最新 | 最热门 | 最高评价

+1  数据库事务ACID和锁

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

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

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

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

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年04月30日 22:25 | 点击: 175 | 展开摘要
日志复制状态机模型是 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:25 | 点击: 137 | 展开摘要
数据库事务的原子性并不仅仅是指写操作, 还包括读操作. 对于写操作, 众所周知, 原子性是指操作序列中的所有操作要么全部成功, 要么全部失败. 但多次读操作未必是指要么全部读到要么全部读不到. 如果不是 Snapshot Isolation, 那么两次读操作, 可能有其中一次读到旧值, 另一次读到新值. 但是, 读操作的原子性要求必须满足因果性. 当读到新值之后, 就说明事务中的所有写操作都已完成, 显然, 后续的读操作必须读到新值, 不能读到旧值.

Snapshot Is

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

+0  操作的先后顺序的确定

Tag: Computer System
ideawu 发于 2021年04月24日 10:14 | 点击: 146 | 展开摘要
在计算机领域, 两个操作的先后顺序的确定, 是一个非常严肃的科学问题, 不能仅凭人的直觉来判定.

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

通信协调

绝对时间规划

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

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

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

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

如果我在新加坡和欧洲同时修改一条记录, 如在新加坡 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 | 点击: 105 | 展开摘要
我之前写过一些谈 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 | 点击: 130 | 展开摘要
某些产品是面向全球用户的, 所以会在全球多个机房部署业务进程(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 | 点击: 105 | 展开摘要
在单机编程时代, 每一项数据只有唯一的一份, 对数据的修改也是 in-place 的. 但是, 在并发编程领域, 包括分布式系统, 数据多版本(Multi Version, Versioning)是核心.

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

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

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

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

以银行转账为例子.

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

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

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

+0  Mac释放purgable空间

Tag: MacOSX
ideawu 发于 2019年01月18日 14:49 | 点击: 1429 | 展开摘要
# sudo tmutil listlocalsnapshots /

com.apple.TimeMachine.2019-01-17-191904

com.apple.TimeMachine.2019-01-18-134752

com.apple.TimeMachine.2019-01-18-141455

com.apple.TimeMachine.2019-01-18-143636

# tmutil deletelocalsnapshots 2019-01-18

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

+0  港股实时行情系统设计

Tag: 网络编程 | 高性能Web架构
ideawu 发于 2018年07月26日 16:24 | 点击: 1526 | 展开摘要
做一下记录。

做了一个可靠传输层,优点是层次分明,缺点是当丢包时价格更新不及时。可以优化成只重传不排序,Aggregator 区分是否是最新包,不是最新包则不更新最新价。

对外提供推和拉接口,两种都有适用场景,不能只提供一种。Query Server 采用 HTTP 协议,Push Server 可以用 WebSocket 协议。

把图改成 stack 形式。

Related posts:
为什么iComet比nginx-push-stream-module更好?

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