• 2021-09-06

    关于多写入点数据库集群的一些想法

    Views: 23242 | No Comments

    在分布式数据库系统领域, 多主(多写入点, Leader-less)是一个非常诱人的特性, 因为客户端可以随机请求任何一个节点. 这种可随机选择访问点(写入点)的特性, 使得系统的高可用唾手可得, 因为当客户端发现某个节点出故障时, 更换另一个节点重试就可以了, 只要系统没有完全宕机, 几次重试之后一定成功, 也就可以达到百分之百高可用.

    传统的 Basic Paxos 常常被误认为是 Leader-less 的, 也即多主, 但 Basic Paxos 只能用于确定一个实例的共识, 真正落地还需要结合日志复制状态机, 如果复制组(多节点)不指定 Leader 的话, 那么就会出现争取同一个位置的日志的情况, 也就是在尝试达成这个位置的日志的共识时出现活锁. 这种多节点争取同一个位置的情况, 在实践上将导致系统不可用, 因为, 通常自称采用 Paxos 的多副本数据库系统, 依然要显式指定 Leader, 并不是真正 Leader-less 的.

    Continue reading »

    Posted by ideawu at 2021-09-06 20:51:04 Tags: ,
  • 2021-09-05

    什么是分布式一致性

    Views: 20084 | No Comments

    在工程实践上, 分布式一致性和多副本有关系, 如果没有多副本, 就没有分布式一致性的问题.

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

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

    例如, 先写后读与先读后写, 显然读出来的结果不一样, 这个很显然. 因为日志序列的复制和执行必然是异步的, 绝对不可能所有副本在同一个时间点同时写入, 必然有一个时间差, 这也是很显然的. 因此, 如果轻率地去读取不同副本, 将可能导致读取的结果不同, 因为某个写入操作可能只在某个副本上执行了, 而在另一个副本上还没有执行, 所以读取的结果不同, 这是很显然的.

    Continue reading »

    Posted by ideawu at 2021-09-05 10:49:53 Tags: ,
  • 2021-08-11

    Paxos 算法难以理解吗?

    Views: 14669 | No Comments

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

    首先, 我们需要理解 Paxos 的算法的定位. 不幸地是, 在这第一步, 我们就遇到的麻烦! 大多数人接触到 Paxos 都是从 Basic Paxos 的两个步骤(1a, 1b, 2a, 2b)开始的. 人们花费了大量的精力来记忆这当中的操作步骤, 但是, 却看不到为什么要这样做.

    第一个问题也出现了, Paxos 是不是等于 Basic Paxos? Paxos 是不是就等于那两个步骤? 我们还没谈到 Multi Paxos, 另一个极不完善的理论.

    Continue reading »

    Posted by ideawu at 2021-08-11 21:29:19 Tags:
  • 2021-08-07

    Paxos 和 Raft 的结构差异

    Views: 8104 | No Comments

    如果用面向对象的方法来分析 Paxos 和 Raft 的对象层次结构关系, 我们会发现, 两者其实没那么多差异, 或者说, 这种差异我们平时在做面向对象建模和编写代码时经常使用.

    Basic Paxos

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

    Multi Paxos

    type Node struct {
    	entries []struct {
    		promised_num int64
    		proposal_num int64
    		proposal_value []byte
    	}
    }
    

    Raft

    type Node struct {
    	currentTerm int64 // promised_num
    	entries []struct {
    		term  int64   // proposal_num
    		value []byte  // proposal_value
    	}
    }
    

    首先, Basic Paxos 关注的是一条日志(Log Entry), 和 Raft 不是一个层次的东西. Multi Paxos 和 Raft 的结构类似, 本质上都是"日志复制状态机".

    Continue reading »

    Posted by ideawu at 2021-08-07 09:09:04 Tags: ,
  • 2021-08-05

    什么是日志复制状态机?

    Views: 13015 | No Comments

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

    那么, 什么是日志复制状态机呢? 首先, 我们先理解什么状态机. 状态机基于一个定理, 这个定理是显然的, 不需要证明的. 那就是, 如果两个被称为状态机的对象, 它们按相同的顺序执行(Apply)相同的指令序列, 那么, 指令执行完毕后, 这两个状态机的状态将必然是相同的(一致的).

    指令序列也称为日志序列, 一般每一条日志带有一个唯一整数编号以确定顺序. 如果日志序列被复制到不同的地方, 然后由状态机执行, 那么分布在不同地方的状态机的状态就一致了. 这种技术便称为日志复制状态机. 状态机对象便是一个副本, 例如是一个数据库实例.

    Continue reading »

    Posted by ideawu at 2021-08-05 21:37:58 Tags: , ,
  • 2021-07-30

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

    Views: 9007 | No Comments

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

    原因很简单, Paxos(准确的说是 Basic Paxos) 是共识算法, 用于对一个实例的状态形成共识, 这个用途和工程上的一致性协议基本是金属铁块和汽车的关系. 工程师对 Paxos 最大的疑问经常是:

    • 什么是实例? 一整个 database 是一个实例吗? 一个 key 是实例吗?
    • 共识是什么? 是一个 key 对应的 value 吗? 形成共识之后就不能更改? 有什么用?

    Continue reading »

    Posted by ideawu at 2021-07-30 00:24:42 Tags: ,
|<<<123456789>>>| 1/9 Pages, 52 Results.