云存储已经自带 3 副本，大家觉得基于云构建存储系统还需依赖 Raft 这类基于共识的算法吗？
zhouxinyu 2024-01-24 11:52:21 +08:00 2127 次点击这是一个创建于 682 天前的主题，其中的信息可能已经有所发展或是发生改变。
一直以来，存储软件都基于复制来提高数据的可靠性和系统的可用性，复制的方式有很多种，各个模式间可能还有交集：
- 同步复制、异步复制
- 强一致性、最终一致性
- 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 的开发者们怎么看待这个问题，欢迎大家发表下看法。
 | 1 cyifei2023 2024-01-24 11:58:22 +08:00 automq 这个方案相比不用云存储的 Apache kafka 具体哪些方面有优势呢？有数据吗？ |
 | 2 XDMonkey 2024-01-24 12:02:30 +08:00 基于云盘再去构建多副本一定是重复建设，问题是如何相信云厂商的 SLA 。。 |
 | 3 wan0573 2024-01-24 12:28:09 +08:00 @XDMonkey 这个本质是云信任的问题。云也是在发展中的，长远来看云厂商的 SLA 肯定是比自建更高的。只不过国内现在每次云厂商出问题都上新闻，好多自建的出事没上新闻，让大家感觉好像自建 SLA 更好一样，其实不然。我们可以参照云发展更加先进的美国，他们很多银行也都是直接使用的公有云。这个 google 下可以搜到很多新闻： https://ir.usbank.com/news-releases/news-release-details/us-bank-partners-microsoft-accelerate-future-banking-cloud |
 | 4 zhouxinyu OP @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) |
| 5 zhouxinyu &bsp; OP @XDMonkey 请相信云厂商提供的块存储、对象存储这类服务，背后有数百人的团队，一定比企业自建更稳定。另外，在云上，最大的稳定性风险实际上是来自于软件故障，因为云上所有的资源生命周期都是通过 API 来管理的，我们架构上很容易通过「可编程」的理念来应对这些故障，比如 ECS 、EBS 、S3 任意一个资源出故障，我们都可以通过 API 创建替换资源用于容灾。 |
 | 6 isno 2024-03-08 15:49:39 +08:00 原来是 RocketMQ 的大佬。 没仔细看过 AutoMQ ，AutoMQ 是把底层的存储、可用性交给云对吧？ 上云托管，将底层系统的复杂度交给云基础设施，技术美好，商业上应该能趟出一条路。 |
| 7 zhouxinyu OP @isno 是的，目前我们认为这是一个比较明确的云原生技术方向，怎么把云用好我们有不少的技术思考点，也在 V2EX 跟大家分享。。 |
| 8 isno 2024-03-15 13:11:51 +08:00 @zhouxinyu 我在想一个反向的问题：云上的资源虽好，但贵。而且还绑定服务商不好迁移。 如果方向是“云上之云”，只利用云 IaaS 层最基本的资源（网络、存储、计算），做私有化的 PaaS 方案。一键就能在 ECS 安装高可用的 RDS 、MQ 、存储、K8S 、分布式的 GPU 等等服务。架构做到易用，自由迁移（ ali 到 azure 、azure 到 aws ，甚至到自建机房），享受无限的云上资源。 这个想法怎么样？ 能锤下我么？ |
| 9 zhouxinyu OP @isno 挺好呀。。。现在不少企业用云的方式其实就是这样干的，核心依赖 IaaS 层的云服务。比如举个例子，Aiven 一家芬兰的做数据的厂商，他们上面的一些 PaaS 服务，支持跨云迁移，能迁到各个云上。 |
| 10 isno 2024-03-15 16:33:21 +08:00 |
Select Language