Scalability
客户端应该去计算什么?
这是一个很有意思的话题:随着计算机技术的发展,客户端的计算能力越来越强。想要提高在服务器端运行的系统的负载能力,最直接有效的办法就是把计算任务尽可能交给客户端去做,并减少两者之间的交互;然而,另一方面,这样做又可能会带来一些其他问题,例如,客户端完成某些计算任务的时候可能会比较慢(因为在客户端可以用到的资源比较少,想要保持兼容性最好的办法就是只使用普适的Java Script子集),或者,作为安全系统的一个最基本的原则,任何来自外界的数据都是不应被信任的,等等。
阅读全文…可伸缩性 Scalability
关于Scalability这个词的中文译法,目前还没有一个非常确切的定论。一些文献中将其翻译为"可扩充性",而"扩充"指的主要是Scale up;而在一些实际的用法中,Scalability还包括Scale down,因此,“可伸缩性"也许是比较贴近原文意思的说法。
互联网应用的可扩充性体现在两个方面:其一,是能够对系统容量进行扩充,也就是说,这个系统各个组件能够提供的服务的量,能够在需要的时候予以扩充(特别是通过添加新的服务器等等)。其二,是这种扩充是有效率的扩充,即,增加硬件投入时,其投入与所产生的效果是接近甚至达到成比例增加的。通常说来,“可扩充"同时暗含的需求是用户的使用习惯尽可能保持不变。如果我们关注某一具体的计算节点,可扩充性还应体现于提高计算节点性能,例如增加其CPU数量或内存容量时,能够相应地改善系统的容量或响应时间,等等。
而另一方面,“可缩减性"主要指的则是说一套系统能够运行在尽可能少的软硬件环境之中。对于大型互联网公司而言,这一点可能并不重要,而对初创公司来说这一点则非常重要。
在设计互联网应用的时候,充分地考虑系统的可伸缩性,能够极大地减少日后的维护开销,并帮助决策者对于投资所能获得的回报进行更加精准的估计;另一方面,高可伸缩性的系统往往会具有更好的容灾能力,从而提供更好的用户体验。
与解决很多其他问题类似,改善可伸缩性最常用的方法就是分治法(Divide and Conquer)。分治属于大道理一类,在实践中,我们比较常用的分治策略包括:
- 提高计算的可并行度。简单的计算,例如连续执行的加法,可以将中间结果的计算并行完成;而复杂一些的计算,例如搜索,也可以通过类似的方式分派到不同的单元中进行,并最终在另外的地方完成汇总。这种策略,比较适合于数据集中数据之间直接关联度不大、生成数据集比输入数据集小很多,并且汇总计算本身引起的开销较小的情形。
- 增加能够完成同一类任务的计算/服务单元数。这类做法中,计算/服务单元仅仅完成某种将输入变换为输出的工作,并且,这类工作不太依赖于其与外界交互产生的状态,简而言之,对于输入数据,计算/服务单元能够自行完成一个环节的计算任务并给出输出。这种策略比较适合于存在,或可能成为瓶颈的位置。举例来说,对于读多写少的应用,通过适当增加cache环节(这些cache是全冗余的,也就是不同的机器之间可以完全地相互取代),就能够有效地提高其负载能力。
- 消除单一故障点/瓶颈。如果一个系统中某些数据只存在一份,或某种计算只能在某一点上完成,那么这些环节就会成为单一故障点,或性能瓶颈。消除这类问题需要更巧妙的设计,简单地将数据复制到更多的机器上并不能够从根本上解决问题,因为在这种结构中"主"节点仍会成为瓶颈。有时,为了达到这个目的需要进行一些折衷设计,例如分段提交的方法,在容忍一部分竞态条件(race condition)的前提下避免另一些、不能容忍的竞态条件。这类做法往往会导致局部吞吐量受到负面影响,或使设计变得复杂。