• 2021-07-13

    Leader based 的集群也可以100%高可用

    Views: 3361 | No Comments

    很多初学者错误地认为, 像 Raft 这样的 leader based 的分布式协议不是 100% 高可用的, 因为"Raft 在选主的过程中, 不能提供服务". 初学者之所以存在这种错误认知, 完全是因为他们没有理论结合实践, 只略懂一点理论皮毛, 就胡乱引申导致的. 本文将在理论和实践结合的层面上, 分析这种错误认知.

    首先, Raft 的选举过程并没有特殊的成本, 在局域网条件下, 一般只需要 5ms 的时间. 5 毫秒对于实用的分布式集群, 是微不足道的时间长度, 因为客户端对时间长度的认知是百毫秒级别的, 只要客户端在 5 毫秒之后重试[可靠通信三原则], 或者服务器先 Hold 住请求, 过 5 毫秒之后再处理, 对于客户端来说, 完全没有感受到服务不可用, 因此, 服务是 100% 高可用.

    我认为, leader based 的集群, 最大的问题在于"何时发起选举?". 也就是, 如何能快速地发现当前集群失去了有效的 leader.

    客户端可能发现集群无主, 但是, 我们不会把这个权限赋予客户端, 因为在 CS 理论中, 客户端是不可信的. 所以, 只能交由集群成员去发现集群是否需要发起选举.

    Continue reading »

    Posted by ideawu at 2021-07-13 21:57:52 Tags:
  • 2021-07-01

    分布式系统核心三要素

    Views: 6481 | No Comments

    曾经有一次, 某个技术人员向我介绍了他们自研的"分布式存储系统", 他提到, 他们使用了开源的 Raft 库做数据同步, 使用了开源的 B+Tree 存储引擎存储数据到硬盘上. 由于使用的都是非常成熟的开源组件, 技术选型非常正确, 系统结构也简单合理, 这样的系统, 不可否认, 能存储几 TB 的数据, 被广泛应用起来完全没有问题.

    但是, 对于他自称这是一个"分布式数据库"或者"分布式存储系统", 我无法认同, 我无法认同以如此功能如此结构的系统, 竟能挂以"分布式"之名. 但是, 我又没有理论支持说"你们这个系统不是分布式系统!".

    虽然诡辩术广泛存在, 同时每个人的视角不同, 但是, 根据我的实际经验, 和我对分布式系统的理解, 我想总结出分布式系统的核心三要素, 只具备部分要素的系统, 要谨慎挂以"分布式"之名.

    分布式系统核心三要素:

    • 要素一: 多副本(Replication), 系统包含多个完全相同(一致)的节点
    • 要素二: 多分区(Sharding), 系统被拆分成多个完全独立的节点组
    • 要素三: 协作(Cooperation), 节点组之间有协作, 共同完成某项工作

    Continue reading »

    Posted by ideawu at 2021-07-01 21:45:53
  • 2021-06-29

    分布式数据库系统的容错处理 – 100% 成功率, 超时和性能

    Views: 5087 | No Comments

    之前写过一篇文章, 介绍"可靠通信三原则". 对于一个分布式数据库, 如果想实现 100% 高可用(也即客户端的请求永远不会返回失败), 同样可以用可靠通信三原则中的重试理论和去重理论来解决. 但在实践上, 需要在成功率, 耗时(速度和性能)各方面进行取舍. 本文分享实际经验, 介绍什么样的选择是普适的, 各位可以参考.

    客户端访问数据库服务器, 发起大量的请求, 绝对不可能做到每一个请求都是成功的. 因为网络原因, 请求可能失败. 因为服务器内部处理冲突, 或者分布式节点间协调冲突, 都可能导致请求失败.

    所谓容错处理, 就是在遇到错误的时候进行重试. 因为错误必然发生, 只有重试才能消除错误的影响, 就好像 IP 层必然会丢包, 但 TCP 协议通过重传达到某种程度的可靠传输.

    某些实现了 Basic Paxos + 日志复制状态机模型的系统, 因为所谓的"Leaderless", 会产生大量冲突. 即使是使用 Raft, 在某些情况下意外发生选举, 也会导致请求冲突.

    Continue reading »

    Posted by ideawu at 2021-06-29 22:16:55 Tags: ,
  • 2021-06-27

    分布式数据库如何做到异地多活?

    Views: 9409 | 2 Comments

    前段时间写过一篇文章"分布式数据库系统如何做到平滑缩扩容?", 讲了分布式数据库在扩容(集群服务器开机关机)过程中, 如何保证服务 100% 不中断. 那篇文章主要是从客户端的角度去考虑问题, 正如该文章所说的, 一个分布式系统, 必须服务端和客户共同协作, 才能实现服务不中断. 本文从服务端, 也即狭义理解的"数据库系统"的角度, 分析一个分布式数据库系统是如何做到 100% 高可用的.

    注意, 高可用, 异地多活, 多主(Leaderless), 这些词汇, 本质上是指同一个东西, 都是指在单一节点宕机时, 客户端可以切换(切主)到其它节点访问, 或者说, 客户端在平时可以访问任意一个节点(多主) -- 切主多主是一回事, 只要可以做到足够快速地切主, 即使表面上一个系统是有 Leader Based 的, 那么它和 Leaderless 没有区别. 阅读本文之后, 相信你能加深对这些概念的理解.

    首先说一个定理: 只有强一致性的多副本系统, 才能异地多活.

    Continue reading »

    Posted by ideawu at 2021-06-27 23:24:48 Tags: ,
  • 2021-06-26

    并发编程两原则

    Views: 4658 | No Comments

    之前写过一篇文章, 并发编程的核心技术 – 多版本(Multi Versioning), 本文继续对并发编程做一次更全面的总结, 这样的总结并非具体的编程指导, 而概括性的理论, 是笔记性质的.

    根据经验总结, 并发编程的指导思想可以总结为两个原则, 也即并发编程两原则:

    1. Sharding/Partitioning
    2. Leveling

    Continue reading »

    Posted by ideawu at 2021-06-26 20:17:54
  • 2021-06-23

    分布式数据库异地多活不是你想的那样

    Views: 4095 | No Comments

    在分布式数据库领域, "异地多活"是一个非常诱人的特性, 被广泛用于商业广告宣传. 但是, "异地多活"未必是你所想象的那种"多活". 因为分布式数据库的三个重要特性:

    • 多副本
    • 多写入点
    • 低延迟

    "异地多活"占据了前两个, 根据"不可能三角"理论, 一旦选择了前两个特性, 那么低延迟便不再是一个选项, 而是一个结果, 给你多大的延迟(多慢), 你就得接受多大的延迟, 你无法选择.

    这里涉及到一个基础科学思维的问题, "结果"是一种客观存在的东西, 而"选择"是一种主观决定的东西. 根据"不可能三角"理论, 你无法同时选择三个特性, 不代表一旦你选择其中两个, 就一定会得到极差的第三个特性, 而是说, 一旦你选择了其中两个特性, 那么第三个特性就已经完全固定, 无法再改变.
    Continue reading »

    Posted by ideawu at 2021-06-23 23:56:43
|<<<123456789>>>| 3/9 Pages, 52 Results.