RebornDB下一代架构的三项演进方向

[[Codis相比Redis Cluster的架构选择：无状态Proxy+可插拔存储]]虽然解决了水平扩展和运维灵活性的问题，但在实际运行中也暴露出下一代架构需要重点解决的三类局限，RebornDB正是针对这三点做的演进：第一，ZooKeeper作为分布状态的存储依赖，本身要求额外部署和运维一套独立的分布式协调系统，增加了整体的部署复杂度和潜在故障点，RebornDB选择把类似Raft的一致性协议直接内置到系统自身里，不再依赖外部的ZooKeeper或etcd；第二，底层存储引擎虽然理论上”可插拔”，但实际上要在不同存储引擎之间切换、或是升级存储引擎版本，仍然需要大量人工介入和细致的生命周期管理，RebornDB把存储引擎的生命周期管理做了进一步抽象，让插拔真正做到自动化和低运维成本；第三，Codis原有的数据迁移方案效率有限，RebornDB转向基于复制的迁移方式——不是一次性搬运数据，而是把迁移建模成一种特殊的复制关系，迁移过程更平滑、对在线服务的影响更小。这三项改进共同体现了一种成熟中间件的自我进化路径：先用一个相对简单、能快速落地的架构（依赖外部组件、抽象层次较浅）解决从0到1的问题，再在生产实践中反复验证之后，把外部依赖收归内部、把抽象做得更彻底，用架构复杂度的适度提升换取运维复杂度的下降。