云存储已经自带 3 副本，大家觉得基于云构建存储系统还需要依赖 Raft 这类基于共识的算法吗？

一直以来，存储软件都基于复制来提高数据的可靠性和系统的可用性，复制的方式有很多种，各个模式间可能还有交集：

同步复制、异步复制
强一致性、最终一致性
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 的开发者们怎么看待这个问题，欢迎大家发表下看法。

wan0573

119 天前

@XDMonkey 这个本质是云信任的问题。云也是在发展中的，长远来看云厂商的 SLA 肯定是比自建更高的。只不过国内现在每次云厂商出问题都上新闻，好多自建的出事没上新闻，让大家感觉好像自建 SLA 更好一样，其实不然。我们可以参照云发展更加先进的美国，他们很多银行也都是直接使用的公有云。这个 google 下可以搜到很多新闻： https://ir.usbank.com/news-releases/news-release-details/us-bank-partners-microsoft-accelerate-future-banking-cloud

zhouxinyu

119 天前

@cyifei2023 我们因为基于 S3 构建了一层共享存储，实际上是一个 Shared Everything 的架构，Apache Kafka 是一个传统的 IDC 架构，走的是 Shared Nothing 路线，所以每个 Broker 都会绑定一块磁盘。存储完全共享后，我们获得了这些优势：
1. 弹性，S3 的大规模，对于单个租户，可以认为是无限容量的，再也不需要做容量评估了。
2. 因为有了共享存储，困扰 Kafka 已久的分区迁移和扩缩容问题都迎刃而解。
3. 最重要的是成本，不需要复制，省了大量的存储和计算成本。
4. 存储卸载至云，Kafka Broker 变得无状态，云厂商的竞价实例都可以用起来。

我们发表过一篇技术文章，讲解我们的云原生架构，可以看一下：[上云还是下云：章文嵩博士解读真正的云原生 Kafka 十倍降本方案！]( https://www.infoq.cn/article/f4hJdZqtKAQdJvCKQYq7)

zhouxinyu

119 天前

@XDMonkey 请相信云厂商提供的块存储、对象存储这类服务，背后有数百人的团队，一定比企业自建更稳定。另外，在云上，最大的稳定性风险实际上是来自于软件故障，因为云上所有的资源生命周期都是通过 API 来管理的，我们架构上很容易通过「可编程」的理念来应对这些故障，比如 ECS 、EBS 、S3 任意一个资源出故障，我们都可以通过 API 创建替换资源用于容灾。

isno

68 天前

@zhouxinyu 我在想一个反向的问题：云上的资源虽好，但贵。而且还绑定服务商不好迁移。

如果方向是“云上之云”，只利用云 IaaS 层最基本的资源（网络、存储、计算），做私有化的 PaaS 方案。一键就能在 ECS 安装高可用的 RDS 、MQ 、存储、K8S 、分布式的 GPU 等等服务。架构做到易用，自由迁移（ ali 到 azure 、azure 到 aws ，甚至到自建机房），享受无限的云上资源。

这个想法怎么样？能锤下我么？