设计数据密集型应用笔记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之前数据库是单个节点。
但分布式数据系统是未来的趋势。
要根据实际的问题来设计,没有银弹.
如何设计取决于负载参数,例如读写比,对于读多比不同的应用设计可能会是截然不同的.
可维护性
易操作
设计简洁
易迭代
