最新 | 最热门 | 最高评价

+0  什么是分布式一致性

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

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

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

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

+0  Paxos 算法难以理解吗?

Tag: 分布式 | Paxos
ideawu 发于 2021年08月11日 21:29 | 点击: 137 | 展开摘要
Paxos 被冠以"晦涩难懂"的恶名, 一方面来源于它自身的定位不清, 边界模糊, 另一方面来源于它并不直接解决工程上广泛的强烈需求. 工程师们需要一个算法(规则, 协议), 用来开发一个分布式多副本系统, 并让多副本对外表现得像一个单一副本的效果(强一致性, 线性一致性, 外部一致性). 坦率地说, Paxos 距离这个需求有十万八千里. 所以, 广大的工程师便认为 Paxos 算法难以理解.

首先, 我们需要理解 Paxos 的算法的定位. 不幸地是, 在这第一步, 我

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

+0  Paxos 和 Raft 的结构差异

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

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

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

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

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

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

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

+0  Paxos 算法实现和工程落地: 选主与复制状态机

Tag: 分布式 | Paxos
ideawu 发于 2021年07月24日 17:54 | 点击: 169 | 展开摘要
有不少对分布式系统感兴趣的同学问我:"Paxos 算法是最基础的分布式共识算法, 但是, 我看完之后, 似懂非懂. Paxos 到底应该如何进行工程落地呢?"

业界对 Paxos 算法有着非常高的美誉, 一方面是因为 Paxos 的开创性, 更多的原因, 至少我所知道的, 许多人之所以赞美 Paxos, 主要是因为"看不懂". 说看不懂似乎不对, 许多人有时觉得自己懂 Paxos, 有时觉得不懂, 今天懂, 明天不懂, 但是必须懂. 要命的是,没法落地, 即使看懂了学完了,

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

+0  分布式系统最重要的基础特性 – 平滑增删节点

Tag: 分布式
ideawu 发于 2021年07月21日 21:29 | 点击: 107 | 展开摘要
对于一个多节点的分布式系统集群, 我们分析一下经常会遇到哪些问题:

因为出现网络分区或者节点关机, 客户端访问到了宕机节点

因为网络分区得到恢复或者节点启动, 客户端没有访问正确的节点

集群扩容/缩容(也就是增删节点)过程中, 客户端访问了错误的节点

在分布式系统环境中, 客户端访问到错误的节点的情况一定会出现, 直接的后果就是请求失败, 所以, 这个问题是分布式系统高可用的核心障碍之一. 如果不解决这个问题, 一个系统一定不是高可用的.

这3个问题, 其实是一个问

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

+0  Paxos 所谓的”幽灵复现”

Tag: 分布式 | Paxos
ideawu 发于 2021年07月18日 13:06 | 点击: 128 | 展开摘要
学习分布式一致性协议的程序员, 或早或晚都会面临所谓的"Paxos 日志幽灵复现"的问题. 就跟学习 TCP 总会遇到所谓的"拆包粘包"问题一样. 这类问题非常之经典, 人们对它们抱有非常顽固的似是而非的误解, 有时这些误解是对的, 但本质其实是错的. 原因就在于, 它们超过了人们的日常理解, 是一种违反常理的东西.

比如 "TCP 粘包"问题, 你能说它不存在吗? 现象确实是这个现象, 但问题本质不是字面上的原因. "TCP 粘包"问题的本质, 是 TCP 对上层提供的是

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

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

Tag: 分布式 | 数据库 | Paxos | Raft
ideawu 发于 2021年07月17日 22:48 | 点击: 145 | 展开摘要
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  分布式系统Redirect和Proxy的区别

Tag: 分布式
ideawu 发于 2021年07月15日 23:41 | 点击: 131 | 展开摘要
正如之前文章"分布式系统核心三要素"所提到的, 多分区(Sharding) 是分布式系统必不可少的核心特性, 无 Sharding 不分布式. Sharding 之后, 必然会遇到服务发现的问题, 也即服务寻址, 或者路由表.

客户端在访问系统的服务之前, 需要拉取路由表, 根据路由表找到访问点的地址, 然后直接请求节点. 根据"Single Source of Truth"原理, 路由表的信息并不是 Truth, 不可能实时反映集群的 Sharding 分布, 因此, 客

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

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

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

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

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