数据密集型应用系统设计-系统设计的三个原则
date
Dec 10, 2021
slug
reading-notes-ddia-three-principles
status
Published
tags
读书
系统和网络
summary
type
Page
因为场景不同，需求不同，存在很多不同的数据系统，但所有的数据系统都应该考虑这三方面的问题：
- 可靠性 Reliability：出现意外情况如硬件软件故障、人为失误等，系统应可以继续正常运行，虽然性能可能受到影响，但确保功能正确。
- 可扩展性 Scalability：系统应该以合理的方式来匹配数据量或流量的增长
- 可维护性 Maintainability：随着时间推移会有许多新人员加入开发维护，系统应该能够适配新场景并高效运转。
也就是表示系统不仅现在能用，而且未来也能用，而且容易用还要好修理。
可靠性 Reliability
即使发生了某些错误，系统仍可以正常工作，称为系统容错 fault-tolerant 或弹性 resilient，但这是有前提和场景限制的，不可能容忍所有的错误，如地球毁灭这种情况就很难容错。注意故障 faults 和失效 failure 不完全一致，故障指偏离正常规格，失效意味着系统整体无法提供服务，容错就是通过机制避免系统从故障引发失效。故障可分为：
硬件故障
如硬盘崩溃、内存故障、停电、网线掉了等等。一般通过冗余备份和快速切换解决。
软件错误
或叫软件bug，多处于一种引而不发的状态，直到碰到特定条件才会触发。软件错误很难自动快速恢复，只能做好细节检查如资源隔离，自动重启等。
人为失误
可以在设计管理界面时做防呆设计，做正确的事很容易，但搞坏则很复杂。另外可以增加快速回滚等功能。
可扩展性 Scalability
单纯说xx可扩展或不可扩展没有意义，而应该考虑：如果系统以某种方式增长，我们应对增长的措施有哪些？
描述负载
只有简洁的描述当前负载，才能更好地讨论后续的增长，如活跃用户数、缓存命中率等等。即不可测量就不可优化。例如 twitter 2012 年发布和 timeline 的 QPS 分别为 4.6k 和 300k，为应对这种负载其采用了实时联表查和写入timeline两种方案并用的方式。
描述性能
如果负载增加会发生什么？具体来说可以思考如果负载增加但系统资源不变，性能会发生什么？或是负载增加如果要保持性能不变，需要增加多少资源。即 负载、资源、性能 三者间的关系。性能指标一般有吞吐量 throughput 即每秒处理量或响应时间 response time等。注意延迟 latency 和 响应时间 response time不一样，后者是客户端看到的总时间，前者是花费在处理上的时间。
应对负载增加
无状态服务水平扩展；有状态服务水平扩展较复杂，优先选择垂直扩展，除非万不得已不采取水平扩展。
可维护性 Maintainability
软件大部分成本不在最初开发阶段，在于这个生命周期内的持续投入，包括维护和修复、监控和故障排查，适配新平台新场景，增加新功能。为了实现这些目的这里有三个设计原则：
- 可运维性：方便团队保持系统平稳运行
- 简单性：简化复杂操作
- 可演化性：可以进行改进，或叫可修改性、可塑性