V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
zhouxinyu
V2EX  ›  云计算

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

  •  7
     
  •   zhouxinyu · 338 天前 · 1501 次点击
    这是一个创建于 338 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    11 条回复    2024-03-16 10:48:52 +08:00
    cyifei2023
        1
    cyifei2023  
       338 天前
    automq 这个方案相比不用云存储的 Apache kafka 具体哪些方面有优势呢?有数据吗?
    XDMonkey
        2
    XDMonkey  
       338 天前
    基于云盘再去构建多副本一定是重复建设,问题是如何相信云厂商的 SLA 。。
    wan0573
        3
    wan0573  
       338 天前
    @XDMonkey 这个本质是云信任的问题。云也是在发展中的,长远来看云厂商的 SLA 肯定是比自建更高的。只不过国内现在每次云厂商出问题都上新闻,好多自建的出事没上新闻,让大家感觉好像自建 SLA 更好一样,其实不然。我们可以参照云发展更加先进的美国,他们很多银行也都是直接使用的公有云。这个 google 下可以搜到很多新闻: https://ir.usbank.com/news-releases/news-release-details/us-bank-partners-microsoft-accelerate-future-banking-cloud
    zhouxinyu
        4
    zhouxinyu  
    OP
       338 天前
    @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
        5
    zhouxinyu  
    OP
       338 天前
    @XDMonkey 请相信云厂商提供的块存储、对象存储这类服务,背后有数百人的团队,一定比企业自建更稳定。另外,在云上,最大的稳定性风险实际上是来自于软件故障,因为云上所有的资源生命周期都是通过 API 来管理的,我们架构上很容易通过「可编程」的理念来应对这些故障,比如 ECS 、EBS 、S3 任意一个资源出故障,我们都可以通过 API 创建替换资源用于容灾。
    isno
        6
    isno  
       293 天前
    原来是 RocketMQ 的大佬。

    没仔细看过 AutoMQ ,AutoMQ 是把底层的存储、可用性交给云对吧? 上云托管,将底层系统的复杂度交给云基础设施,技术美好,商业上应该能趟出一条路。
    zhouxinyu
        7
    zhouxinyu  
    OP
       287 天前
    @isno 是的,目前我们认为这是一个比较明确的云原生技术方向,怎么把云用好我们有不少的技术思考点,也在 V2EX 跟大家分享。。
    isno
        8
    isno  
       287 天前
    @zhouxinyu 我在想一个反向的问题:云上的资源虽好,但贵。而且还绑定服务商不好迁移。

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

    这个想法怎么样? 能锤下我么?
    zhouxinyu
        9
    zhouxinyu  
    OP
       286 天前
    @isno 挺好呀。。。现在不少企业用云的方式其实就是这样干的,核心依赖 IaaS 层的云服务。比如举个例子,Aiven 一家芬兰的做数据的厂商,他们上面的一些 PaaS 服务,支持跨云迁移,能迁到各个云上。
    isno
        10
    isno  
       286 天前
    @zhouxinyu 大佬,如果方便是否可以加个微信啊,我对这个方向挺感兴趣。

    我的微信号( base64 ):d2VpZmVuZzEwMjY=
    zhouxinyu
        11
    zhouxinyu  
    OP
       286 天前
    @isno 好的。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5535 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 06:39 · PVG 14:39 · LAX 22:39 · JFK 01:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.