Kiwi Rust 与 kiwi-cpp 实现对比：可复用经验、已建 Issue 与后续优先级

[AlexStocks]

背景与范围

Kiwi 是 kiwi-cpp 的 Rust 演进版本，但两者目前已经不是简单的逐文件翻译关系。Rust Kiwi 选择了 Tokio、OpenRaft、Tonic 和权威 RocksDB 数据集，并把 Redis 8.8.1 精确兼容、崩溃恢复和系统稳定性作为当前主线；kiwi-cpp 则保留了长期运行中积累的 braft/brpc/RocksDB 实现与故障记录。

本轮对比固定在以下快照：

• arana-db/kiwi main@3164d4a0fead580ac6701fb0595e50193c4edff9
• arana-db/kiwi-cpp unstable@0fa4f1b95ff2f89873d06eb86de40532dd91d146
• kiwi-cpp 公开 Issue：90 个（40 open / 50 closed）
• Kiwi 公开 Issue：121 个（63 open / 58 closed，包含本轮新建的 feat(lifecycle): 建立 RESP、Raft、storage 的有界优雅关闭生命周期 #408、fix(info): 删除硬编码假数据并接入真实 runtime、storage 与 Raft 状态 #410）

目标不是把 C++ 实现机械移植到 Rust，而是把 kiwi-cpp 的实现经验和失败历史映射到 Kiwi 当前架构，区分：

1. 当前源码中仍存在、应立即跟踪的缺口；
2. 已被 Kiwi Issue 或 .planning/KANBAN.md 覆盖的事项；
3. 需要等稳定性证据充分后再立项的能力。

实现对比

维度	kiwi-cpp	Rust Kiwi	判断
服务与并发模型	C++ event server、命令工作线程，Raft 使用 braft/brpc	network/storage 两个 Tokio runtime，通过异步 channel 隔离；Raft 使用 OpenRaft/Tonic	Rust 架构边界更明确，但长期任务的 shutdown owner、JoinHandle 和失败传播还没有形成统一生命周期
存储	多实例 RocksDB，已有长期生产问题记录	多实例 RocksDB 是唯一完整权威数据集；正在推进 crash-safe apply、applied metadata、snapshot/log recovery 和 executor 收敛	不应移植 C++ 存储抽象；应复用其崩溃、重启、资源释放问题作为 Rust 故障测试输入
Redis 协议	命令面较早，仍有事务、阻塞命令、INFO 等兼容缺口	目标固定为 exact Redis 8.8.1，已有 RESP2/RESP3、HELLO 和 compatibility manifest/Oracle 规划	兼容结论应以 Redis 8.8.1 raw Oracle 为准，kiwi-cpp 只用于发现高风险场景
Raft	已有显式 ShutDown/Join/Clear，但仍存在优雅关闭、重启回群和崩溃问题	OpenRaft 持久化与状态机正确性工作已拆分为 #332、#334、#336、#340 等	先完成单 Group 的恢复与故障矩阵，再根据瓶颈证据评估 Multi-Raft
可观测性	kiwi-cpp#176 要求优化 INFO	当前 INFO 仍返回版本、OS、PID、端口、uptime、cluster mode 等硬编码值	这是客户端可见的错误状态，不只是缺少指标，已拆为 #410

本轮已经拆出的可执行 Issue

#408：建立 RESP、Raft、storage 的有界优雅关闭生命周期

kiwi-cpp 已有显式停止链，但 #69 和 #77 说明“收到退出信号”不等于具备可靠的集群关闭和恢复合同。Rust Kiwi 当前生产入口收到 Ctrl+C 后主要依赖 RuntimeManager::stop() 和 runtime drop/timeout，RESP、Raft gRPC、append-log drain、OpenRaft、StorageServer 等任务没有统一 owner 与 join 顺序，Linux SIGTERM 也没有进入同一关闭链。

#408 建议固定以下合同：停止 admission → 在共享 deadline 内 drain 已接收请求 → 停止 Raft/gRPC → 停止 storage/background task → 最后关闭 runtime；同时用 standalone 和三节点 leader/follower 进程级重启验证资源释放、membership 恢复和已确认数据。

#410：删除 INFO 硬编码假数据并接入真实 runtime、storage 与 Raft 状态

当前 INFO 会报告固定的 redis_version:7.0.0、os:Windows、PID 1、端口 7379、uptime 1、standalone/cluster disabled 等值，即使实际平台、监听端口或 Raft 模式不同。监控和客户端会把这些字段当作服务事实，因此应优先删除假状态，而不是继续扩充静态模板。

#410 建议通过有界只读 provider 生成一次一致状态快照，并使用 exact Redis 8.8.1 Oracle 固定 section、默认集合、未知 section、字段格式以及 RESP2/RESP3 行为；暂时没有真实来源的字段应按兼容合同输出真实零值、明确 unavailable 或省略，不能伪造。

kiwi-cpp Issue 与 Kiwi 现有规划的映射

以下事项有价值，但目前不需要再创建重复 Issue：

kiwi-cpp 历史事项	Kiwi 当前承接位置	处理建议
#11 Transaction	.planning/KANBAN.md M3-002：Transaction、WATCH、Lua 与错误/TTL 语义	按 exact Redis 8.8.1 行为闭环，不从 C++ 接口直接移植
#65 BLPOP、#186 BRPOP leader switch	M3-003：阻塞命令与连接行为	测试取消、超时、断连、leader 切换以及请求结果不确定性
#23 Python Raft tests、#25 Jepsen、#27 pre-vote crash、#28 on_apply crash、#227 node-down crash	#340、M5-001、M5-002	转换成确定性 fault injection、3/5 节点 process harness 和 Elle/Jepsen history，不保留 C++ 特有实现假设
#141 Follower Proxy	#336 已包含非 leader 写入的 reject/redirect/proxy 行为边界	先固定一致性、超时与错误合同，再决定是否实现透明代理
#20 Multi-Raft	M10-001：单 Group 瓶颈证据与 Multi-Raft 立项评估	在单 Group 正确性、恢复和稳定性门禁完成前不提前实施
#14 Online profiling	#351、#352 的 executor/metrics 基础	先建立低开销、真实、有界的指标来源，再决定在线 profiling 入口
#183 Protect mode	与 #332 的 fatal/unhealthy 语义有关，但不是同一问题	先证明未认证公网暴露、启动配置或 unhealthy 写入的具体可达路径，再拆独立安全 Issue

建议的优先级

P1：先完成生产正确性和可诊断性

• 推进 feat(lifecycle): 建立 RESP、Raft、storage 的有界优雅关闭生命周期 #408 和 fix(info): 删除硬编码假数据并接入真实 runtime、storage 与 Raft 状态 #410；
• 完成 feat(raft): establish crash-safe state machine apply semantics #332、feat(raft): persist and recover state machine applied metadata #334、test(raft): cover crash windows and multi-instance state machine recovery #340 的崩溃恢复与故障窗口验证；
• 完成 refactor(runtime): 使用有界 RocksDB executor 替代未受控的 storage task 调度 #351、chore(runtime): 删除未接线的 batching、scaling、priority 与 metrics 脚手架 #352 的有界 executor、真实指标和无效脚手架收敛；
• 保持 RocksDB 为唯一完整权威数据集，不用 shutdown hook、缓存或强制 snapshot 掩盖恢复问题。

下一阶段：补齐客户端行为和系统级验证

• 按 M3-002、M3-003 推进事务、阻塞命令、连接取消和 leader 切换语义；
• 按 M5-001、M5-002 建立 3/5 节点 process harness、网络/磁盘故障矩阵和 Elle/Jepsen history；
• 把 kiwi-cpp 的历史故障转成 Rust Kiwi 可复现、可自动化的回归用例。

后续评估，不提前承诺实现

• Multi-Raft：等待单 Group 瓶颈和稳定性证据；
• Follower Proxy：等待非 leader 行为、一致性和错误合同固定；
• Online profiling：等待 runtime/storage/Raft metrics 来源稳定；
• Protect mode：等待安全威胁模型和客户端可达路径证据。

建议长期采用的对比原则

1. 不按文件或类逐行移植 kiwi-cpp；按公开行为、持久化合同和故障场景迁移经验。
2. kiwi-cpp 的开放 Issue 不是 Rust Kiwi 的自动待办列表；先和当前源码、Issue、KANBAN 去重。
3. 优先复用失败历史，而不是追求命令数量或功能表面的对齐。
4. Redis 兼容行为以 exact Redis 8.8.1 raw Oracle 为准，不以 kiwi-cpp 结果替代。
5. 所有状态发现接口只能报告真实、有界、可追溯的数据；没有来源时不要填入看似合理的常量。
6. graceful shutdown 与 crash recovery 分开验收：前者证明有界 drain/资源释放，后者证明进程无法执行退出钩子时仍能正确恢复。

希望维护者确认的问题

1. 是否接受“feat(lifecycle): 建立 RESP、Raft、storage 的有界优雅关闭生命周期 #408/fix(info): 删除硬编码假数据并接入真实 runtime、storage 与 Raft 状态 #410 + 既有 Raft/runtime P1 → M3 客户端行为 → M5 系统故障矩阵 → M10 Multi-Raft 评估”的顺序？
2. feat(lifecycle): 建立 RESP、Raft、storage 的有界优雅关闭生命周期 #408 应作为直接实现 Issue，还是升级为 lifecycle Epic 并继续拆分 RESP、Raft、storage 子任务？
3. fix(info): 删除硬编码假数据并接入真实 runtime、storage 与 Raft 状态 #410 是否先交付准确的 server、clients、stats、persistence、replication/cluster、keyspace 最小集合，再逐步扩充其余 section？
4. 下一轮是否优先把 kiwi-cpp 的 Raft 崩溃/重启类 Issue 转成 Kiwi 的 process harness 与 fault-injection 用例？

以上结论只适用于文首固定 SHA；相关入口、规划或 Issue 状态变化后，需要重新对账。