读《数据密集型应用系统设计》笔记（一）
这书买了三年，一直断断续续翻。最近通勤路上把第一部分重新读了一遍，记几点印象比较深的。
三个词
作者开篇把「好的系统」拆成三个维度：
- 可靠性：出故障的时候还能正常工作
- 可扩展性：负载增长时有合理的应对手段
- 可维护性：未来的人（包括三个月后的自己）能改得动
看起来像废话，但书里对「故障」的定义很严格：不是「系统挂了」才叫故障，偏离规格的任何行为都算。按这个标准，很多我们习以为常的「偶发超时」其实都是故障，只是没人统计。
可扩展性不是单一维度
这段我印象最深。我们平时说「这个服务能不能扩」，脑子里想的通常是 QPS。但书里说，负载要用几个数字描述：
- 每秒请求数
- 读写比例
- 缓存命中率
- 数据量和访问分布（热点）
同样的 QPS，读写比 100:1 和 1:100 完全是两个系统。之前做过一个项目，压测时 QPS 很漂亮，上线后一崩，就是因为真实流量里写比例比压测高了一个数量级。
一个反例：加机器不一定变快
书里提到「共享状态」是扩展性的天敌。加机器之后如果每台都要去抢同一把锁、或者写同一个库的同一条记录，吞吐不但不涨，还可能因为竞争更激烈而下降。
这点在现实里太常见了：扩了 8 个实例，结果 MySQL 单行更新的锁等待把整个链路拖垮。
另外一句
可维护性最大的敌人是复杂度，而复杂度往往来自「为了通用而抽象」。
读到这句的时候想起好几个过度设计的内部框架。为了「以后可能要用」，先加了三层接口，结果谁也不敢改。
下一部分讲数据模型和存储引擎，还没看完，等看完再写。