最新 | 最热门 | 最高评价

+0  什么是分布式一致性

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

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

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

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

+0  Binlog 和 Redolog 的区别

Tag: 数据库
ideawu 发于 2021年09月02日 21:29 | 点击: 150 | 展开摘要
在开发分布式数据库的过程中, Binlog 和 Redolog 是非常重要的两个概念, 两者的作用似乎相同, 但实际上各有各的使用场景. 从多副本复制一致性的角度看, Binlog 用于强一致性, Redolog 用于最终一致性.

Binlog 可包含非幂等的指令, 例如 incr 指令. Redolog 只能包含幂等的指令, 例如 set 指令.

全球跨地域同步最终一致, 能不能复制 Binlog 呢? 绝对不行! 使用 incr 和 set 指令的组合, 在不同的地域

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

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

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

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

查看全文: http://www.udpwork.com/item/18117.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  分布式数据库异地多活不是你想的那样

Tag: 分布式 | 数据库
ideawu 发于 2021年06月23日 23:56 | 点击: 117 | 展开摘要
在分布式数据库领域, "异地多活"是一个非常诱人的特性, 被广泛用于商业广告宣传. 但是, "异地多活"未必是你所想象的那种"多活". 因为分布式数据库的三个重要特性:

多副本

多写入点

低延迟

"异地多活"占据了前两个, 根据"不可能三角"理论, 一旦选择了前两个特性, 那么低延迟便不再是一个选项, 而是一个结果, 给你多大的延迟(多慢), 你就得接受多大的延迟, 你无法选择.

这里涉及到一个基础科学思维的问题, "结果"是一种客观存在的东西, 而"选择"是一种主

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

+0  数据库内核的快照技术实现原理

Tag: 数据库
ideawu 发于 2021年06月04日 22:10 | 点击: 120 | 展开摘要
"快照(Snapshot)"是数据库领域非常重要的一个概念, 最初是用于数据备份. 如今, 快照技术已经成为数据库内核(引擎)最核心的技术特性之一. 数据库内核的绝大多数操作, 都依赖于快照, 例如, LevelDB 的每一次读取操作和遍历操作, 其内部都必须创建一个快照, 所以, 对于一个请求量非常大的系统, 数据库内核每秒种就要创建和销毁几十万次快照. 因此, 如何快速地创建和销毁快照, 成为一个数据库内核(引擎)必须要解决的问题.

本文从源头出发, 逐步推演, 探讨数

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

+0  分布式数据库系统如何做到平滑缩扩容?

Tag: 分布式 | 数据库
ideawu 发于 2021年06月03日 22:41 | 点击: 119 | 展开摘要
分布式数据库系统的缩扩容能力(后面也称迁移)是最基础最基本的特性, 但是, 要实现平滑扩容并不容易, 需要包括服务端, 客户端共同完成, 这两者只要缺少任何一方的参与和配合, 便绝不可能实现平滑扩容.

平滑迁移要解决的问题, 本质上就是故障容错处理.

客户端请求重试

请求重试是故障容错的最基础要求, 因为你永远无法避免遇到故障. 遇到故障时, 要么报错, 要么重试. 既然我们追求的是平滑, 那么, 一旦遇到故障, 绝对不能向上层反馈, 只能重试.

重试要配合服务发现,

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

+0  数据库内核的并发控制

Tag: 数据库
ideawu 发于 2021年05月30日 00:36 | 点击: 119 | 展开摘要
大部分程序员最先接触并发编程, 一般是从编程语言里的多线程和锁开始. 但是, 并发控制是一种广义的技术思想, 千万不可将眼光局限于编程语言所提供的锁. 将编程语言里的并发控制技术推广, 就能得到任何层面的并发控制技术.

以操作一个文件为例, 如果不做并发控制, 就会遇到数据完整性问题. 例如, 我们写入的一项数据, 对应着现实对象, 如果不做并发控制, 那么可能读到的是两项数据的混合体, 或者只读到一项数据的部分.

互斥锁

互斥锁是最简单的并发控制技术, 无论读还是写,

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

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

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

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

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

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

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

Tag: 分布式 | 数据库
ideawu 发于 2021年05月08日 22:42 | 点击: 156 | 展开摘要
系统结构

request
client -------> server

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

request write
client -------> serv

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