一直以来，存储软件都基于复制来提高数据的可靠性和系统的可用性，复制的方式有很多种，各个模式间可能还有交集：
- 同步复制、异步复制
- 强一致性、最终一致性
- Leader-follower Replication
- Decentralized Replication （一般 Client 侧进行多写/Quorum Write ，比如阿里云的盘古）
因为有了多个副本，一方面能够容忍部分副本的数据损坏，也能在部分节点不可用时，通过冗余的副本选出新的 Leader 节点来提高系统的可用性。
在面向 IDC 环境，这样的架构没有任何问题，但今天将这些存储系统 Rehost 到云上后，第一个暴露出来的问题就是成本。
我们都知道，云存储已经提供了极高的可靠性和可用性，以块存储 EBS 和对象存储 S3 为例：
- 对象存储提供 4 个 9 左右的可用性，11 个 9 左右的数据可靠性。
- EBS 提供 3 个 9 左右的可用性，5~9 个的可靠性。
当然，不同的云厂商有 SLA 差异，不过可以看出云存储已经通过多副本或 EC 技术提供了很高的 SLA 了，如果应用层还要基于云存储去做 3 副本复制，数据最多可能会冗余 9 个副本。
基于这个背景，想找大家讨论下，如果要面向云做一款真正云原生的存储软件，Raft 这类算法还有必要性吗？
我目前的答案是完全没有必要了，云原生的软件一定是要深度用云，把复杂度卸载至云，让应用层变得更轻量，更弹性，更低成本，基于这些思考，我们（ AutoMQ ）面向云原生重新设计了 Kafka ，充分撬动云计算带来的技术和规模化红利，感兴趣的可以移步我们的开源项目： https://github.com/AutoMQ/automq-for-kafka
不知道 V2EX 的开发者们怎么看待这个问题，欢迎大家发表下看法。
Select Language