[返回] [最新] [最热门] [最高评价]

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

有一些文章, 包括 Raft 协议的论文, 已经从反例的角度解释了为什么不允许 Leader 直接 commit 前任的日志, 而是必须追加本任期的一条日志, 以达到隐式地 commit 前任的日志. 我想从 Raft 的几项原则的角度, 在逻辑上解释这个问题.

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

某个节点的一条日志, 一旦 commit 它, 那么就会对状态机造成不
...

ideawu 2021-05-21 23:07 | 查看: 186

Binlog, Redolog 在分布式数据库系统中的应用

系统结构

request
client -------> server

在一个系统中, 有 client 和 server 两个角色, client 向 server 发起请求(request), 这里的请求指写数据请求, 例如某条类似 "update table set a=1" 这样的 SQL 语句. 我们把 server 进行拆分, 得到下面这个更细化一些的系统结构:

reque
...

ideawu 2021-05-08 22:42 | 查看: 40

Raft 协议和区块链

我还没有发现有人把 Raft 协议和区块链关联到一起讨论, 但是经过仔细分析, 穿透问题的本质之后, Raft 和区块链技术具有非常多的共同点. 可以整理出一个表格:

Raft
区块链
通用

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

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

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

Term
分叉
...

ideawu 2021-05-08 22:19 | 查看: 57

数据库事务ACID和锁

数据库事务功能非常重要, 任何应用只要操作的多个对象之间有依赖(约束)关系, 都会不约而同地想到使用事务, 例如银行转账功能, 社交 App 中的粉丝关注功能, 购物网站下订单功能. 任何一个数据库系统, 如果不提供事务功能, 就不能减少用户(应用开发者)的某些麻烦, 因为用户不得不自己在应用层去实现类似事务的代码逻辑.

从用户的角度看, 如果数据库不提供事务, 他就要多写代码, 这让他很不爽.
...

ideawu 2021-05-02 13:30 | 查看: 267

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

日志复制状态机模型是 Raft 协议里的一个基础概念, 用于保障多副本一致性. 这个概念并非 Raft 独创, 而是由 Raft 具体总结和推广的, 在 Raft 之前, 像 MySQL 的 binlog 等等, 都是广义的日志复制状态机模型.

采用日志复制状态机模型的系统, 把多副本一致性问题分解成两个部分(模块), 第一部分是日志本身的一致性, 第二部分是状态机(例如数据库引擎)的数据一致性
...

ideawu 2021-04-30 22:25 | 查看: 197

分布式数据库的过期机制(TTL)实现原理

像 MySQL 这样的传统关系数据库, 没有提供数据过期自动删除功能(TTL), 因为从常规理解, MySQL 是一个持久化数据库, 不是缓存系统, 数据应该由用户主动地通过 DELETE 指令显式地删除. 不过, 从实践经验上看, 由数据库系统提供基于过期时间自动删除数据(TTL)的功能, 可以减少用户(应用开发者)的工作量. 所以, Redis, SSDB, MongoDB 这些新开的 NoS
...

ideawu 2021-04-30 00:41 | 查看: 235

数据库事务的原子性与隔离级别

数据库事务的原子性并不仅仅是指写操作, 还包括读操作. 对于写操作, 众所周知, 原子性是指操作序列中的所有操作要么全部成功, 要么全部失败. 但多次读操作未必是指要么全部读到要么全部读不到. 如果不是 Snapshot Isolation, 那么两次读操作, 可能有其中一次读到旧值, 另一次读到新值. 但是, 读操作的原子性要求必须满足因果性. 当读到新值之后, 就说明事务中的所有写操作都已完成
...

ideawu 2021-04-24 10:25 | 查看: 129

操作的先后顺序的确定

在计算机领域, 两个操作的先后顺序的确定, 是一个非常严肃的科学问题, 不能仅凭人的直觉来判定.

有两种方式可以规划两个操作的先后顺序:

通信协调

绝对时间规划

通信协调是指, 一个操作 (B) 在明确知道另一个操作 (A) 已经结束的前提下才启动, 那么便可以判定 (B) 在 (A) 之后. 这里说的"明确知道", 包含主观上的知道, 也包括客观上的知道. 例如, 对于顺序(串行)操作,
...

ideawu 2021-04-24 10:14 | 查看: 159

数据库的并发操作与一致性

作为分布式强一致数据库的开发者, 被多次问到:

如果我在新加坡和欧洲同时修改一条记录, 如在新加坡 set a=1, 在欧洲 set a=2, 结果 a 是多少?

我的回答是:

可能是 a=1, 也可能是 a=2.

然后提问者会非常困惑和不满:

你不是说数据库是强一致的吗? 为什么结果不确定呢?

我非常理解他的困惑, 但是, 他所提到的"并发操作"和"一致性"并没有必然的联系.

并发
...

ideawu 2021-04-24 10:08 | 查看: 89

再谈 Paxos 和 Raft

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

实际上, 许多人认为 P
...

ideawu 2021-04-18 11:59 | 查看: 87

面向全球的应用的系统架构

某些产品是面向全球用户的, 所以会在全球多个机房部署业务进程(Service)和数据库(Database). 这带来了所谓的数据一致性问题. 以用户加好友功能作为例子:

用户 A 在中, 在 App 中向用户 B 发送了好友申请. 用户 B 在美国, 打开 App 刷新, 没有看到有任何未处理的好友申请…

这是一个非常典型的例子. 我们仔细分析一下问题出在哪.

首先, 用户 B 刷新 App
...

ideawu 2021-04-17 18:25 | 查看: 114

并发编程的核心技术 – 多版本(Multi Version)

在单机编程时代, 每一项数据只有唯一的一份, 对数据的修改也是 in-place 的. 但是, 在并发编程领域, 包括分布式系统, 数据多版本(Multi Version, Versioning)是核心.

我们先从单机编程的内存操作出发. 对于内存的操作, 都是原地(in-place)更新的. 对象和内存空间强绑定, 当更新对象时, 是将对象的内存空间擦除然后用新数据写覆盖. 到了多线程编程时代
...

ideawu 2021-04-17 18:20 | 查看: 78

...更多...