RaftKeeper：构建跨机房高可用 OLAP 集群

项目背景：Zookeeper在OLAP业务中引发性能瓶颈和稳定性问题，如Table ReadOnly导致插入失败、分布式DDL操作超时等。
Zookeeper引起的问题：JVM GC STW、状态机Map扩容、mntr命令等阻塞因素影响性能。
RaftKeeper项目：社区计划研发keeper替代Zookeeper，解决Zookeeper在OLAP中的角色问题（Metdatastore、Operation Log、Coordinator）。
项目研发动机：实际业务问题突出，社区计划研发keeper替代Zookeeper。
项目目标：完全兼容ZK用户接口，性能至少提升2倍，降低ZK阻塞因素。
Raft分布式共识算法：用于解决分布式副本间数据一致性，采用majority规则，保证已commit请求不回退。
Raft优势：相对Paxos易理解，工程实践简单，广泛用于Kudu、TiDB、Etcd等。
WhyNuRaft：算法方面，第三方依赖少，代码优雅；实现方面，Pre-vote机制、Leadership过期机制、Leader指派机制，增加quorumsize灵活性。
核心特性：完全兼容ZK生态，写吞吐Zookeeper 2倍，查询平稳，TP99稳定，Session内请求顺序保证，支持30w长连接。

基础功能：支持Zookeeper握手协议、基础命令（Create、Remove、Exists、Get、Set等）、异常处理。
高级功能：四字命令（NodeWatch、ParentNodeWatch、Snap）、特殊节点（Ephemeral、Sequential、SequentialEphemeral）。
架构设计：
- 整体架构要点：状态机是核心模块，读请求直接访问状态机，写请求走LogReplication流程，数据持久化采用snapshot+binlog，LogStore设置cache提升性能。
- 一致性约束：Session内请求顺序执行，已提交事务顺序执行。
- 架构设计–session内一致性：PipeRunner保证Session内写请求在同一个线程执行，读请求按xid顺序执行。
- 架构设计–状态机：负责功能实现、logcommit请求应用、用户查询请求处理、维护session信息。
- 架构设计–存储结构：采用snapshot+binlog方式持久化数据。

性能优化：
- Batch：将用户写请求批量处理，提升效率。
- Pipeline：请求分解为多个环节，由不同线程完成，形成流水线提升吞吐量。
延时优化–状态机Map：使用TwolevelHashMap，减小阻塞时间。
延时优化–异步Snapshot（WIP）：异步snapshot消除查询阻塞，但可能导致部分日志被apply两次。
优化小结：
- 性能优化：Pipeline和Batch执行模型，环形队列缓存日志，多线程处理请求。
- 延时优化：状态机哈希表优化，异步Snapshot消除阻塞，C++无JVMGC阻塞。