笔记 - 数据密集型应用系统设计

共识就是让一群不靠谱的机器，对某个值或操作顺序达成一致。它等价于线性化的 CAS、共享日志和原子提交。共识算法通过领导者 + 法定人数投票，实现了自动故障转移，避免了脑裂和数据丢失。

如果你曾经尝试在分布式系统中给数据记录分配唯一的 ID，你可能会感到一种深深的无力感。单机时代，一个自增整数就能解决所有问题——新来的记录 ID 总比上一个大，简单明了。但到了分布式世界，有些不一样。

线性一致性是分布式系统里的一剂猛药：它让你能像单机一样思考，但代价是更高的延迟、更低的可用性和更复杂的实现。它等价于原子 CAS、共享日志、分布式锁等问题，都需要共识算法来兜底。

分布式系统迫使我们从"确定性数学"走向"混乱物理"——这个转变不是危机，而是必须接受的现实。你永远无法 100% 确定另一个节点的状态，你的时钟可能和邻居差出好几秒，你的线程可能被垃圾回收暂停一分钟。

分布式系统就像一群醉汉在玩传话游戏：网络会丢话、时钟会跑偏、人还会突然倒地装死。你永远无法百分之百确定对方听到了什么、记住了什么、是不是还活着。

分布式事务，尤其是2PC，为跨节点数据一致性提供了一套优雅但代价不菲的解决方案。它通过协调者和两阶段的承诺机制，解决了原子提交的难题，但也引入了阻塞、单点故障和复杂性等挑战。

可串行化是数据库并发控制的珠穆朗玛峰，攀登它需要权衡性能与一致性。幸运的是，现代数据库已经给了我们多种工具，让我们可以根据业务场景灵活选择。

事务隔离号称能让并发操作实现可串行化。但现实是，这种最强隔离级别太消耗性能，大家都不爱用。于是就有了各种弱隔离级别，它们能解决一部分问题，但也留下了不少坑。

事务不是自然法则，而是为了简化应用开发而创造的工具。它通过 ACID 承诺，帮你处理了各种数据错误和并发冲突，让你可以更专注于业务逻辑。

请求路由解决的是“去哪找数据”的问题，它通过协调服务动态维护分片与节点的映射，让客户端或路由层能精准定位。二级索引解决的是“按特征找数据”的问题，局部索引让写简单读复杂，全局索引让读简单写复杂。

分片的世界精彩但也危险。无论你是按范围分，还是按哈希分，最终目的都是为了让数据均匀分布，避免有人“撑死”，有人“饿死”。

无领导者复制就像一场自由的圆桌会议，没有主持人，大家地位平等。它的优点是高可用、低延迟、能容忍网络分区和节点故障，缺点是引入了数据一致性的复杂性。

在单领导者复制（single-leader replication）的世界里，一切都很简单：只有一个老大发号施令，小弟们只管照做。但现实很骨感——老大挂了怎么办？跨洋访问慢成狗怎么办？

你有没有遇到过这样的情况：在社交媒体上发了一条评论，结果刷新页面后却看不见它，吓得你以为是手滑没发出去？或者在购物网站上刚下了一单，回头再看订单记录却空空如也，瞬间心跳加速？

在分布式数据库的复制世界里，单领导者复制（Single-Leader Replication）是最经典、最常见的一种模式。它就像团队里只有一个决策者，所有重要决定都得经过他。

数据在系统里跑来跑去，像不像一群流浪的旅人？有的住进数据库，有的搭上服务快车，有的组队完成工作流，还有的被塞进邮筒寄往四面八方。今天我们就当一回数据导游，看看它们都在玩什么花样。

应用程序在变，功能在变，用户需求也在变。变不可怕，可怕的是数据格式跟不上变化：新代码读不懂旧数据，旧代码撞上新字段直接崩溃。

B树是优秀的，但它不知道经纬度，不理解轻便和便携是近义词，而现代应用的要求早就不是给我键等于42的那行了，是给我语义上像这个、空间上在这个框里、时间上在这个范围、而且用户大概率会点的那一堆

当你面对一个需要几分钟才能跑出的报表时，可以想象一下：背后的系统可能正在将数百TB的数据，通过列式存储的"刀工"、排序与压缩的"腌制工艺"、以及物化视图的"预制菜"流程，加工成一份能秒级呈上的数据佳肴

存储引擎没有绝对的好坏，只有合不合适。 下次当你设计系统时，不妨问问自己： 我更像一个"先堆再整"的懒人，还是一个"随手归档"的强迫症？