最新 | 最热门 | 最高评价

+0  分布式数据库系统的容错处理 – 100% 成功率, 超时和性能

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

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

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

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

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

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

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

+0  并发编程两原则

Tag: Computer System | 分布式
ideawu 发于 2021年06月26日 20:17 | 点击: 383 | 展开摘要
之前写过一篇文章, 并发编程的核心技术 – 多版本(Multi Versioning), 本文继续对并发编程做一次更全面的总结, 这样的总结并非具体的编程指导, 而概括性的理论, 是笔记性质的.

根据经验总结, 并发编程的指导思想可以总结为两个原则, 也即并发编程两原则:

Sharding

Leveling

Sharding

Sharding 技术常见于分布式系统, 如果我举一个编程技巧里常用的技术, 估计你会比较熟悉 - 哈希锁. 例如 Java 语言里的 Con

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

+0  分布式数据库异地多活不是你想的那样

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

多副本

多写入点

低延迟

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

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

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

+0  Multi-Master-Paxos: 3

Tag: algo | distributed | replication | paxos | multi-master | multi-leader | active-active | 分布式 | 多活 | 多主
张炎泼(xp) 发于 2021年06月14日 08:00 | 点击: 448 | 展开摘要
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  可靠通信的三条基本定理(可靠通信三原则)

Tag: Computer System | 分布式
ideawu 发于 2021年06月06日 13:50 | 点击: 493 | 展开摘要
"通信"是一个广义的概念, 不仅限于计算机网络通信, 任何抽象或者具体的对象间的交互行为, 都是一种通信. 对象间一旦进行通信, 便有可靠通信的需求. 可靠通信至少包括三项要求:

不丢包

不重复

完整性(原子性)

为了达到这三项要求, 对应有三条定理(可靠通信三原则):

定理一(丢包定理): 确认和重传是解决丢包的问题唯一正确方法

定理二(去重定理): 排队(串行化)是解决去重问题的唯一正确方法

定理三(原子定理): 单点标记或者循环自校验是实现完整性(原子性)

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

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

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

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

客户端请求重试

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

重试要配合服务发现,

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

+0  分布式系统升级所遇到的问题

Tag: 分布式 | 算法
ideawu 发于 2021年05月28日 21:09 | 点击: 370 | 展开摘要
常规的单机软件升级, 一般认为是一个原子操作, 也就是说, 软件会在"瞬间"完成升级, 即使不能在"瞬间"完成升级, 也要中断服务, 等升级完成后再提供服务.

对于需要中断服务的情况, 在分布式系统中是不能接受的. 同时, 分布式系统的升级永远不可能在"瞬间"完成. 因此, 分布式系统升级会面临一个长时间的中间态, 新旧版本的软件同时运行, 这就涉及到兼容性问题.

假如, 新版本的软件的数据格式改变了, 那么, 新版本写入的数据就无法被旧版本识别, 旧版本就会报错. 因为

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

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

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年05月21日 23:07 | 点击: 946 | 展开摘要
有一些文章, 包括 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 | 点击: 468 | 展开摘要
系统结构

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

+0  Raft 协议和区块链

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年05月08日 22:19 | 点击: 519 | 展开摘要
我还没有发现有人把 Raft 协议和区块链关联到一起讨论, 但是经过仔细分析, 穿透问题的本质之后, Raft 和区块链技术具有非常多的共同点. 可以整理出一个表格:

Raft
区块链
通用

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

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

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

Term
分叉
Branch

基于 Quorum 立即 Commit
立即相信最长的链条
C

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

+1  数据库事务ACID和锁

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

从用户的角度看, 如果数据库不提供事务, 他就要多写代码, 这让他很不爽. 所以, 即使是 KV 数据库, 也应该提供事务功能. 但是, 不仅事务功能的实

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