负载增长时悄然袭来的42个怪兽问题(2)

　　同步时间更久

　　需要更多的时间才能将更多的对象在应用之间进行同步。

　　在大型配置中没有进行足够的测试

　　因为测试装置成本很高，所以我们实际花费在大型设置上的测试时间非常少。你在开发期间不需要接触大型系统，所以很可能你的设计一开始就不能支持大规模的场景。

　　操作耗时更久

　　如果一个操作作用于每个对象，当更多的对象被添加进来后，该操作的耗时也将会更久。当数据表变得更大时，过去针对一定数据量足够快速的查询，如今的耗时也会大幅度的增长。

　　更多的随机故障

　　在正常操作中你可能不会看到某些故障。但在一定规模下，响应将丢失，ARP请求将丢失，文件系统可能会出现某些错误，消息可能丢失，回复也可能丢失，等等。

　　更大的故障窗口

　　规模化导致每个环节都会耗时更久，这意味着出现故障的概率就会更大。一个数据交换协议在处理少量数据集的时候会很快，这意味着它只有很小的机会遭遇重启或超时。但是更大的规模中，故障窗口将扩大从而第一之间就会遭遇到新问题。

　　没有提高超时设置

　　任何超时在较小的数据集中可以有效工作，但是当数据集逐渐增长后将不再适用。就CPU饥饿问题而言，你所编写的代码可能还没来得及跑，超时时间却早已达到。

　　没有增加重试次数

　　没有办法在确定故障之前为某应用指定重试次数，因为他们没有这方面足够的信息来支持决策。每秒4次重试是否合理?为什么不是20次呢?

　　优先级继承

　　更久的持有大范围的锁将有更好的机会遭遇优先级继承问题。

　　消费模式的打破

　　在一种规模下你可以从生产者获取所有数据，但是在另一规模下你将会耗尽队列的空间或内存。举个例子：某个轮询程序在将数据传递到下一个队列之前，会一直向远程队列轮询所有的数据源。当队列中只有很少量数据项的时候该程序可以有效的运行。但是很可能因为某个功能的变更扩大了该远程队列中的数据项数量，这样一来该轮询程序将会导致某个节点内存不足。

　　监控器超时

　　100%CPU的情况将导致监控器超时。这在小规模系统中很少发生，但是在设计不良的较大型规模系统中就会发生。

　　慢速的内存泄露变成快速泄露

　　较小规模系统中不大引人注意的一个内存泄露问题在较大规模的系统中就变得影响重大。

　　原本未注意到的锁问题变得引人注目

　　应该在适当的地方使用锁。但是如果使用不当，该问题在较小规模的系统中也许会被人忽略。因为持有锁的线程会在另一段产生问题的指令运行前释放掉它长期占用的CPU使用权。但是在大规模系统中将会有更多的CPU抢占，这意味着将会有更多的机会看到不同线程对同一数据的并发访问。

　　死锁的机会变大

　　不同的调度模式将以不同的路径运行代码，所以遭遇死锁的机会也就更大。举个例子，当CPU使用率很高时文件系统没有机会得到运行，而当以某种方式打破这一情形时，文件系统随即占用了100%的CPU使用权却再也没有运行。

　　时间同步变糟

　　时间同步任务的优先级并不高，所以当可用的CPU和网络资源变得更少时，不同节点的时钟将出现偏差。

　　日志数据丢失

　　由于日志队列容量过小从而无法应对增长的负载或是因为CPU太忙而没有时间片给予日志记录器分发日志数据，都将可能导致日志记录器开始丢失数据。根据队列的容量和类型不同，或将导致内存不足。

　　定时器没有在准确的时间触发

　　一个繁忙的系统无法在期望的时间触发定时器，这将导致系统的其余部分出现一连串的延迟。

　　ARP数据包丢失

　　在高负载的CPU或网络环境中，在主机间传送的ARP数据包可能会丢失。这是因为数据包被发送到了错误的网卡，一旦更新完路由表，将不会再发生这种情况。

　　文件描述符限制

　　在一个硬件上通常都会有一个固定的文件描述符数量上限。系统设计必须将所需的最大文件描述符数量限制在该上限以内。如果取用的套接字描述符超过了文件描述符的可用池，那么涉及到大量连接(ftp，com，启动，客户端等等)的设计将会产生问题。规模化将可能造成描述符需求数量的峰值。当规模增长时，描述符泄露将会耗尽可用池。

　　套接字缓冲限制

　　系统都会为每个套接字分配一定量的缓冲空间，大量的套接字可能会减少系统整体的可用内存。随着规模增长，消息丢失也开始增长。这是因为接收消息的缓冲空间数量不足从而跟不上负载的压力。这同样也和优先级相关，因为一个任务没有足够的优先级从套接字中读取数据。较低优先级的任务可能会被发送者一方某个高优先级任务的消息所淹没。

　　启动镜像服务限制

　　一个节点的启动卡同一时间可服务的限制为X。FTP服务器基础设施必须限制启动卡服务的数量，否则将造成该节点发生CPU饥饿。

　　消息次序混乱

　　你的消息系统在高负载压力下传递消息的次数可能会发生混乱，这对非幂等的操作来说将产生问题。

　　协议的弱点

　　除非小心谨慎的创建应用层协议，否则规模的增长将带来大量的问题。

　　连接限制

　　一个某种类型的中央服务器在应付十个客户端的情况下也许绰绰有余。但是当有一千客户端的时候，它将无法满足到响应时间的需求。在这种情况下，平均响应时间将根据客户端数量成线性增长，我们称该复杂度为O(N)(“order N”)，但是若是其他更差的复杂度将会产生问题。举个例子，我们希望一个网络中的N个节点可以互相通信，我们可以让每个节点链接到一台中央交换服务器，这将需要O(N)条连接线。或者我们在每两个节点之间直接建立连接，这将需要O(N^2)条连接线(确切的数字或公式通常不重要，这只跟涉及到的N的最高次有关)。

　　分层架构

　　这是一个很好的总结，所以我在此处引用了它：基于分层的架构从来就不是用来构建低延迟，高吞吐量应用的。对于多层架构，究其本质是被创建用于解决昨天的历史问题的。从客户端-服务器时代过渡到互联网时代，它是可伸缩性方面最完美的解决方案。

原文转自：http://www.infoq.com/cn/articles/42-monster-problems