負載增長時悄然襲來的42個怪獸問題(2)

　　同步時間更久

　　需要更多的時間才能將更多的對象在應用之間進行同步。

　　在大型配置中沒有進行足夠的測試

　　因為測試裝置成本很高，所以我們實際花費在大型設置上的測試時間非常少。你在開發期間不需要接觸大型系統，所以很可能你的設計一開始就不能支持大規模的場景。

　　操作耗時更久

　　如果一個操作作用于每個對象，當更多的對象被添加進來后，該操作的耗時也將會更久。當數據表變得更大時，過去針對一定數據量足夠快速的查詢，如今的耗時也會大幅度的增長。

　　更多的隨機故障

　　在正常操作中你可能不會看到某些故障。但在一定規模下，響應將丟失，ARP請求將丟失，文件系統可能會出現某些錯誤，消息可能丟失，回復也可能丟失，等等。

　　更大的故障窗口

　　規?；瘜е旅總€環節都會耗時更久，這意味著出現故障的概率就會更大。一個數據交換協議在處理少量數據集的時候會很快，這意味著它只有很小的機會遭遇重啟或超時。但是更大的規模中，故障窗口將擴大從而第一之間就會遭遇到新問題。

　　沒有提高超時設置

　　任何超時在較小的數據集中可以有效工作，但是當數據集逐漸增長后將不再適用。就CPU饑餓問題而言，你所編寫的代碼可能還沒來得及跑，超時時間卻早已達到。

　　沒有增加重試次數

　　沒有辦法在確定故障之前為某應用指定重試次數，因為他們沒有這方面足夠的信息來支持決策。每秒4次重試是否合理?為什么不是20次呢?

　　優先級繼承

　　更久的持有大范圍的鎖將有更好的機會遭遇優先級繼承問題。

　　消費模式的打破

　　在一種規模下你可以從生產者獲取所有數據，但是在另一規模下你將會耗盡隊列的空間或內存。舉個例子：某個輪詢程序在將數據傳遞到下一個隊列之前，會一直向遠程隊列輪詢所有的數據源。當隊列中只有很少量數據項的時候該程序可以有效的運行。但是很可能因為某個功能的變更擴大了該遠程隊列中的數據項數量，這樣一來該輪詢程序將會導致某個節點內存不足。

　　監控器超時

　　100%CPU的情況將導致監控器超時。這在小規模系統中很少發生，但是在設計不良的較大型規模系統中就會發生。

　　慢速的內存泄露變成快速泄露

　　較小規模系統中不大引人注意的一個內存泄露問題在較大規模的系統中就變得影響重大。

　　原本未注意到的鎖問題變得引人注目

　　應該在適當的地方使用鎖。但是如果使用不當，該問題在較小規模的系統中也許會被人忽略。因為持有鎖的線程會在另一段產生問題的指令運行前釋放掉它長期占用的CPU使用權。但是在大規模系統中將會有更多的CPU搶占，這意味著將會有更多的機會看到不同線程對同一數據的并發訪問。

　　死鎖的機會變大

　　不同的調度模式將以不同的路徑運行代碼，所以遭遇死鎖的機會也就更大。舉個例子，當CPU使用率很高時文件系統沒有機會得到運行，而當以某種方式打破這一情形時，文件系統隨即占用了100%的CPU使用權卻再也沒有運行。

　　時間同步變糟

　　時間同步任務的優先級并不高，所以當可用的CPU和網絡資源變得更少時，不同節點的時鐘將出現偏差。

　　日志數據丟失

　　由于日志隊列容量過小從而無法應對增長的負載或是因為CPU太忙而沒有時間片給予日志記錄器分發日志數據，都將可能導致日志記錄器開始丟失數據。根據隊列的容量和類型不同，或將導致內存不足。

　　定時器沒有在準確的時間觸發

　　一個繁忙的系統無法在期望的時間觸發定時器，這將導致系統的其余部分出現一連串的延遲。

　　ARP數據包丟失

　　在高負載的CPU或網絡環境中，在主機間傳送的ARP數據包可能會丟失。這是因為數據包被發送到了錯誤的網卡，一旦更新完路由表，將不會再發生這種情況。

　　文件描述符限制

　　在一個硬件上通常都會有一個固定的文件描述符數量上限。系統設計必須將所需的最大文件描述符數量限制在該上限以內。如果取用的套接字描述符超過了文件描述符的可用池，那么涉及到大量連接(ftp，com，啟動，客戶端等等)的設計將會產生問題。規?；瘜⒖赡茉斐擅枋龇?a href='http://www.kjueaiud.com/ceshi/ruanjianzhiliangbaozheng/xqgl/' target='_blank'>需求數量的峰值。當規模增長時，描述符泄露將會耗盡可用池。

　　套接字緩沖限制

　　系統都會為每個套接字分配一定量的緩沖空間，大量的套接字可能會減少系統整體的可用內存。隨著規模增長，消息丟失也開始增長。這是因為接收消息的緩沖空間數量不足從而跟不上負載的壓力。這同樣也和優先級相關，因為一個任務沒有足夠的優先級從套接字中讀取數據。較低優先級的任務可能會被發送者一方某個高優先級任務的消息所淹沒。

　　啟動鏡像服務限制

　　一個節點的啟動卡同一時間可服務的限制為X。FTP服務器基礎設施必須限制啟動卡服務的數量，否則將造成該節點發生CPU饑餓。

　　消息次序混亂

　　你的消息系統在高負載壓力下傳遞消息的次數可能會發生混亂，這對非冪等的操作來說將產生問題。

　　協議的弱點

　　除非小心謹慎的創建應用層協議，否則規模的增長將帶來大量的問題。

　　連接限制

　　一個某種類型的中央服務器在應付十個客戶端的情況下也許綽綽有余。但是當有一千客戶端的時候，它將無法滿足到響應時間的需求。在這種情況下，平均響應時間將根據客戶端數量成線性增長，我們稱該復雜度為O(N)(“order N”)，但是若是其他更差的復雜度將會產生問題。舉個例子，我們希望一個網絡中的N個節點可以互相通信，我們可以讓每個節點鏈接到一臺中央交換服務器，這將需要O(N)條連接線?；蛘呶覀冊诿績蓚€節點之間直接建立連接，這將需要O(N^2)條連接線(確切的數字或公式通常不重要，這只跟涉及到的N的最高次有關)。

　　分層架構

　　這是一個很好的總結，所以我在此處引用了它：基于分層的架構從來就不是用來構建低延遲，高吞吐量應用的。對于多層架構，究其本質是被創建用于解決昨天的歷史問題的。從客戶端-服務器時代過渡到互聯網時代，它是可伸縮性方面最完美的解決方案。

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