并發業務系統的實現

夏雨++朱信忠++徐慧英++顧雅麗++盧山富

摘 要 隨著互聯網技術突飛猛進的發展，網站規模的不斷擴大，數據量的增加，大數據的時代已經真正到來，性能和安全的問題也日益突出，很多技術被提出，并且用來提升網絡以及服務器的性能和安全，各種各樣的架構也應運而生，如何在高并發，高性能之中尋找一個平衡點，已經成為亟需解決的問題，很多人可能知道應對高并發要用分布式緩存，要用分布式和負載均衡。但為什么要這么用，怎么用才能用好，怎樣根據實際需求設計最適合的架構完全不懂。本文基于.net平臺，提出了并設計了支持.Net平臺的千萬級規模分布式高性能高并發WEB軟件開發架構設計方案。

【關鍵詞】互聯網技術 并發業務系統 方案設計

1 系統產生并發的業務節點

并發產生的原因：

（1）短時間大量請求競爭低速存儲設備或者競爭處理器資源。

（2）不合理的程序處理邏輯導致請求無法盡快完成。

（3）其他瓶頸，如帶寬、服務器資源等。

2 應對并發的解決方案

2.1 針對并發量不高的情況的方案——分庫分表，實質上是分布式系統的一種模式

具體邏輯如下：

將原本屬于同一臺服務器的同一個數據庫拆分到多臺服務器中，甚至可以將原本同屬于一張表的字段拆分到不同的服務器上。其目的為將一個大的讀寫請求分解到多臺服務器中，從而在異步并行執行中減少請求執行時間，以達到并發周期中可承載更多的請求。

2.2 使用分布式處理，結合CDN負載均衡技術

2.2.1 鏡像模式

將一臺服務器的鏡像副本復制到多臺服務器中，通過windows的NLB或者第三方CDN方案如nginx實現分布式處理，請求均衡。此種分布式模式在windows下只能使用NBL，因為NBL僅支持鏡像式分布式服務器集群，理論上NLB可以支持32臺服務器。

NLB模式的分布式系統的優勢在于通過負載均衡能夠充分發揮分布式系統在讀數據比較頻繁的模式下發揮最大的效益，而且彼此之間互為備份。其缺點也是明顯的，因為同一條數據的寫入（更新或者刪除等寫操作）必須通過事務在集群內每臺服務器上同步。

2.2.2 分段模式

多臺服務器通過CDN來決定數據寫入那一臺或者多臺服務器中，數據在讀取時需要在多臺服務器中輪詢，增加了數據讀取的復雜度。

2.3 使用分布式緩存技術

分布式緩存技術已經得到廣泛應用，其實現算法為平衡樹（紅黑樹），使用緩存的目的是要減少訪問服務器低速存儲設備以及I/O帶來的性能損耗，從而提高系統單位時間內的響應能力，以達到提高并發能力的目的。

分布式緩存有很多典型應用，例如聊天室。早期的聊天室沒有使用socket前，基本上使用的都是脈沖模式（服務器輪詢），不斷向低速存儲設備輪詢的成本是很可觀的。所以寫入內存當中能夠更快速的使客戶端訪問到，一旦聊天結束，服務器并不持久化聊天數據。

投注業務具有短時間集中并發寫入數據的特點，將數據寫入內存，并在內存中操作并非復雜的事情。但如涉及到數據持久化，就存在數據一致性的問題。分布式緩存解決方案redis提供了數據持久化，能夠保證數據的一致性。

實踐證明，10萬級別的并發場景中，向低速存儲設備（關系數據庫）寫入數據如果以整形為主，使用緩存和不使用緩存的差別并不明顯。

2.4 NOSQL的使用

NOSQL數據庫的數據吞吐能力可以達到關系數據庫的百倍以上，天然支持分布式模式。能夠提供高速讀寫的優異性能，提供高I/O操作。谷歌、百度、淘寶等都使用了NOSQL。

但NOSQL也并非沒有缺點，大多數應用都是關系型的，也就是要保證數據操作的原子性和唯一性，NOSQL無法保證這一點。因此多數NOSQL應用需要數據庫中間件來保證關系數據的原子性。常用的NOSQL如MongoDB、Hadoop等。

3 并發解決方案的實現

分庫分表的實現：

A：為什么要分庫分表？

在只有一臺服務器的情況下，大量的select會被同時執行的update和delete阻塞，導致并發數嚴重受限。當然，這種場景非常適合讀遠大于寫的應用，當讀寫基本相當的情況下，單臺服務器依舊存在讀寫互斥的情況，不適合并發量較大的應用。

B：分庫的作用在于多臺服務器分擔客戶端的讀寫請求，大大降低了并發的可能性。

在web應用中，通常web服務器應與數據庫服務分離，這在未來實現CDN的時候非常有意義，來自客戶端的請求基本會在web服務器之間進行分配，由web服務器根據CDN決定訪問哪些數據庫服務器。

數據庫服務器分離后，多臺數據庫服務器之間通過異步數據事務保持一致性，當然這種數據同步會有一些時間上的延遲，這種延遲基本上都是毫秒級別的。當然，低級別的分庫可以直接由邏輯層通過事務保證數據一致性。

操作系統對磁盤的讀寫有控制機制，在只有一臺服務器的情況下，各種請求競爭資源，包括對處理機及內存、磁盤等的控制權。因此，一臺服務器的并發能力是非常有限的，這也是分庫的原因所在。

3.1 關于讀寫分離

前文已提到讀寫互斥，這將給讀取數據帶來很大延遲，尤其是大量讀寫的情況下這種延遲是無法接受的。因此在讀業務場景中，應保持數據隨時處于可讀取狀態。

通過分庫、分表以達到讀寫分離的目標，讓一些（庫）表專門用來寫數據，而另一些表（庫）用來讀數據。而數據庫與數據庫之間通過數據一致性組件保持數據復制作業，如syncNavigator或者數據庫自帶的訂閱發布功能。用于寫操作的數據庫一旦有新數據寫入，則根據數據同步策略來同步數據到讀服務器（數據庫、表）中。

3.2 關于緩存

Memcached 是一個高性能的分布式內存 對象緩存系統，用于動態Web應用以減輕數據庫負載。它通過在內存中緩存數據和對象 來減少讀取數據庫的次數，從而提供動態、數據庫驅動網站的速度。

memcache會預先生成很多的內存塊，比如有96byte，120byte，150byte，200byte，800byte。

預先生成一批slab的好處是什么？可以根據item的大小，放到合適的slab上面去。

原因：找內存所消耗的時間比遠大于釋放時間。

但是Memcached對內存資源的有效利用：

（1）重復利用已經分配的內存，也就是說不會去刪除已有的數據而且釋放，而是數據過期后，用戶將數據不可見。

（2）Memcached 還是用了一種Lazy Expiration （延遲過期[姑且這樣翻譯]） 技術，就是Memcached不會去監視服務器上的數據是否過期，而是等待get的時候檢查時間戳是否過期，減少Memcached在監控數據上所用到的時間。

（3） Memcached 不會去釋放已經使用的內存空間，但是如果分配的內存空間已經滿了，而Memcached 是如何去保證內存空間的重復使用呢！Memcached 是用了 Least Recently Used（LRU） 機制來協調內存空間的使用。LRU 意思就是最少最近使用，當此處內存空間數據最長時間沒有使用，而且使用次數很少，在存儲新的數據的同時就會覆蓋此處空間。

一致性哈希

當hash遇上分布式，單臺機子的hashmap存儲已經不能滿足我們的key-value需求，怎么辦，我們需要把存儲內容分布到不同的實體機上，這時需要一種把key映射到不同機器的方法，我們想起了hash，可以把實體機當做是桶，采用和hashmap實現一樣的思路，通過和實體機的數量取模，自然映射到不同的機器。

但是這就會導致一個問題：數據分布不均勻。大部分數據都分配到server1了，只有小部分數據分布在server2。在服務器數據很少的時候，數據不均 勻會表現的非常明顯。

解決這個問題的方法是使用虛擬節點，一個真實服務器對應多個虛擬節點，所有虛擬節點按hash值分布在一致性哈希圓環上。具體實現方法可以這樣做，為真實服務器設置副本數量，然后根據各真實服務器的IP和端口號再加上一個遞增的索引數計算hash值。

如圖2所示。

分布式緩存可以解決以下幾種問題：

比如用來緩存Web 頁面的內容片段，包括HTML、CSS 和圖片等，多應用于社交網站等；

應用對象緩存：緩存系統作為ORM 框架的二級緩存對外提供服務，目的是減輕數據庫的負載壓力，加速應用訪問；

狀態緩存：緩存包括Session 會話狀態及應用橫向擴展時的狀態數據等，這類數據一般是難以恢復的，對可用性要求較高，多應用于高可用集群；

并行處理：通常涉及大量中間計算結果需要共享；

事件處理：分布式緩存提供了針對事件流的連續查詢（continuous query）處理技術，滿足實時性需求；

極限事務處理：分布式緩存為事務型應用提供高吞吐率、低延時的解決方案，支持高并發事務請求處理，多應用于鐵路、金融服務和電信等領域。

3.3 關于NOSQL

以SQL SERVER2012作為數據倉庫存儲邏輯數據，當關系型數據庫無法滿足并發要求的時候，后端增加使用非關系型數據庫mongodb作為高吞吐數據庫使用，為避免NOSQL數據庫的非原子性操作帶來的一些問題，架構使用SQL SERVER作為數據一致性中間件，以分布式緩存作為業務快速存儲載體，提高整個系統的并發響應能力。

MongoDB一個文件存儲片段最大2GB，所以隨著數量的增加，MongoDB會一個又一個增加數據存儲文件，正因為是多個文件，所以可以并行從多個文件中讀取和寫入數據，但是因為是多個文件的并行處理，帶來了高IO，也帶來了致命的缺陷，原因非常明顯，那就是關系數據庫為了保證數據的一致性，使用了原子性約束，也就是我們說的原子性操作，比如添加數據庫記錄時，不允許出現兩條數據完全相同，比如主鍵都是2，這樣的話就沒辦法唯一標識這條數據了，所以關系數據庫普遍采用了原子性（唯一性）約束，非關系數據庫和關系數據庫在這一點上的區別非常鮮明，那就是無法保證原子性操作，非關系數據庫不保證原子性，也就無法保證數據的唯一性，這樣在連表查詢時就無法獲取正確的數據，所以一般情況下都是由中間件或者關系數據庫來保證數據的唯一性，比如NOSQL數據庫專門用來讀操作，你不是I/O能力很強嗎（是關系數據庫的100倍），那你就專門用來讀，數據通過各種手段先寫入關系數據庫，然后再同步到非關系數據庫，你從關系數據庫里讀出來的數據都具有唯一性，再同步到NOSQL，寫數據庫時底層用的是socket，來監聽多個異步操作是否返回了正確的結果。如果是則萬事大吉，如果不是，則向緩存拿數據再次寫入數據庫，直到寫入為止，除非有新的請求告訴你丟棄這個操作。最后再同步到NOSQL來讀。

參考文獻

[1]包立輝，黃彥飛.高并發網站的架構研究及解決力案[J].計算機科學，2012，39（10）：184-187.

[2]薛質.電子商務平臺的性能優化和高可靠性研究與實現[D].上海：上海交通大學，2007：41-45.

作者單位

浙江師范大學 浙江省金華市 321004