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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

事件溯源与CQRS架构如一本可回溯的“操作日志”，确保数据完整性与审计追踪；DataFrame则如“数据厨房”，将信息转化为机器学习所需的矩阵格式。二者分别解决了历史回溯与灵活分析的核心问题。

你是否曾在复杂的代码库中迷失，试图理清一个函数如何被三个服务调用，而每个服务又依赖五个不同的库？或者，当你试图为AI助手构建“理解”整个代码库的能力时，是否感到传统的数据结构力不从心？

如果你曾经和数据库打过交道，那你一定听说过关系模型和文档模型这两位"大佬"。它们就像是数据库世界的"少林派"和"逍遥派"——一个规矩森严，一个灵活随性。今天就来聊聊这场21世纪开始的"模型大战"。

可靠性、可伸缩性、可维护性是系统长期存活的命脉，它们决定你的软件能否不挂、不卡、不腐化。忽视这些，你的系统离崩溃只差一次流量高峰或一个手滑的配置。优秀的代码不仅要能跑，更要能优雅地跑到最后。

本文生动剖析系统性能核心指标，揭示“平均响应时间”的误导性，强调必须用百分位数（如p99）关注尾部延迟，并提供应对过载的实用工具箱，助你构建既快又稳的系统。