最新 | 最热门 | 最高评价
4

-1  什么是分布式一致性

Tag: 分布式 | 数据库 | Paxos | Raft
ideawu 发于 2021年09月05日 10:49 | 点击: 2330 | 展开摘要
在工程实践上, 分布式一致性和多副本有关系, 如果没有多副本, 就没有分布式一致性的问题.

多副本的定义: 多副本可以放在多台机器上, 也可以放在同一个进程内的不同内存地址内, 或者一个副本在内存, 一个副本在硬盘. 只要同一个对象出现在多处, 或者在多处被引用, 就是多副本.

各个副本的写入操作序列必须先经过共识, 按同样的顺序写入, 因此所有副本的状态将是最终一致的(相同). 但是, 有可能单独地读取某个副本, 这就导致读操作在不同副本上发生的顺序并不相同, 这显然会

查看全文: http://www.udpwork.com/item/18147.html
---

+0  Paxos 和 Raft 的结构差异

Tag: 分布式 | Paxos | Raft
ideawu 发于 2021年08月07日 09:09 | 点击: 815 | 展开摘要
如果用面向对象的方法来分析 Paxos 和 Raft 的对象层次结构关系, 我们会发现, 两者其实没那么多差异, 或者说, 这种差异我们平时在做面向对象建模和编写代码时经常使用.

Basic Paxos

type Entry struct {
promised_num int64
proposal_num int64
proposal_value []byte
}

Multi Paxos

type Node struct {
entries []struct

查看全文: http://www.udpwork.com/item/18116.html
^..^

+0  什么是日志复制状态机?

Tag: 分布式 | 数据库 | Paxos | Raft | 日志复制状态机
ideawu 发于 2021年08月05日 21:37 | 点击: 703 | 展开摘要
日志复制状态机, 也叫复制状态机, 是分布式数据库领域最重要的基石之一. 当前市面上所有实用的分布式数据库, 几乎都是用日志复制状态机技术来实现多副本. 像 MySQL 的主从同步, Redis 的主从同步, SSDB 的主从同步等, 是大家非常熟知的日志复制状态机的例子. 而更复杂的共识算法 Paxos, 以及最流行的分布式一致性协议 Raft, 前者的实现基本离不开日志复制状态机, 后者则是直接以日志复制状态机作为其核心组成.

那么, 什么是日志复制状态机呢? 首先,

查看全文: http://www.udpwork.com/item/18117.html
11

+1  为什么极少有开源的Paxos库?

Tag: 分布式 | Paxos | Raft
ideawu 发于 2021年07月30日 00:24 | 点击: 1574 | 展开摘要
你是不是也很奇怪, Paxos 既然被称为唯一的共识算法(分布式一致性算法), 是分布式系统的基石, 那么为什么极少看到开源的 Paxos 库呢? 反观 Raft, 有 etcd 开源的 go 语言写的库, 有 PingCap(tidb)开源的 Rust 语言写的, 还有百度, 阿里等等公司开源的各种语言的库. 既然 Paxos 那么牛逼, 为什么江湖中只有它的传说, 却从来没有人见过它的身影呢?

原因很简单, Paxos(准确的说是 Basic Paxos) 是共识算法,

查看全文: http://www.udpwork.com/item/17979.html
---

+0  Raft ReadIndex 有什么神奇之处?

Tag: 分布式 | Raft
ideawu 发于 2021年07月25日 19:45 | 点击: 606 | 展开摘要
其实, 工程上的一致性读, 本质是操作的先后顺序. 只要让读操作在某一个节点上发生的顺序, 在我们预想的那个写操作之后, 这时只依赖该节点, 就能保证一次正确的一致性读. 例如, 假设我们知道某次写操作的序号是 idx, 对应某条编号为 idx 的日志, 只要我们等某个节点 apply 了这条日志, 然后直接读状态机就可以了, 就能满足强一致性的定义.

但是, 虽然可以要求客户端请求读操作时带上它所依赖的那次写操作的编号, 但工程上并不合理, 所以, 只能由集群节点自己找到

查看全文: http://www.udpwork.com/item/17981.html
^..^

+0  什么是 Paxos 的日志空洞?

Tag: 分布式 | 数据库 | Paxos | Raft
ideawu 发于 2021年07月17日 22:48 | 点击: 761 | 展开摘要
Paxos 所谓的日志空洞, 在讨论 Paxos 和 Raft 对比时出现的频率非常高, 非常显眼. Paxos 的日志空洞是什么? "日志空洞"对线性一致性有什么影响? 我认为大多数人都对 Paxos 日志空洞有误解, 包括我之前也是.

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

To guarantee that all servers execute the same sequence of state machine comm

查看全文: http://www.udpwork.com/item/17986.html
---

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

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

首先, Raft 的选举过程并没有特殊的成本, 在局域网条件下, 一般只需要 5ms 的时间. 5 毫秒对于实用的分布式集群, 是微不足道的时间长度,

查看全文: http://www.udpwork.com/item/17988.html
---

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

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

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

查看全文: http://www.udpwork.com/item/17864.html
---

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

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

注意, 高可用, 异地多活, 多主(Leaderless), 这些词汇, 本质上是指

查看全文: http://www.udpwork.com/item/17865.html
---

+0  Raft 为什么不能直接 commit 前任的日志?

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年05月21日 23:07 | 点击: 1040 | 展开摘要
有一些文章, 包括 Raft 协议的论文, 已经从反例的角度解释了为什么不允许 Leader 直接 commit 前任的日志, 而是必须追加本任期的一条日志, 以达到隐式地 commit 前任的日志. 我想从 Raft 的几项原则的角度, 在逻辑上解释这个问题.

Raft 策略1: 节点的日志一旦 commit 便不可撤销

某个节点的一条日志, 一旦 commit 它, 那么就会对状态机造成不可逆的改变. 也许某些状态机有回滚功能, 但在 Raft 的架构中, 假设状态机

查看全文: http://www.udpwork.com/item/17484.html
^..^

+0  Raft 协议和区块链

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年05月08日 22:19 | 点击: 621 | 展开摘要
我还没有发现有人把 Raft 协议和区块链关联到一起讨论, 但是经过仔细分析, 穿透问题的本质之后, Raft 和区块链技术具有非常多的共同点. 可以整理出一个表格:

Raft
区块链
通用

日志
区块
Entry, Node, 节点, 记录

日志序列
区块链
Chain, 链表(前向指针)

选举: Leader 可产生日志
算力: 任意节点付出成本产生区块
Leader

Term
分叉
Branch

基于 Quorum 立即 Commit
立即相信最长的链条
C

查看全文: http://www.udpwork.com/item/17486.html
---

+0  Raft日志复制状态机模型的Apply进度问题

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年04月30日 22:25 | 点击: 783 | 展开摘要
日志复制状态机模型是 Raft 协议里的一个基础概念, 用于保障多副本一致性. 这个概念并非 Raft 独创, 而是由 Raft 具体总结和推广的, 在 Raft 之前, 像 MySQL 的 binlog 等等, 都是广义的日志复制状态机模型.

采用日志复制状态机模型的系统, 把多副本一致性问题分解成两个部分(模块), 第一部分是日志本身的一致性, 第二部分是状态机(例如数据库引擎)的数据一致性. 这两个系统模式是独立运行的, 它们之间的通信(Apply)也是异步的. 由此

查看全文: http://www.udpwork.com/item/17454.html
|<<<12>>>| 一共2页, 15条记录