RingBuffer 不提供自动分流，需显式控制消费者拓扑；容量必须为2的幂次方（如1024），否则位运算索引越界；多消费者须用WorkProcessor+WorkerPool实现负载均衡；自定义路由需tryNext()+手动publish()；须防伪共享，关键字段间隔≥64字节。

RingBuffer 本身不提供“分流”逻辑，所有分流行为必须由你显式控制消费者拓扑和事件路由策略；盲目依赖默认单消费者模式或简单广播，反而会拖垮吞吐量。

RingBuffer 的长度必须是 2 的幂次方，否则 next() 和 get() 会出错

Disruptor 内部用位运算 index & (size - 1) 替代取余计算数组下标，这是硬性要求。设成非 2 幂值（比如 1000）会导致索引越界或数据错位，且不会抛异常，只会在运行时静默覆盖错误位置。

• 正确做法：初始化时传入 1024、4096、65536 这类值，不要用 1000 或 5000
• 验证方式：打印 ringBuffer.getBufferSize()，确认是 2 的整数次幂
• 注意：这个 size 是 RingBuffer 容量，不是事件对象数量——实际分配的数组大小会更大（含填充），但对外暴露的可用 slot 数就是该值

多消费者并行处理同一 RingBuffer 时，必须用 WorkProcessor 而非 BatchEventProcessor

如果你希望多个线程共同消费 RingBuffer 中的事件（即“工作窃取”式分流），BatchEventProcessor 会为每个实例独占一段 sequence 区间，造成事件被重复或跳过；而 WorkProcessor 配合 WorkerPool 才能真正实现负载均衡。

• BatchEventProcessor 适合固定角色的消费者（如日志落盘、指标上报各走一路），每路独立消费全量
• WorkProcessor 适合动态任务分发（如订单校验、风控、计费等模块争抢待处理订单），由 Disruptor 自动协调 sequence 分配
• 必须确保所有 WorkProcessor 共享同一个 SequenceBarrier，否则会因等待逻辑错乱卡死

自定义事件路由需绕过 Disruptor 默认 publish 流程，改用 tryNext() + 手动 publish()

当你要根据事件内容决定投递到不同 RingBuffer（比如按业务类型分库写入），不能直接调 ringBuffer.publishEvent() ——它只支持单目标提交。必须拆解为三步：预占位置 → 填充数据 → 按条件选择对应 RingBuffer 提交。

• 先调 long seq = ringBuffer.tryNext() 尝试获取空闲 slot；失败时需主动 sleep 或退避，避免自旋耗尽 CPU
• 用 ringBuffer.get(seq) 取出事件对象，填入完整业务字段（包括用于路由的 key，如 event.setBizType("pay")）
• 根据 event.getBizType() 查表得到目标 RingBuffer 实例，再在其上调用 publish(seq)
• 切记：每个 RingBuffer 的 publish() 必须独立触发，不可复用 sequence 值跨 RingBuffer 提交

最易被忽略的是伪共享——哪怕你把消费者拆得再细，只要 Sequence 字段和事件数据挤在同一个缓存行，多核竞争仍会让吞吐掉 30% 以上。务必用 JOL 工具检查 Event 类布局，确认关键 long 字段之间间隔 ≥64 字节。