最新 | 最热门 | 最高评价

+1  数据库事务ACID和锁

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

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

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

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

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年04月30日 22:25 | 点击: 173 | 展开摘要
日志复制状态机模型是 Raft 协议里的一个基础概念, 用于保障多副本一致性. 这个概念并非 Raft 独创, 而是由 Raft 具体总结和推广的, 在 Raft 之前, 像 MySQL 的 binlog 等等, 都是广义的日志复制状态机模型.

采用日志复制状态机模型的系统, 把多副本一致性问题分解成两个部分(模块), 第一部分是日志本身的一致性, 第二部分是状态机(例如数据库引擎)的数据一致性. 这两个系统模式是独立运行的, 它们之间的通信(Apply)也是异步的. 由此

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

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

Tag: 分布式 | 数据库
ideawu 发于 2021年04月30日 00:41 | 点击: 162 | 展开摘要
像 MySQL 这样的传统关系数据库, 没有提供数据过期自动删除功能(TTL), 因为从常规理解, MySQL 是一个持久化数据库, 不是缓存系统, 数据应该由用户主动地通过 DELETE 指令显式地删除. 不过, 从实践经验上看, 由数据库系统提供基于过期时间自动删除数据(TTL)的功能, 可以减少用户(应用开发者)的工作量. 所以, Redis, SSDB, MongoDB 这些新开的 NoSQL 数据库都提供了 TTL 功能.

TTL 功能非常有用, 能节省用户的工作

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

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

Tag: 分布式 | 数据库
ideawu 发于 2021年04月24日 10:08 | 点击: 106 | 展开摘要
作为分布式强一致数据库的开发者, 被多次问到:

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

我的回答是:

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

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

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

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

并发

Martin Kleppmann 提到并发(Concurrency)的定义:

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

+0  再谈 Paxos 和 Raft

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

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

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

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

Tag: 分布式 | 高性能Web架构
ideawu 发于 2021年04月17日 18:25 | 点击: 128 | 展开摘要
某些产品是面向全球用户的, 所以会在全球多个机房部署业务进程(Service)和数据库(Database). 这带来了所谓的数据一致性问题. 以用户加好友功能作为例子:

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

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

首先, 用户 B 刷新 App, 没有看到任何好友申请, 算是一个问题吗? 看不到好友申请, 本身不算问题,

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

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

Tag: C/C++语言编程 | Computer System | 分布式 | 数据库 | 算法
ideawu 发于 2021年04月17日 18:20 | 点击: 103 | 展开摘要
在单机编程时代, 每一项数据只有唯一的一份, 对数据的修改也是 in-place 的. 但是, 在并发编程领域, 包括分布式系统, 数据多版本(Multi Version, Versioning)是核心.

我们先从单机编程的内存操作出发. 对于内存的操作, 都是原地(in-place)更新的. 对象和内存空间强绑定, 当更新对象时, 是将对象的内存空间擦除然后用新数据写覆盖. 到了多线程编程时代, 就引入了锁机制, 因为擦除和写操作过程不是原子性的, 可能擦除到一半时, 就

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

+0  分布式系统中的先后顺序问题 – 逻辑时钟, 原子钟和停止等待

Tag: 分布式
ideawu 发于 2021年04月16日 21:47 | 点击: 121 | 展开摘要
分布式系统中的一致性问题, 本质就是操作的先后顺序问题. 先后顺序, 纯朴的理解就是时间的先后, 也即时钟的先后. 众所周知, 时钟受许多因素影响, 例如观察者, 时钟源(钟表, 系统时间), 时钟同步等等, 单纯依赖时钟的读数来区分先后顺序, 会造成许多的问题.

以银行转账为例子.

在一个虚拟的银行系统中, 用户直接修改离自己最近的银行的数据库, 而数据库本身会自动地将修改同步到其它地点.

中国的用户 A 在中国的数据库里修改了自己账户的余额, 扣减 100 元, 同

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

+0  200行代码实现基于paxos的kv存储

Tag: algo | distributed | replication | paxos | kv | 分布式 | 存储
张炎泼(xp) 发于 2020年10月28日 08:00 | 点击: 83 | 展开摘要
前言

写完 paxos的直观解释 之后,
网友都说疗效甚好, 但是也会对这篇教程中一些环节提出疑问(有疑问说明真的看懂了

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

+0  后分布式时代: 多数派读写的’少数派’实现

Tag: algo | distributed | quorum | majority | replication | paxos | raft | 分布式 | 多数派
张炎泼(xp) 发于 2020年10月18日 08:00 | 点击: 89 | 展开摘要
前言

paxos可以看做是2次 多数派读写 完成一次强一致读写. 多数派要求半数以上的参与者(paxos中的Acceptor)接受某笔操作. 但 多数派读写 并不一定需要多于半数的参与者, 分布式系统中某些场合的优化, 可以通过减少参与者数量来完成的.

多数派读写:分布式系统的基础

分布式系统中, 其中一个基础的问题是如何在不可靠硬件(低可用性)基础上构建可靠(高可用性)的服务,
要达成这个目标, 核心的手段就是复制(例如一份数据存3个副本).
而复制过程中的一致性

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

+0  可靠分布式系统-paxos的直观解释

Tag: algo | distributed | consensus | fault-tolerant | quorum | replication | paxos | 分布式 | 一致性 | 容错 | 多数派
张炎泼(xp) 发于 2020年06月01日 08:00 | 点击: 81 | 展开摘要
前言

paxos是什么?

在分布式系统中保证多副本数据强一致的算法.

paxos有啥用?

没有paxos的一堆机器, 叫做分布式;

有paxos协同的一堆机器, 叫分布式系统.

Google Chubby的作者Mike Burrows说过:

这个世界上只有一种一致性算法,那就是Paxos …

其他一致性算法, 都可以看做paxos在实现中的变体和扩展.

另外一个经常被提及的分布式算法是raft, raft的贡献在于把一致性算法落地.
因为 Leslie

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

+0  2PC之踵?是时候升级二阶段提交协议了

Tag: 分布式
Tim 发于 2019年01月28日 10:32 | 点击: 1401 | 展开摘要
感谢读者,能看到这篇文章,也许是通过 RSS 订阅或者是博客首页来的。博客过去很长时间没有更新,大部分随想都发表在微博,由于发的内容大多是碎碎念,建议大家也不用专门去拜访。在 2010 年时候,曾写过一篇多IDC的数据分布设计的文章提到过 2PC 等协议,最近在 Hackernews 上又有很多有关优化 2PC 讨论,讨论的源头主要由下面这篇文章引起的,因此作了翻译,供大家参阅。

两阶段提交协议(2PC)已经在企业软件系统中使用了三十多年。它是一种非常有影响力的协议,用于确

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