前言
物聯網如今是一個大的趨勢，但是概念還比較新穎。大家對這一塊的技術積累也比較匱乏，借此前段時間摩拜單車出現了大規模癱瘓的現象。我們今天來討論一下物聯網項目的開發方式。
關於tcp/ip 相關的知識點
tcp三次握手，四次揮手
http://blog.csdn.net/whuslei/article/details/6667471
tcp Client/server 最大連接數
http://blog.csdn.net/huangjin0507/article/details/52399957
close_wait問題處理方案
http://www.cnblogs.com/sunxucool/p/3449068.html
socket通訊的單機瓶頸
物聯網的項目socket使用方式有兩種：
- 短連接的socket請求
- 維持socket長連接的請求
對於socket短鏈接來說就好比是http請求，請求服務器，服務器返回數據以后請求管道就關閉了，服務器與客戶端的鏈接就釋放了。但是對於socket長鏈接就不同了，當設備與服務器建立連接以后就要一直保持連接，或者說保持較長時間的鏈接，那么就會大量消耗服務器的資源。若存在大量的這樣的請求以后服務器終究會受不了垮掉。通過對TcpClient/server最大連接數我們得知單機socket服務是存在最大鏈接數限制。盡管理論值很大，但還要考慮到實際服務器的內存／cpu／帶寬等條件，我們不可能指望單機承載特別大的鏈接請求。
該如何負載均衡socket長連接的請求
提到負載均衡大家可能會想到很多負載均衡的框架，比如說比較出名的：nginx。但是悲催的是他是基於轉發的方式，不能應用在socket長鏈接請求上。在這一塊目前還沒有特別優秀的處理框架，而且從技術角度來分析也不可能存在。那我們只能自己想辦法了。
socket分發服務架構圖
1、 設備請求分發服務器，分發服務器返回有效的socket服務器ip與port，然后斷開連接。
a) 設備與服務器建立連接。
b) 服務器接收到連接請求后，立即將分配好的socket服務器ip與port信息響應給設備。
c) 服務器主動斷開socket連接。
2、 設備得到ip與port以后，設備去連接socket服務器，然后與其進行協議通訊。
a) 設備連接到socket服務器。
b) socket服務器響應連接成功響應信息。
c) 設備與socket服務器保持長鏈接通訊。
*. 若設備未收到連接成功響應則再次嘗試連接，若三次請求依舊沒有成功建立連接，那么設備需要去請求分發服務器然后再重新上述操作。
*. 當設備在異常情況下鏈接不上socket服務器時，依舊嘗試三次若不能成功，則直接請求分發服務器，然后再重復上述操作。
分發服務器處理業務
我們來看一下分發服務器該處理的業務：
@Override public void channelActive(ChannelHandlerContext ctx) throws Exception { //todo 根據自己的負載情況獲取相應的socket服務器信息 String ip = "192.168.1.188:2030"; SocketUtils.send(ctx,ip.getBytes()); ctx.close(); } *. ip的獲取需要根據自己的業務來完成。
總結
我們通過這樣的方式就可以輕松的解決大量設備與服務器通訊的問題，若后面有更多的設備請求只需添加更多的socket服務器即可。當然可能大家擔心分發服務器受不了，其實這是多余的，因為分發服務器只做轉發，而且完成處理以后就直接把鏈接給釋放，並且當設備拿到socket服務器的ip地址以后就將不在訪問分發服務器了，它的壓力是可控的不會特別也不會頻繁。
關於distribute-netty： 該demo僅僅用於說明分發服務器的工作原理，具體的業務實現還需要根據自己的業務來完成。
轉自：https://my.oschina.net/oswl/blog/967828?from=singlemessage&isappinstalled=0