带读 |《Designing Data-Intensive Applications》(中文：数据密集型系统设计)

我在实习和工作的过程中发现技术方案的设计这一环节是后端开发散发魅力并且深深吸引我的地方，好的技术方案/架构设计 可以让整个系统开发的开发者开发更轻松 后续的维护 以及拓展更容易 遇到高并发、各种软硬件失效人为错误带来的挑战时更可靠，总而言之，这让我觉得像是在设计自己世界乐高，我对此很有兴趣，于是找到这本书。

数据系统基础

这里先给出了一个全文检索服务器的例子（之前《Go In Action》也拿搜索例子做为开篇，看来文本检索很受大家欢迎呀），，假定某个应用包含缓存层（例如Memcached)与全文索引服务器（如Elasticsearch或Solr),二者与主数据库保持关联，通常由应用代码负责缓存、索引与主数据库之间的同步，如下图所示

在设计这个系统的时候，我们需要

1. 通过缓存正确地刷新来保证客户端们看到的效果一致；
2. 系统出现局部失效的时候 保证数据的正确性和完整性
3. 系统发生降级时为客户提供一致良好的表现。
4. 负载增加时系统便于拓展
   ...

这本书主要围绕系统设计的

• 可靠性
• 可扩展性
• 可维护性
  展开

---

可靠性

• 硬件故障
  在设计系统考虑硬件可靠性的时候 我们需要考虑到 硬盘崩溃、内存故障、电网停电、网线被拔掉等情况。
  应对的方案大致有：1.添加硬件冗余
  （比如磁盘配置RAID，服务器配置双电源，热插拔CPU，数据中心添加备用电源，发电机等）2.滚动升级（后面会介绍）
• 软件错误
  特点时间值导致服务器崩溃，比如2012年6月30日发生的闰秒触发的Linux内核bug、依赖服务故障、级联故障等。
  软件错误很多时候没办法快速解决，需要在系统设计之初认真检查各种交互和依赖，进行全面测试，进程隔离，提前设计好异常告警。
• 人为错误
  经调查发现，运维人员的配置错误是某大型互联网服务下线的首要原因。
  所以在系统设计的时候，我们可以先假定人是不可靠的，用最小的出错方式来设计系统、分离出最易出错的地方、充分测试、制定出错是快速恢复机制等。

未完待续。。。

---

参考

Kleppmann M. Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems[M]. " O'Reilly Media, Inc.", 2017.