最新 | 最热门 | 最高评价

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

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

查看全文: http://www.udpwork.com/item/17979.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  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  分布式数据库系统的容错处理 – 100% 成功率, 超时和性能

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

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

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

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

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

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

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

+0  Multi-Master-Paxos: 3

Tag: algo | distributed | replication | paxos | multi-master | multi-leader | active-active | 分布式 | 多活 | 多主
张炎泼(xp) 发于 2021年06月14日 08:00 | 点击: 137 | 展开摘要
Background

200行代码实现paxos-kv
中介绍了一款非常简洁的分布式kv存储实现, 它是基于 classic-paxos
实现分布式一致性. 在 paxos的直观解释 中我们提到, 每次写入, 也就是每个 paxos 实例需要2轮 RPC 完成, 效率低.

一个常见的优化就是 mutli-paxos(或raft), 用一次 RPC 对多个实例运行 phase-1;
再对每个实例分别运行 phase-2, 这样均摊开销是一次 RPC 完成一次写入.
它通过

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

+0  再谈 Paxos 和 Raft

Tag: 分布式 | Paxos | Raft
ideawu 发于 2021年04月18日 11:59 | 点击: 215 | 展开摘要
我之前写过一些谈 Paxos 的文章[1][2], 特别是将 Paxos[3] 和 Raft[4] 进行了对比. 由于我更多的是站在工程实现的角度考虑两种技术的优缺点, 所以造成了不少读者感受到我有非常强的"贬 Paxos, 赞 Raft"的倾向. 不可否认, 从工程实现的角度, Paxos 的指导意义非常抽象且不直接, 所以我们必须""亲 Raft 远 Paxos".

实际上, 许多人认为 Paxos 和 Raft 不是同一层面的东西, 不可同日而语. 另一方面, 某种角

查看全文: http://www.udpwork.com/item/17459.html
|<<<123>>>| 一共3页, 28条记录