多Chronicle Queue读取时Chronicle Event Loop使用方案咨询

以下是生产环境验证过的落地实践，完全贴合Chronicle系列组件低延迟、无GC的设计目标：

• 线程绑核隔离：每个跑Event Loop的线程单独绑定一个被操作系统隔离的CPU核心，Linux环境下可配置SCHED_FIFO实时调度策略，关闭对应核心的节能调度、中断负载均衡，避免上下文切换带来的延迟毛刺。绝对不要在Event Loop线程里跑任何阻塞操作、堆内存大对象分配逻辑，从根源减少GC停顿。
• 读写资源隔离：队列的写入Appender和读取Tailer不要共用同一个Event Loop线程，分别给读写流程分配独立的Event Loop。读取侧用tailer.readingDocument()做非阻塞轮询，低延迟场景直接用忙等（Busy Wait）策略，不要加sleep或者长时间park；写入侧可以配合excerptAppender.batch()做批量刷盘，减少系统调用开销。
• 组件线程封闭：Chronicle的Tailer、Appender、Event Loop实例都严格遵循线程封闭原则，绝对不要跨线程调用这些实例的方法，否则会出现不可预期的顺序错乱、数据损坏问题。
• 异常兜底：Event Loop里要加捕获Throwable的兜底逻辑，避免读取到坏消息、队列文件损坏时直接把整个事件循环线程打挂，异常发生时记录偏移量后可以选择跳过坏消息或者暂停对应队列的读取，不要影响其他流程。

完全可以基于Event Loop实现，且能满足每个读取器独占独立线程/CPU核心的要求，正确实现方式如下：

• 不要把两个队列的Tailer注册到同一个Event Loop实例里。单Event Loop轮询多Tailer的模式不仅无法做到核心独占，还会出现高频消息队列饿死低频消息队列的问题，延迟稳定性极差。
• 给每个Chronicle Queue单独初始化专属的Tailer、专属的Event Loop实例，两个Event Loop分别启动在独立的线程上，启动时分别给两个线程绑定不同的隔离CPU核心即可。两个读取流程完全独立，互不抢占执行资源，延迟表现和单队列读取没有差异。
• 如果业务需要聚合两个队列的数据，不要在两个读取线程里直接操作共享变量，优先用无锁堆外队列做数据传递，避免锁竞争带来的性能损耗。

踩坑提醒：如果CPU资源足够，两个读取Event Loop都优先用忙等轮询策略，不要用阻塞等待的读取方法，否则会失去Chronicle Queue微秒级延迟的优势；如果CPU资源紧张，可以给Event Loop配置微秒级的短park时间，平衡CPU占用和延迟表现。

内容的提问来源于stack exchange，提问作者heniek