上一篇文章中講到了分布式部署之后，各個模塊要通過網絡進行通信，那么如何通信，用什么協議呢？
可選的方案有http tcp/ip(socket)等
http短連接通信方案
基於http協議，xml報文傳輸
客戶端具體框架為httpclient，服務端為struts2
客戶端和服務端的通信在內網
該方案我們實行過一段時間，發現存在性能問題，首先是短連接，在並發量較大的時候，開啟大量的tcp連接，這樣連接資源容易耗盡，客戶端首先成為瓶頸，tps上不去。
我總結的幾點原因：
1.每次通信都重新開啟新的tcp連接，握手協議耗時間
2.tcp是慢啟動，TCP 數據傳輸的性能還取決於 TCP 連接的使用期（age）。TCP 連接會隨着時間進行自我“調諧”，起初會限制連接的最大速度，如果數據成功傳輸，會隨着時間的推移提高傳輸的速度。這種調諧被稱為 TCP 慢啟動（slow start），用於防止因特網的突
然過載和擁塞
3.http協議是在tcp協議上封裝了一層，因此還存在解析協議的消耗，如果直接用tcp協議進行傳輸，效率將要高一點
據說http1.1可以實現長連接，但是沒有用java客戶端試過，后續再研究
4.短時間內開啟過多的連接，容易將系統資源耗盡
Mina長連接通信方案
主要開發任務在客戶端，我是用Mina做的長連接異步通信，
我自己編寫代碼實現了一個，有時間貼出來分享一下，如果有想了解Mina使用技術的，可以先看我的Mina系列博客http://www.cnblogs.com/tangyanbo/p/4297377.html
這里我做了相關的性能測試，下面把測試結果貼出來一下：
短連接測試
場景描述
socket 發送消息到服務端，接收到響應后關閉
結果：
一段時間過后，會出現死掉的現象，連接會被耗盡
| 服務器cpu |
2線程 3000Mhz |
| 服務器cpu使用率 |
110% |
| 客戶端cpu |
4線程 2400Mhz |
| 客戶端cpu使用率 |
95% |
| 客戶端執行線程數 |
500 |
| 每秒並發數 |
1800 |
長連接異步通訊測試
場景描述
客戶端開啟2個長連接，與服務端通信
| 服務器cpu |
2線程 3000Mhz |
| 服務器cpu使用率 |
100%-150% |
| 客戶端cpu |
4線程 2400Mhz |
| 客戶端cpu使用率 |
60% |
| 客戶端連接數 |
2 |
| 客戶端執行線程數 |
500 |
| 每秒通過事務數 |
16000 |
性能明顯提升，而且狀態穩定，cpu利用率較低
這里大家會有個問題，為什么要用異步通信，不能是同步
這里其實我們先要搞清楚什么是同步通信，什么是異步通信
同步通信
同步通信應該很好理解，這里我們以同一個socket連接為例，即多次請求都是從一個socket連接發送出去的。
Socket客戶端發送一個請求，等待響應成功之后，再發送另一個請求，即在同一時間只能發送一個請求，假如我們的場景是這樣的，發送的報文較小，服務端處理的速度較快，我們網站的大多數業務請求都是這樣的，這樣報文在網絡中傳輸的時候，通道是很空閑的，通信的吞吐量將收到影響。
典型的同步通信案例是jdbc
異步通信
還是以同一個socket連接為例，socket客戶端發送一個請求之后，在響應還沒到來的時候，可以繼續發送另一個請求，具體場景是這樣的，業務線程1發送請求，然后線程等待結果，業務線程2發送請求，然后等待結果，以此類推，但是socket輸出通道可以一直發送消息，socket輸入一直在接收消息，這樣業務處理和通信邏輯是分離開來的互不干擾，且充分利用了通信通道，因為網絡傳輸的速度比cpu和磁盤要慢的多，因此有效利用網絡資源，將極大的提高系統吞吐量，當然要記住這里的使用場景，高並發，較小的報文傳輸，如果報文特別大，幾十MB，那異步通信就沒意義了
NIO 和BIO
Mina是使用的NIO
這個網站上很多資料，我就簡單的講下，我們的場景是適合用NIO的，為什么呢？
我們的場景除了高並發，報文小，還有一個特點，就是客戶端部署的點要遠遠多於服務端，因為越是底層的服務，可重用性越高，那么客戶端就相對較多，服務端相對較少。
BIO的缺點
傳統的BIO特點，有N個客戶端連接服務端，服務端就需要開啟N個線程來分別處理客戶端的請求，而且很多時候客戶端是空閑狀態的，那么服務端給它開的線程也將空閑，造成了資源浪費，同時線程數還不夠用。
NIO的優點
NIO很好的解決了這個問題，它使得服務端的一個線程可以處理多個客戶端連接，只要協調的好，可以用較少的線程處理較多的客戶端連接，使線程利用率得到很大的提高。
上一篇 大型網站系統架構的演進（一）