• 2021-07-17

    什么是 Paxos 的日志空洞?

    Views: 536 | No Comments

    Paxos 所谓的日志空洞, 在讨论 Paxos 和 Raft 对比时出现的频率非常高, 非常显眼. Paxos 的日志空洞是什么? "日志空洞"对线性一致性有什么影响? 我认为大多数人都对 Paxos 日志空洞有误解, 包括我之前也是.

    很多人认为 Multi Paxos 可以允许空洞, 但是 Paxos 论文提到:

    To guarantee that all servers execute the same sequence of state machine commands, we implement a sequence of separate instances of the Paxos consensus algorithm, the value chosen by the ith instance being the ith state machine command in the sequence.

    状态机必须严格按顺序执行(apply)命令, 所以, Multi Paxos 并不允许 apply 时出现所谓的日志空洞. 虽然会乱序 chosen(也即所谓的空洞), 但是, apply 一定是严格按顺序进行的. Apply 的时候, 如果不是严格按顺序的, 就不是日志复制状态机.

    但是, 因为必须严格按顺序执行日志序列, 所以, 即使 Multi Paxos 乱序 chosen 日志, 也不会影响外部一致性.

    Continue reading »

    Posted by ideawu at 2021-07-17 22:48:54 Tags: ,
  • 2021-07-01

    分布式系统核心三要素

    Views: 783 | 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: 753 | 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: 1383 | 2 Comments

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

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

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

    Continue reading »

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

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

    Views: 728 | No Comments

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

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

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

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

    Posted by ideawu at 2021-06-23 23:56:43
  • 2021-06-04

    数据库内核的快照技术实现原理

    Views: 839 | No Comments

    "快照(Snapshot)"是数据库领域非常重要的一个概念, 最初是用于数据备份. 如今, 快照技术已经成为数据库内核(引擎)最核心的技术特性之一. 数据库内核的绝大多数操作, 都依赖于快照, 例如, LevelDB 的每一次读取操作和遍历操作, 其内部都必须创建一个快照, 所以, 对于一个请求量非常大的系统, 数据库内核每秒种就要创建和销毁几十万次快照. 因此, 如何快速地创建和销毁快照, 成为一个数据库内核(引擎)必须要解决的问题.

    本文从源头出发, 逐步推演, 探讨数据库内核是如何实现快照技术的. 数据库内核创建快照, 将使用如下技术:

    1. 全量拷贝(Full Clone)
    2. 写时拷贝(Copy On Write)
    3. 分区拷贝(Partitioning)
    4. 多版本(Multi Versioning, Leveling, Zero Copy)

    无论何种实现快照的技术, 数据拷贝都不可避免, 差异点主要是不同的技术拷贝的数据量不同, 以及拷贝的数据含义不同(直接拷贝和间接拷贝). 直接拷贝意味着拷贝数据本身, 间接拷贝则拷贝数据的"指针".

    拷贝意味着互斥, 独占, 加锁, 因为拷贝需要保证数据的完整性. 硬盘数据拷贝速度是较慢的, 往往被认为不可接受, 应极力避免. 内存数据拷贝速度较快, 但仍然需要减少拷贝的数据量.
    Continue reading »

    Posted by ideawu at 2021-06-04 22:10:51
|<<<1234>>>| 1/4 Pages, 20 Results.