「阅读」数据密集型系统设计一

来源：https://github.com/Vonng/ddia/blob/master/ch1.md

为什么要学习数据密集型系统设计？

这本书用很简单的话语告诉我们：因为当今的系统，更多的瓶颈在数据量，而不在于计算量（cpu）。用我不多的开发经验而言，现在所开发的系统，更重要的是数据的行为（流转、存储等）

1. 当前系统大多都是数据密集型

文中另一个很有启发的点：当你使用多个存储完成一个接口的实现时，你就已经是一个数据密集型的系统设计人员了。这句话是在太酷了。

2. 需要思考：数据系统如何工作、为什么工作、这种运转方式中最重要的问题有那些？

第一章节 可靠性、可伸缩性、可维护性

一、概念

1. 可靠性相关概念

可靠性描述的是系统对用户提供服务的稳定性。对于一个系统而言，可靠性意味着

1. 用户在预期的行为下可以得到预期的结果
2. 用户在非预期的行为下，系统可以正常运行
   1. 此处{非预期}包括：硬件故障、软件故障、人为错误

定义中的故障是指：系统中一部分状态发生偏移。

2. 可伸缩性相关概念

可伸缩性描述：负载增长/缩小时，为了维持系统性能所作的努力。

• 描述负载
  • 负载参数：描述系统当前负载的参数，不同系统的选取不同，常见参数每秒服务器的请求数量、数据库的读写比率、缓存命中率等。
• 描述性能
  • 吞吐量
  • 响应时间

3. 可维护性相关概念

可维护性描述系统在迭代过程中，开发人员和运维人员所需要的努力程度。（个人概念）

二、如何思考 && 如何实现

1. 可靠性

1.1 如何思考可靠性？

可靠性需要处理的就是各种故障，不要信任任何一行代码，核心的原则就是根据不同故障采取兜底手段。

在分布式/微服务场景下，可靠性的目的不再是单机的可靠性，而是整个集群的可靠性，也即灵活性 && 弹性。在分布式场景下的可靠性，更多的考虑在于让故障范围尽量减少，让恢复时间尽量加快。

1.2 如何实现可靠性？

• 硬件故障（硬盘挂了）
  • 解决方案
    • 冗余，堆机器
• 软件故障（代码错误）
  • 解决方案
    • 熔断&&恢复

书中还有一个分类是 人为错误，感觉这个分类没有太多意义。

2. 可伸缩性

2.1 如何思考可伸缩性

既然可伸缩性是在系统负载发生变化时对系统性能的描述，可以通过这个逻辑推演可伸缩性需要关注的问题。

系统负载增加 => 系统性能变差

1. 什么性能变差？
   吞吐率、响应速度
2. 链路中那些组件在影响上述性能？
   多个下游请求？（串行请求？没有超时时间？）
   对存储组件的压力？（redis、mysql）
   异步操作中，对 mq 等中间件的压力？（mq 生产、消费能力）
3. 如何观察具体是那部分的影响？
   1. 阅读代码 or 看 trace，了解链路中有多少下游？对下游的处理方式
   2. 查看 redis mysql 等组件的相关监控（了解的有点少
   3. 查看 mq 监控（mq 限流、mq 生产、消费积压情况）

2.2 如何实现可伸缩性

可伸缩性的解决方案，粗放的说就是当负载变大时，增加机器。

增强单个机器的性能（垂直伸缩）成本可能是高于增加机器（容器）的

实现伸缩性中，需要考虑的问题

• 数据存放到更多的机器上
  • 如何让不同机器均衡的负载
  • 如何保证机器之间数据的一致性

3. 可维护性

3.1 如何思考可维护性？

可维护性更多的是预防，核心在于系统设计原则

• 可操作性
• 简单性
• 可演化性

书中对可维护性描述相对较少