自动驾驶中间件iceoryx - 架构设计（二）

第3章 架构设计+

本章目录

• [3.2 核心组件详解](#3.2 核心组件详解)

  • [3.2.1 RouDi（Route & Discover）](#3.2.1 RouDi（Route & Discover）)
    • 启动流程
    • 线程模型
    • 关键数据结构
  • [3.2.2 PoshRuntime](#3.2.2 PoshRuntime)
  • [3.2.3 Publisher 与 Subscriber](#3.2.3 Publisher 与 Subscriber)

• [3.3 服务三元组与端口机制](#3.3 服务三元组与端口机制)

  • [3.3.1 ServiceDescription](#3.3.1 ServiceDescription)
  • [3.3.2 端口匹配规则](#3.3.2 端口匹配规则)
  • [3.3.3 端口状态机](#3.3.3 端口状态机)
  • [3.3.4 多对多关系](#3.3.4 多对多关系)

• [3.4 完整生命周期流程](#3.4 完整生命周期流程)

  • [3.4.1 系统启动](#3.4.1 系统启动)
  • [3.4.2 应用启动](#3.4.2 应用启动)
  • [3.4.3 数据传输](#3.4.3 数据传输)
  • [3.4.4 应用退出](#3.4.4 应用退出)

• [3.5 线程模型与并发](#3.5 线程模型与并发)

  • [3.5.1 应用线程](#3.5.1 应用线程)
  • [3.5.2 无锁数据结构](#3.5.2 无锁数据结构)

• [3.6 配置与调优](#3.6 配置与调优)

  • [3.6.1 内存池配置](#3.6.1 内存池配置)
    • 配置文件示例
    • 配置加载流程
  • [3.6.2 队列深度](#3.6.2 队列深度)

• [3.7 小结](#3.7 小结)

前文 自动驾驶中间件iceoryx - 架构设计（一）。

本章深入剖析 iceoryx 的架构设计，重点讲解三平面模型、核心组件职责、端口机制、生命周期流程与线程模型。通过本章，你将建立对整个系统的宏观理解，为后续深入内存管理与性能调优奠定基础。

3.2 核心组件详解

3.2.1 RouDi（Route & Discover）

RouDi 是整个系统的中枢，单进程运行，负责资源管理与协调。

启动流程

1. 解析配置文件（TOML）
2. 计算总内存需求
3. 创建共享内存段（shm_open + ftruncate + mmap）
4. 使用 BumpAllocator 分区内存
5. 初始化各 MemoryManager
6. 创建控制通道（UDS/NamedPipe）
7. 启动处理线程
8. 进入主循环，处理 IPC 消息

线程模型

RouDi 采用多线程架构，各线程职责清晰分离。以下是实际运行时的线程列表（可通过 ps -T -p <pid> 查看）：

线程名称	职责	触发频率/方式
iox-roudi	主线程，执行 waitForTerminationRequest()	等待终止信号
IPC-msg-process	🔥 IPC 消息处理线程（Unix Socket）	事件驱动（收到消息时处理）
Mon+Discover	🔥 监控和服务发现线程	每 100ms 执行一次
PortIntr	端口内省线程，发布端口状态信息	每 1s 发送一次
ProcessIntr	进程内省线程，发布进程列表信息	每 1s 发送一次
MemPoolIntr	内存池内省线程，发布内存池使用情况	每 1s 发送一次

主线程（iox-roudi）

主线程主要负责初始化和等待终止信号：

// 启动所有子线程
m_processIntrospection.run();      // 启动 ProcessIntr 线程
m_mempoolIntrospection.run();      // 启动 MemPoolIntr 线程
m_portManager->doDiscovery();      // 启动 PortIntr 线程
m_monitoringAndDiscoveryThread = std::thread(&RouDi::monitorAndDiscoveryUpdate, this);
m_handleRuntimeMessageThread = std::thread(&RouDi::processRuntimeMessages, this, ...);

// 等待终止信号
waitForTerminationRequest();

// 收到信号后进行清理
shutdown();

IPC-msg-process 线程（核心）

处理应用的控制消息，这是控制平面的核心线程：

void RouDi::processRuntimeMessages(...) noexcept {
    setThreadName("IPC-msg-process");
    
    IOX_LOG(Info, "RouDi is ready for clients");
    
    while (m_runHandleRuntimeMessageThread) {
        runtime::IpcMessage message;
        if (roudiIpc.timedReceive(m_runtimeMessagesThreadTimeout, message)) {
            auto cmd = runtime::stringToIpcMessageType(message.getElementAtIndex(0).c_str());
            RuntimeName_t runtimeName{...};
            
            processMessage(message, cmd, runtimeName);  // 处理注册、创建端口等请求
        }
    }
}

处理的消息类型包括：REG（注册）、CREATE_PUBLISHER、CREATE_SUBSCRIBER、TERMINATION 等。

📌 详细的 IPC 消息处理流程
CREATE_PUBLISHER 等消息的详细处理机制（包括消息格式、序列化、相对指针转换、错误处理等）请参见 第 6 章 服务发现与端口管理 中的"6.3 端口创建流程详解"小节。

Mon+Discover 线程（核心）

定期执行进程监控和服务发现：

void RouDi::monitorAndDiscoveryUpdate() noexcept {
    setThreadName("Mon+Discover");
    
    while (m_runMonitoringAndDiscoveryThread) {
        m_prcMgr->run();  // 检查所有进程存活状态，清理崩溃进程资源
        
        cyclicUpdateHook();  // 可选的周期性更新钩子
        
        // 每 100ms 执行一次，或手动触发时立即执行
        discoveryLoopWaitset.timedWait(DISCOVERY_INTERVAL);
    }
}

内省线程（Introspection Threads）

三个内省线程使用相同的机制（PeriodicTask），定期发布系统状态供监控工具（如 iox-introspection-client）订阅：

// PortIntr 线程：发布端口信息（Publisher/Subscriber 列表、连接状态等）
concurrent::detail::PeriodicTask<...> m_publishingTask{
    concurrent::detail::PeriodicTaskManualStart, 
    "PortIntr",    // 线程名称
    *this, 
    &PortIntrospection::send
};

// ProcessIntr 线程：发布进程列表（进程 PID、名称等）
concurrent::detail::PeriodicTask<...> m_publishingTask{
    ..., "ProcessIntr", *this, &ProcessIntrospection::send
};

// MemPoolIntr 线程：发布内存池使用率（各池已用/总数、段信息等）
concurrent::detail::PeriodicTask<...> m_publishingTask{
    ..., "MemPoolIntr", *this, &MemPoolIntrospection::send
};

默认发送间隔为 1 秒 ，可通过 setSendInterval() 调整。

关键数据结构

RouDi 内部维护两个核心数据结构来管理整个系统的通信拓扑，它们分别承担着"逻辑索引"和"物理存储"的职责。

服务注册表（Service Registry）

服务注册表是 RouDi 实现服务发现的核心数据结构，它建立了从服务描述（ServiceDescription）到端口引用计数的映射关系。这个映射表回答了一个关键问题：给定一个服务三元组，有多少发布者正在提供该服务？有多少服务器在提供该服务？

// 代码位置：iceoryx_posh/include/iceoryx_posh/internal/roudi/service_registry.hpp
class ServiceRegistry {
    struct ServiceDescriptionEntry {
        capro::ServiceDescription serviceDescription;
        ReferenceCounter_t publisherCount{0U};  // 该服务的发布者数量
        ReferenceCounter_t serverCount{0U};     // 该服务的服务器数量
    };
    
    // 内部使用 vector 存储服务条目
    vector<optional<ServiceDescriptionEntry>, CAPACITY> m_serviceDescriptions;
};

// PortManager 持有服务注册表实例
// 代码位置：iceoryx_posh/include/iceoryx_posh/internal/roudi/port_manager.hpp
class PortManager {
    ServiceRegistry m_serviceRegistry;  // 服务注册表
};

工作原理：

1. 注册阶段 ：当应用创建 Publisher 时，RouDi 调用 addPublisher()，找到或创建对应的 ServiceDescriptionEntry，将 publisherCount 加 1
2. 查找阶段 ：通过 find() 方法支持通配符查询（service/instance/event 可以是 nullopt），遍历所有匹配条目
3. 动态更新 ：应用退出或端口销毁时，调用 removePublisher()，将引用计数减 1，计数归零后删除条目
4. 变更检测 ：hasDataChangedSinceLastCall() 用于服务发现时检测拓扑变化

使用场景：

// 场景 1：添加 Publisher 到注册表
auto result = m_serviceRegistry.addPublisher(serviceDescription);
if (result.has_error()) {
    // 注册表已满
    return Error::SERVICE_REGISTRY_FULL;
}

// 场景 2：查找匹配的服务（支持通配符）
m_serviceRegistry.find(
    capro::IdString_t("Radar"),    // service
    iox::nullopt,                  // instance（通配符）
    iox::nullopt,                  // event（通配符）
    [](const auto& entry) {
        // 处理每个匹配的服务
        if (entry.publisherCount > 0) {
            // 有发布者在提供此服务
        }
    }
);

// 场景 3：遍历所有服务
m_serviceRegistry.forEach([](const auto& entry) {
端口池是 RouDi 管理端口资源的物理存储容器，它负责端口数据结构的生命周期管理。这个池子回答了另一个关键问题：**如何高效地分配和回收端口资源，避免内存碎片和动态分配开销？**

```cpp
// 代码位置：iceoryx_posh/include/iceoryx_posh/internal/roudi/port_pool_data.hpp
struct PortPoolData {
    using PublisherContainer = FixedPositionContainer<popo::PublisherPortData, MAX_PUBLISHERS>;
    PublisherContainer m_publisherPortMembers;

    using SubscriberContainer = FixedPositionContainer<popo::SubscriberPortData, MAX_SUBSCRIBERS>;
    SubscriberContainer m_subscriberPortMembers;

    using ServerContainer = FixedPositionContainer<popo::ServerPortData, MAX_SERVERS>;
    ServerContainer m_serverPortMembers;

    using ClientContainer = FixedPositionContainer<popo::ClientPortData, MAX_CLIENTS>;
    ClientContainer m_clientPortMembers;
    
    // 还有 InterfacePort、ConditionVariable 等容器...
};

内存效率：服务注册表只记录"有多少个"，而非"是谁"，节省内存

• 职责分离：端口指针列表由 PortPool 管理，注册表只负责服务层面的统计
• 快速检测：通过计数快速判断服务是否存在，无需遍历指针列表
• 支持通配符查询 ：find() 方法允许使用 nullopt 作为通配符，灵活查询服务

端口池（Port Pool）

端口池是 RouDi 管理端口资源的物理存储容器，它负责端口数据结构的生命周期管理。这个池子回答了另一个关键问题：如何高效地分配和回收端口资源，避免内存碎片和动态分配开销？

// 代码位置：iceoryx_posh/include/iceoryx_posh/internal/roudi/port_pool.hpp
iox::cxx::FixedPositionContainer<PublisherPortData, MAX_PUBLISHERS> m_publisherPorts;
iox::cxx::FixedPositionContainer<SubscriberPortData, MAX_SUBSCRIBERS> m_subscriberPorts;

核心特性：

1. 固定容量：编译时确定最大端口数（通过 CMake 配置）

   • MAX_PUBLISHERS：默认 512
   • MAX_SUBSCRIBERS：默认 1024
   • MAX_CLIENT_PORTS、MAX_SERVER_PORTS 等类似

2. 预分配内存：所有端口数据在 RouDi 启动时一次性分配在共享内存中，运行时无动态分配

3. 位置稳定性 ：FixedPositionContainer 保证元素一旦分配，其内存地址不变（即使其他元素被删除），这对于共享内存中的指针引用至关重要

工作流程：

// 分配新端口
auto maybePort = m_publisherPorts.insert(
    serviceDescription,     // 服务三元组
    publisherOptions,       // 配置选项
    runtimeName,            // 应用名称
    memoryManager          // 内存管理器
);

if (maybePort.has_value()) {
    // 成功：返回端口指针（共享内存中的地址）
**两个数据结构的协同**：

```text
服务注册表（服务层面统计）    端口池（端口实例存储）
+----------------------------+  +----------------------------+
| ServiceDescriptionEntry    |  | PublisherPortData[0]       |
| {"Radar","Front","Obj"}    |  |   service: {"Radar",...}   |
|   publisherCount: 2        |  |   runtime: "app1"          |
|   serverCount: 0           |  | PublisherPortData[1] (空闲) |
|                            |  | PublisherPortData[2] (空闲) |
| {"Camera","Left","Image"}  |  | PublisherPortData[3]       |
|   publisherCount: 1        |  |   service: {"Radar",...}   |
|   serverCount: 0           |  |   runtime: "app2"          |
+----------------------------+  | PublisherPortData[4]       |
                                |   service: {"Camera",...}  |
                                |   runtime: "app3"          |
                                +----------------------------+

• 服务注册表：记录每个服务有多少个 Publisher/Server，支持通配符查询和快速检测
• 端口池 ：存储所有端口实例的完整数据，提供 O(1) 分配/回收
• 协同工作 ：
  • 创建端口时：先从端口池分配 → 再在注册表中增加计数
  • 服务发现时：注册表快速判断服务是否存在 → 端口池遍历匹配的端口建立连接
  • 销毁端口时：先在注册表中减少计数 → 再归还端口到池中
• 职责分离：注册表负责"有什么服务"，端口池负责"谁在用端口"

特性	std::vector	FixedPositionContainer
内存布局	连续存储，可能重新分配	固定位置，地址永不变
删除操作	移动元素填补空隙	标记为空闲，位置保留
指针稳定性	❌ 重新分配会失效	✅ 始终有效
适用场景	动态大小、单进程	共享内存、跨进程指针

在共享内存环境中，指针稳定性 至关重要。如果端口地址在运行时改变，其他进程中的引用会失效，导致段错误。FixedPositionContainer 通过牺牲一定的内存连续性（存在空洞），换取了绝对的地址稳定性。

两个数据结构的协同：

服务注册表（逻辑索引）         端口池（物理存储）
+----------------------------+  +----------------------------+
| {"Radar","Front","Obj"}    |  | PublisherPortData[0]       |
|   ├─> [Port0*, Port3*]     |  | PublisherPortData[1] (free)|
|                            |  | PublisherPortData[2] (free)|
| {"Camera","Left","Image"}  |  | PublisherPortData[3]       |
|   └─> [Port4*]             |  | PublisherPortData[4]       |
+----------------------------+  | ...                        |
                                +----------------------------+

• 服务注册表 ：提供 O(log N) 的快速查找，支持服务发现
• 端口池 ：提供 O(1) 的分配/回收，管理资源生命周期
• 协同工作：注册表存储指向端口池的指针，实现"索引与存储分离"

代码位置

• iceoryx_posh/source/roudi/roudi.cpp：主入口
• iceoryx_posh/source/roudi/port_manager.cpp：端口管理
• iceoryx_posh/source/roudi/process_manager.cpp：进程管理

3.2.2 PoshRuntime

这是应用端的运行时库，封装与 RouDi 的通信。

初始化

// 应用启动时必须调用
iox::runtime::PoshRuntime::initRuntime("my_app_name");

// 内部流程：
// 1. 连接到 RouDi 的控制通道（UDS/NamedPipe）
// 2. 发送注册消息（REG）
// 3. 接收唯一进程 ID
// 4. 映射共享内存段
// 5. 创建应用端的内存管理器代理

创建 Publisher

auto publisher = runtime.createPublisher<MyData>({"Service", "Instance", "Event"});

// 内部流程：
// 1. 发送 CREATE_PUBLISHER 消息到 RouDi
// 2. RouDi 分配端口、建立路由
// 3. 返回端口地址（共享内存中的偏移）
// 4. 应用通过相对指针访问端口

代码位置

• iceoryx_posh/source/runtime/posh_runtime.cpp：运行时接口
• iceoryx_posh/source/runtime/posh_runtime_impl.cpp：实现细节

3.2.3 Publisher 与 Subscriber

应用层 API 的封装，内部包含端口数据与操作。

Publisher 内部结构

class Publisher<T> {
    PublisherPortUser m_port;  // 端口封装
    
    auto loan() {
        return m_port.tryAllocateChunk(sizeof(T), alignof(T))
            .and_then([](ChunkHeader* header) {
                return Sample<T>(header);
            });
    }
    
    void publish(Sample<T>&& sample) {
        m_port.sendChunk(sample.release());
    }
};

PublisherPort 数据

位于共享内存，包含：

struct PublisherPortData {
    ServiceDescription service;
    ChunkDistributor distributor;  // 管理订阅者列表
    std::atomic<uint64_t> sequenceNumber;
    // ...
};

Subscriber 内部结构

class Subscriber<T> {
    SubscriberPortUser m_port;
    
    auto take() {
        return m_port.tryGetChunk()
            .and_then([](const ChunkHeader* header) {
                return Sample<const T>(header);
            });
    }
};

SubscriberPort 数据

struct SubscriberPortData {
    ServiceDescription service;
    ChunkQueue<256> chunkQueue;  // 接收队列
    ConditionListener listener;  // 通知机制
    // ...
};

代码位置

• iceoryx_posh/include/iceoryx_posh/popo/publisher.hpp
• iceoryx_posh/include/iceoryx_posh/popo/subscriber.hpp
• iceoryx_posh/source/popo/ports/publisher_port_user.cpp
• iceoryx_posh/source/popo/ports/subscriber_port_user.cpp

3.3 服务三元组与端口机制

3.3.1 ServiceDescription

唯一标识一个通信通道：

struct ServiceDescription {
    IdString_t service;    // 例如 "Radar"
    IdString_t instance;   // 例如 "FrontLeft"
    IdString_t event;      // 例如 "Objects"
};

3.3.2 端口匹配规则

RouDi 根据三元组精确匹配：

bool match(const ServiceDescription& pub, const ServiceDescription& sub) {
    return pub.service == sub.service &&
           pub.instance == sub.instance &&
           pub.event == sub.event;
}

3.3.3 端口状态机

Publisher:
  [WAITING_FOR_OFFER] → offer() → [OFFERED]
  [OFFERED] → stopOffer() → [WAITING_FOR_OFFER]

Subscriber:
  [NOT_SUBSCRIBED] → subscribe() → [SUBSCRIBED]
  [SUBSCRIBED] → unsubscribe() → [NOT_SUBSCRIBED]

3.3.4 多对多关系

• 一个 Publisher 可以有多个 Subscriber
• 一个 Subscriber 只能连接一个 Publisher（1:N，非 M:N）

3.4 完整生命周期流程

3.4.1 系统启动

1. 管理员启动 RouDi
   ./iox-roudi -c config.toml

2. RouDi 初始化
   - 解析配置
   - 创建共享内存（/dev/shm/iceoryx_mgmt）
   - 分区内存池
   - 监听控制通道（/tmp/iceoryx_roudi.socket）

3. 系统就绪
   Log: "RouDi is ready for clients"

3.4.2 应用启动

Publisher 应用：
1. initRuntime("publisher_app")
   - 连接 UDS → send(REG) → recv(ProcessID=42)
   - mmap("/iceoryx_mgmt")

2. createPublisher({"Radar", "Front", "Objects"})
   - send(CREATE_PUBLISHER) → recv(PortOffset=0x1000)
   - 通过相对指针访问 PublisherPortData

3. publisher.offer()
   - 设置端口状态 = OFFERED
   - RouDi 发现可匹配的 Subscriber

Subscriber 应用：
1. initRuntime("subscriber_app")
   - 类似 Publisher

2. createSubscriber({"Radar", "Front", "Objects"})
   - send(CREATE_SUBSCRIBER) → recv(PortOffset=0x2000)

3. subscriber.subscribe()
   - 设置端口状态 = SUBSCRIBED
   - RouDi 建立路由：PublisherPort → SubscriberPort

3.4.3 数据传输

发布端：
1. auto sample = publisher.loan();
   → MemoryManager::getChunk(size)
   → 返回 ChunkHeader* (shared memory)

2. sample->x = 10.5f;  // 直接写入共享内存

3. sample.publish();
   → ChunkDistributor::deliverToAllStoredQueues(chunk)
   → for each Subscriber: ChunkQueue::push(chunk)
   → ConditionNotifier::notify() → sem_post()

接收端：
4. sem_wait() 被唤醒

5. auto sample = subscriber.take();
   → ChunkQueue::pop() → 返回 ChunkHeader*
   
6. float x = sample->x;  // 直接读共享内存（零拷贝）

7. } // sample 析构
   → ChunkHeader::referenceCount.fetch_sub(1)
   → if (refCount == 0) returnToPool()

3.4.4 应用退出

1. subscriber 析构
   - unsubscribe()
   - send(TERMINATION) 到 RouDi

2. RouDi 清理
   - 移除 SubscriberPort 路由
   - 释放端口资源
   - 回收未释放的 Chunk

3. publisher 析构
   - stopOffer()
   - 类似清理

4. PoshRuntime 析构
   - 断开 UDS 连接
   - munmap 共享内存

3.5 线程模型与并发

本节重点讨论应用层的线程使用和并发控制。关于 RouDi 的线程模型（6 个线程的职责、频率、代码实现）已在 3.2.1 RouDi 组件 中详细介绍，此处不再赘述。

3.5.1 应用线程

应用可自由创建线程，但需注意：

• Publisher/Subscriber 非线程安全：同一个对象不可并发调用
• 推荐模式：每线程独立 Publisher/Subscriber
• 或使用互斥锁保护

3.5.2 无锁数据结构

ChunkQueue（SPSC）

• 单生产者（Publisher）、单消费者（Subscriber）
• 读写索引用 std::atomic<uint64_t>
• 无需锁

引用计数

void ChunkHeader::incrementReferenceCount() {
    m_refCount.fetch_add(1, std::memory_order_relaxed);
}

void ChunkHeader::decrementReferenceCount() {
    if (m_refCount.fetch_sub(1, std::memory_order_acq_rel) == 1) {
        // 最后一个引用，归还到内存池
        m_originMemoryManager->freeChunk(this);
    }
}

3.6 配置与调优

3.6.1 内存池配置

iceoryx 的内存池配置通过 TOML 配置文件 （roudi_config.toml）进行管理，RouDi 在启动时读取该文件完成初始化。

配置文件示例

# roudi_config.toml
[general]
version = 1

[[segment]]
[[segment.mempool]]
size = 128      # Chunk 大小（字节）
count = 10000   # Chunk 数量

[[segment.mempool]]
size = 1024
count = 5000

[[segment.mempool]]
size = 16384
count = 1000

配置加载流程

RouDi 在启动时按以下步骤处理配置文件：

// 1. 启动 RouDi 时指定配置文件
$ ./iox-roudi -c /path/to/roudi_config.toml

// 2. RouDi 内部解析流程（iceoryx_posh/source/roudi/roudi_config_toml_file_provider.cpp）
auto config = RouDiConfigTomlFileProvider::parse(configFilePath);

// 3. 根据配置计算总内存需求
for (auto& mempool : config.mempools) {
    totalSize += mempool.size * mempool.count;
}

// 4. 创建共享内存段并分配内存池
for (auto& mempool : config.mempools) {
    memoryManager->addMemoryPool(mempool.size, mempool.count);
}

关键特性：

• 运行时可配置：修改 TOML 文件后重启 RouDi 即生效，无需重新编译
• 多段内存支持 ：可配置多个 [[segment]]，分别用于不同用户组或安全域
• 默认配置 ：如不指定 -c 参数，使用编译时的默认配置（CMake 选项）

调优原则

内存池大小选择：

• 根据数据大小选择合适的 size
• 数量 = 峰值并发 × 安全系数（1.2-1.5）
• 避免过大的池（浪费内存）
• 避免过小的池（分配失败）

配置文件位置：

• 系统默认：/etc/iceoryx/roudi_config.toml
• 用户自定义：通过 -c 参数指定任意路径
• 示例配置：iceoryx_meta/roudi_config_example.toml

3.6.2 队列深度

队列深度（queueCapacity）控制订阅者的接收队列大小，它与内存池的 count 是两个不同层面的配置。

队列深度 vs 内存池数量

配置项	作用范围	含义	配置方式
内存池 count	全局（所有应用共享）	共享内存中该大小 Chunk 的总数	TOML 文件
队列深度 queueCapacity	单个订阅者	该订阅者可缓存的未处理消息数	应用代码

示例说明

# TOML 配置：全局内存池
[[segment.mempool]]
size = 1024
count = 5000    # 整个系统共有 5000 个 1KB 的 Chunk

// 应用代码：订阅者队列
SubscriberOptions options;
options.queueCapacity = 256;  // 这个订阅者最多缓存 256 条消息
subscriber = createSubscriber(service, options);

关系与约束

1. 队列深度不能超过内存池数量

场景：10 个订阅者，每个队列深度 256
需求：最坏情况下需要 10 × 256 = 2560 个 Chunk
配置：内存池 count 至少应为 2560（实际建议 3000+）

2. 队列深度影响单个订阅者的缓冲能力

// 发布者高速发送（1000 msg/s）
for (int i = 0; i < 1000; i++) {
    publisher.publish(sample);
}

// 订阅者慢速处理（100 msg/s）
// 队列深度 256：可缓冲 2.56 秒的数据
// 队列深度 64：可缓冲 0.64 秒的数据（容易溢出）

3. 内存池 count 影响系统整体容量

内存池不足的后果：
- publisher.loan() 返回 nullptr（无可用 Chunk）
- 应用需要等待或丢弃数据
- 影响所有发布者，而非单个订阅者

配置示例

场景 1：多订阅者 + 低延迟

# 10 个订阅者，每个队列 64
[[segment.mempool]]
size = 4096
count = 1000    # 10 × 64 × 1.5 = 960（留有余量）

SubscriberOptions options;
options.queueCapacity = 64;  // 低延迟优先
options.queueFullPolicy = QueueFullPolicy2::DISCARD_OLDEST_DATA;

场景 2：单订阅者 + 高吞吐

# 1 个订阅者，大缓冲
[[segment.mempool]]
size = 1024
count = 600     # 1 × 512 × 1.2 = 614

SubscriberOptions options;
options.queueCapacity = 512;  // 高吞吐，允许更大延迟
options.queueFullPolicy = QueueFullPolicy2::BLOCK_PRODUCER;

调优原则

队列深度（queueCapacity）：

• 小队列（64-128）：低延迟，适合实时控制系统
• 中队列（256）：默认值，平衡性能和延迟
• 大队列（512+）：高吞吐，适合离线处理或批量分析

内存池 count：

• 公式 ：count ≥ Σ(订阅者数 × queueCapacity) × 安全系数
• 安全系数：通常 1.2-1.5，考虑发布者缓冲和传输中的 Chunk
• 监控 ：使用 iox-introspection-client 查看内存池使用率

权衡：

配置	优点	缺点
大队列 + 大 count	高吞吐、容错性强	延迟大、内存占用高
小队列 + 小 count	低延迟、内存节约	易丢数据、容错性差
大队列 + 小 count	⚠️ 配置错误	队列无法填满，浪费配置
小队列 + 大 count	灵活性高	内存利用率低

3.7 小结

本章详细剖析了 iceoryx 的架构：

核心要点：

1. 三平面解耦：控制/数据/通知各司其职，互不干扰
2. RouDi 中枢：资源管理、服务发现、路由匹配
3. 零拷贝实现：共享内存 + 无锁队列 + 相对指针
4. 生命周期清晰：注册 → 匹配 → 传输 → 清理
5. 并发模型简洁：无锁数据结构 + 原子操作

与后续章节的关系：

• 第4章将深入数据平面的内存管理细节
• 第5章介绍通知平面的高级用法（WaitSet、Callbacks）
• 第6章讨论性能调优与最佳实践

下一章将深入 Chunk 的生命周期、MemoryManager 的分配策略、以及如何追踪 mmap 调用链。