乐趣区

关于读书:数据密集型应用系统设计-应用系统概览

《数据密集型利用零碎设计》– 利用零碎概览

引言

零碎利用概览是纯理论的局部尽管很简略,然而看完之后发现其实很多时候有一些术语在本人的观点外面是很狭窄的,作者在书中用了更加谨严的解释话语阐述一些软件和零碎设计中常见的问题。

书中提到的一些试验和理论案例都比拟有意思。也因为是第一章,内容通常不会一上来就会很难很干燥,也是比拟有意思的一个章节。

介绍

古代利用设计更加趋势单一化和模块化,古代信息系统到数据量极速收缩,换来的是数据简单和各模块多变,利用零碎通常须要蕴含上面的内容。

  • 数据库:存储数据。
  • 高速缓存:为简单操作缩小操作代价,比方 CPU 的高速缓存,硬盘缓存等。
  • 索引:建设数据疾速搜寻和过滤。
  • 流解决:异步形式与另一个过程通信。
  • 批处理:解决大量累积数据。

重新认识数据系统

在一个数据系统的架构中,咱们通常会判断一个利用零碎的三种个性反对,这三种个性即:可靠性、可扩大,可维护性

可靠性

所谓可靠性不单单指的是零碎能在产生异样的时候能够失常运行,实际上蕴含更多内容:

  • 利用该程序执行用户冀望性能。
  • 容忍谬误数据或者不正确的操作。
  • 正当到零碎负载和开释性能。
  • 权限治理。

简略来说这样到可靠性指的是程序上的牢靠和零碎架构上牢靠以及保证数据的安全性。

另外还须要对于一些和可靠性紧密联系并且常见的术语做出更为严格的解释:

  • 容错:所谓容错不是指容许肯定的谬误,而是指 在预感的前提下容许某些特定的问题产生
  • 故障和生效:故障是指组件偏离原始设定的状况,零碎存在复原可能,而生效则是指的整个业务零碎瘫痪并且将无奈提供服务。

    • 打消故障很难,然而更多状况下并不是无奈解决问题,而是由解决问题到程序产生问题,也就是 BUG 上叠加 BUG。
    • 有一些方法来检测修复零碎自身是否“失常”,在过来 Neflix 的 Chaos Monkey,直译过去就是吵闹的猴子,这个组件通过模仿一些常见故障检测零碎问题,尽管比拟小众然而比拟有意思。

拓展:
对于很多小团队和小我的项目而言 Simian Army 可能没有太多的意义,但 Chaos Monkey 背地的思维值得咱们学习和应用。
Chaos Monkey 中次要蕴含了上面的内容
1、Exception Assault(抛出异样攻打)
2、Kill Assault(杀过程攻打)
3、Latency Assault(提早卡顿攻打)
4、Memory Assault(内存溢出攻打)
能够看看 Simian Army 我的项目:Netflix/SimianArmy · GitHub。如果你能拜访 slideshare,也能够看看这个 slides:RE: invent: Chaos Monkey。

  • 硬件故障:硬件故障个别是通过增加备用组件以备不时之需,比方 RAID 硬盘,锂电池,异步容备等,为了实现可靠性同时保障高可用都必不可少,然而这几年通过软件容错到形式逐步变成新伎俩,比方降级补丁通过轮流下多节点形式,实现不毁坏集群状况下降级。
  • 软件谬误:软件谬误更多指的是长期暗藏而不被发现到 BUG,尽管谬误到概率比拟小,然而一旦出错将会是非常复杂的排查流程。针对软件可靠性保障是永远将信将疑的不牢靠,哪怕看似“永远”不可能错处的中央也须要做一些监控和进攻措施,这样能够保障问题产生能够第一工夫排查。(这句话很重要)
  • 人为失误:越是简单的环节越是容易出错,上线的流程由一个人负责根本只会呈现在一些垃圾公司外面,凡是正规流程公司都有相似严格或者不那么严格的上线过程,然而上线配置却经常是零碎上线运行更新最有可能遇到到人为失误。

可靠性的保障意味着开发和经营老本的高下,所以是最为值得关注的事件。

可扩展性

如何形容性能

可扩展性在书中提到了推特对于 微小扇出构造 的解决方案,这种构造的典型体现是某个用户受到海量到关注,之后当被关注用户公布新的内容会扇出微小的申请,以此来反对海量音讯公布的需要。

这种构造显然是典型的海量的单节点公布订阅和播送呈现的业务场景,针对推特中百万粉丝的博主推送和小众主播的推送解决方案是上面两种:

  • 如果是关系型数据库解决方案,是依照关注者关注工夫程序挨个推送新推文。
  • 采纳缓存的形式进行推送,推送用户的时候如果依据缓存找到同一指标,则间接取缓存推送,这样就缩小了不少的零碎开销。

这两种都存在肯定的问题,第一种是会加剧读负载压力,第二种尽管显著能解决第一种的问题,然而显著存在节约,最终扩大是发现联合两种状况,对于关注人数较少的用户齐全能够应用第一种计划实时更新,然而对于关注量非常宏大的用户则须要第二种形式。

所以能够认为针对扩展性阐明是在不同解决方案之间寻找平衡点。

所谓到平衡点则须要思考上面两个因素:

1. 业务增大须要扩大多少机器维持原有性能。
2. 系统资源不变的状况下如何维持性能。

提早和响应工夫差别?
差别次要是响应工夫会蕴含一个服务器从申请到返回那一刻所破费的工夫,所以这里须要算上网络开销。
而提早体现在解决工作的时候用了多久。
这里举个例子:咱们上传文件从上传按钮点击到返回正确后果的那一刻所破费的全副工夫叫做响应工夫,而提早指的是期待上传动作自身花了多久。

那么应该如何掂量性能指标,咱们通常会应用均匀响应工夫作为参考,然而均匀响应工夫实际上不能还原性能。

论断是应该通过 中位数 + 响应工夫 排序的伎俩判断性能,依照用户的响应工夫按照大小排序进行解决。

这里有另一个案例是亚马逊依据用户购物拜访网站的响应工夫,响应工夫 1S 和销售额的影响。

对于一个申请的优化,在初期把 2 -3S 实现的工夫升高到 1S 是十分无效的,然而到 1S 以内的优化,比方优化 99% 的称心申请和 1% 的不称心申请,优化到最初 1% 的代价要远高于理论的收益,所以这时候须要转化思路而不是在旧办法方死磕。

所以可扩展性的优化指标目标不是为了极致优化,优良的优化是对数回升的过程,达不到这个指标就要思考老本以及是否值得持续进行。

为了察看系统优化,在进行负载测试的时候申请生成端不能是阻塞式而必须是并发形式,否则会存在测试误差。这句话意思是说在任何测试之前须要保障测试和正当并且牢靠的。

负载减少扩大

如何应答扩大减少,目前探讨较多的状况为垂直扩大和程度扩大,垂直扩大指的是降级旧系统配置,程度扩大则认为是部署更多的机器分担负载。

少数状况可能认为多台性能个别的机器强过多数几台强劲的机器,实际上如果保障架构足够强劲,只须要几台性能不错的服务器就能够抵掉多台服务器作用的成果,并且程度扩大到肯定水平之后是无限的。

在垂直扩大和程度扩大中又分为有状态节点扩大和无状态节点扩大。

有状态节点更为通常的做法是应用一台高性能服务器利用单机负载服务申请(留神这里的服务仅仅只应用程序服务),当单点服务无奈撑持之后才会思考应用程度扩大的计划。

无状态节点的扩大则更偏向于程度扩大的形式,所以通常须要多个机器或者应用主备备份的形式进行容灾解决。

而将来利用很有可能是面向分布式的架构,古代的分布式编程接口和框架架构在不断完善。

最初一点是针对雷同吞吐量的机器随着业务场景的不同会有齐全不同的架构设计,可扩大的构造通常意味着组件之间的独立和自身的可扩展性,就像是 TCP/IP 模型个别。

然而一旦确立业务架构,后续须要调整架构的代价就会越来越高。

可维护性

可维护性蕴含可运维,简略性和可演。可运维指的是在日常工作中能够通过经营团队维持零碎稳定性,简略性既是能用最简洁的逻辑实现需要,还须要保障经营人员可能简略应用,也就是功能完善和零碎残缺,

总结

这三大个性实际上都指向一个特点:让运维人员更好地保护零碎,因为无论多能够本人化的零碎,最初还是须要运维人员实现保护操作。

另外,为了实现零碎的简略性,不得不引入形象来解决问题,高级语言也是应用形象来覆盖 CPU 寄存器,汇编代码,零碎调用复杂性等内容。

使用越宏大的零碎越须要形象的思维,在古代的零碎中为此设置了麻利开发模式,测试驱动凋谢模式以及重构,两个凋谢模式从国内环境来看滥用的趋势还算是比拟多的,所以咱们更应该关注重构的利用。

对于重构的细节,都能够在《重构》这本书当中进行理解。

写在最初

第一章探讨了可靠性、可扩展性、可维护性的实践概念,同时梳理了以后时代下各个利用零碎所应答的挑战,并且展望未来随着分布式架构的代码成熟和技术欠缺,哪怕是微笑我的项目也有可能玩上分布式,并且可能就会在不久的未来 ……

关联

零碎减速:阿姆达定律

外围:假如程序划分为两局部:不可并行局部和可并行局部。

解释:

假如一个磁盘中的程序加载到内存中,扫描目录并且进行创立文件。扫描目录和创立文件列表的局部不能并行化,但解决文件能够并行。

那么依据下面的阐明,咱们能够定义上面的变量:

  • T = 串行执行的总工夫
  • B = 不能够并行的总工夫
  • T- B = 并行局部的总工夫

从公式来看,T-B这部分工夫是真正能够并行并且通过进步 CPU 或者线程性能的优化工夫。当多个 CPU 和线程执行并行局部的时候计算公式为:

T(N) = B + (T – B) / N(N 为处理器或者 CPU 数量)

这里咱们不须要记住简单的公式,咱们只须要晓得这个阿姆达定理解释了要优化一个程序的性能,性能的晋升远不如咱们设想中的那么多,软硬件以及设施 IO,内存等每一项都有可能影响程序的性能,同时单项性能优化成果可能并不显著,在进行优化的时候也须要依据理论状况多方位的思考。

更多的参考资料

英文原版网站:http://tutorials.jenkov.com/java-concurrency/amdahls-law.html

中文介绍:http://ifeve.com/amdahls-law/

另外,阿姆达定律提供了上面的优化形式细节:

  • 线程级并发(超线程技术)
  • 指令集并行(流水线技术)
  • 单指令多数据并行
  • 超线程技术
退出移动版