来源：https://github.com/Vonng/ddia/blob/master/ch1.md
为什么要学习数据密集型系统设计？
这本书用很简单的话语告诉我们：因为当今的系统，更多的瓶颈在数据量，而不在于计算量（cpu）。用我不多的开发经验而言，现在所开发的系统，更重要的是数据的行为（流转、存储等）
- 当前系统大多都是数据密集型
文中另一个很有启发的点：当你使用多个存储完成一个接口的实现时，你就已经是一个数据密集型的系统设计人员了。这句话是在太酷了。
- 需要思考：数据系统如何工作、为什么工作、这种运转方式中最重要的问题有那些？
第一章节 可靠性、可伸缩性、可维护性
一、概念
1. 可靠性相关概念
可靠性描述的是系统对用户提供服务的稳定性。对于一个系统而言，可靠性意味着
- 用户在预期的行为下可以得到预期的结果
- 用户在非预期的行为下，系统可以正常运行
- 此处{非预期}包括：硬件故障、软件故障、人为错误
定义中的故障是指：系统中一部分状态发生偏移。
2. 可伸缩性相关概念
可伸缩性描述：负载增长/缩小时，为了维持系统性能所作的努力。
- 描述负载
- 负载参数：描述系统当前负载的参数，不同系统的选取不同，常见参数每秒服务器的请求数量、数据库的读写比率、缓存命中率等。
- 描述性能
- 吞吐量
- 响应时间
3. 可维护性相关概念
可维护性描述系统在迭代过程中，开发人员和运维人员所需要的努力程度。（个人概念）
二、如何思考 && 如何实现
1. 可靠性
1.1 如何思考可靠性？
可靠性需要处理的就是各种故障，不要信任任何一行代码，核心的原则就是根据不同故障采取兜底手段。
在分布式/微服务场景下，可靠性的目的不再是单机的可靠性，而是整个集群的可靠性，也即灵活性 && 弹性。在分布式场景下的可靠性，更多的考虑在于让故障范围尽量减少，让恢复时间尽量加快。
1.2 如何实现可靠性？
- 硬件故障（硬盘挂了）
- 解决方案
- 冗余，堆机器
- 解决方案
- 软件故障（代码错误）
- 解决方案
- 熔断&&恢复
- 解决方案
书中还有一个分类是 人为错误，感觉这个分类没有太多意义。
2. 可伸缩性
2.1 如何思考可伸缩性
既然可伸缩性是在系统负载发生变化时对系统性能的描述，可以通过这个逻辑推演可伸缩性需要关注的问题。
系统负载增加 => 系统性能变差
- 什么性能变差？
吞吐率、响应速度 - 链路中那些组件在影响上述性能？
多个下游请求？（串行请求？没有超时时间？）
对存储组件的压力？（redis、mysql）
异步操作中，对 mq 等中间件的压力？（mq 生产、消费能力） - 如何观察具体是那部分的影响？
- 阅读代码 or 看 trace，了解链路中有多少下游？对下游的处理方式
- 查看 redis mysql 等组件的相关监控（了解的有点少
- 查看 mq 监控（mq 限流、mq 生产、消费积压情况）
2.2 如何实现可伸缩性
可伸缩性的解决方案，粗放的说就是当负载变大时，增加机器。
增强单个机器的性能（垂直伸缩）成本可能是高于增加机器（容器）的
实现伸缩性中，需要考虑的问题
- 数据存放到更多的机器上
- 如何让不同机器均衡的负载
- 如何保证机器之间数据的一致性
3. 可维护性
3.1 如何思考可维护性？
可维护性更多的是预防，核心在于系统设计原则
- 可操作性
- 简单性
- 可演化性
书中对可维护性描述相对较少
