设计数据密集型应用笔记1:可靠 可扩展可维护的应用

原书地址:Designing Data-Intensive Applications, 1st Edition
之前群里有人推荐,再在safaribooksonline上有60多个好评就先看了一章,阅读体验良好,这边记录一下笔记.
似乎之前看到过图灵社区在招这本书的译者,不过那时候可能都读了很多了.
主要是笔记的性质,记录一下概要和重要概念,有兴趣的可以购买阅读或者订阅safaribooksonline,此外作者在github放出了这本书所有章节的引用,看了些第一章的引用都是很不错的资料,或许可以不看这本书直接看提供的资料也可以(笑


现今的很多应用都是数据密集型的应用,CPU很少是应用的限制因素,而数据量,数据复杂度和数据产生的速度是更大的问题.

身为开发不仅仅知识和开发应用程序,还需要设计数据系统。

应用的设计需要考虑以下几个方面:

  • 可靠性: 系统在面对问题(软硬件 人为问题)时依旧可以正常工作
  • 可扩展性: 可以应对系统的增长(数据量 传输量和复杂度)
  • 可维护性

可靠性

错误(fault)和失败(failure)不等价

错误常常定义为一个组件偏离了他的规范(例如非预期的不正常运行)

失败是指系统作为一个整体停止了其服务

硬件错误

例如硬盘的平均失败时间(MTFF mean time to failure)

应对方式:

  • 增加冗余存储 RAID
  • 电源保障 UPS
  • 热替换CPU
  • 服务备份

软件错误

一般认为硬件错误是随机的.
如果是因为硬件问题,一台机器的硬盘坏了不一定暗示了其他机器的会坏,错误之间常常弱相关.

而软件bug则会因为特定条件被触发,带来的问题可能会更严重,也更难排查.

人为错误

最主要的错误来源.

应对方式:

  • 做设计时尽量减少产生错误的机会,例如更友好的管理界面。
  • 将容易产生失误的地方和造成错误的地方解耦,沙箱环境。
  • 测试,从单测到系统集成测试到人力测试。
  • 快速且容易的恢复机制。
  • 设置详细且清晰的监控,例如性能指标和错误率。
  • 优秀的管理和训练。

可扩展性

如何应对不断上升的负载.

描述负载

首先要能简明地描述当前系统负载,不然无法讨论负载增长的问题.

可以使用一些数字来描述:负载参数(load parameter)

选择的参数取决于系统架构:

  • 对于web服务来说可以是QPS
  • 对于数据库来说是读写比
  • 对于聊天室来说是并发活跃连接数
  • 对于缓存是命中率

描述性能

描述好负载之后就可以研究在负载增加的时候系统的表现如何.
可以从两方面考虑:

  • 系统资源(CPU 内存 网络带宽)不变的情况下系统受到的影响。
  • 需要增加多少资源来保持性能不受到影响。

性能指代:对于处理系统例如hadoop来说是吞吐量,对在线系统来说是响应时间.

响应时间-百分比 几个9
要考虑可能最慢的请求是因为数据过多,而大量数据的用户则是核心用户.
百分比常常用于SLO(service level objectives)和SLA(service level agreements)

处理负载的方式:

scaling up 和 scaling out
垂直扩展会变得昂贵
需要考虑一个合适的方式,一些情况下几台高性能机器会比一堆低性能虚拟机更加简单和便宜.

一些系统是elastic,弹性收缩的,在负载增加时自动增加计算资源.

无状态服务的水平扩展会很容易,但如果要处理状态的话就会带来额外的复杂度。
现在一些通用的做法是在达到极限或者要满足HA之前数据库是单个节点。
但分布式数据系统是未来的趋势。

要根据实际的问题来设计,没有银弹.
如何设计取决于负载参数,例如读写比,对于读多比不同的应用设计可能会是截然不同的.

可维护性

易操作

设计简洁

易迭代