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 字节。
