基于Redis建構10萬+終端級的高性能部标JT808協定的Gps網關伺服器（轉）

原文位址：http://www.jt808.com/?p=1282

       在開發一個大規模的部标GPS監控平台的時候，就算我們花費再多的時間設計和規劃，我們也并不能準确的預測出自己未來的車載終端接入量有多大，而且一開始就為了我們宏偉的設計藍圖，投入大規模的伺服器硬體裝置和網絡帶寬，這會帶來極高的成本投入，也會在早期造成大馬拉小車，空耗+複雜度過高。是以大多數的平台一定是從一兩台伺服器搭建營運環境， 随着車載終端量級越來越大，并發越來越高，業務模式也越來越複雜，我們需要将程式解構，從一個子產品拆出多個子產品，從單機運作變成多台伺服器分布式部署，從單程序變成多服務模式。是以我們設計的時候，就必須要建構這種可擴充的由1變成N的架構，必須要有一個可擴充的高可用的基于部标jt808協定的伺服器。

      我們這裡所說的10萬+終端接入，首先是10萬+線上的，另外并不是簡單的接入，後續肯定還要保證明時資料推送、資料入庫、報警分析和複雜的業務邏輯計算都能穩定的運作。在這種場景下，單台伺服器或者單程序的一個808網關伺服器是很難支撐到的。我們需要保證的是從前到後一系列的穩定運作名額：

      1） 接入：10萬+終端接入不出現排隊和無法接入現象，由于一般的基于JT808協定的終端裝置，都是基于TCP長連接配接通信，UDP的很少，10萬+長連接配接的維持對伺服器的壓力可想而知非常大。一般的伺服器帶寬不夠的時候，或者由于伺服器處理速度慢，造成連接配接無法及時歸還連接配接池，造成伺服器接入的時候，就卡殼。我們一般采用Netty來做為JT808伺服器的NIO Socket伺服器架構，而Netty在開發的時候就要求在Handler中，擷取的連接配接資料的時候，必須不能做耗時的操作。這就要求我們必須要異步處理。

      2)   實時性 ： 雖然終端接入了，但是後續的邏輯處理子產品如果處理速度過慢，即使是異步的，也會造成資料在記憶體中排隊等候處理的情況，這樣當資料傳遞到web使用者面前的時候，就是滞後的，不滿足使用者對實時性的要求。如報警彈窗，位置顯示等都是對實時性有要求的功能。

      3)   資料入庫：并發的連接配接，必然會造成對資料庫并發請求加大，要求及時入庫的GPS資料也是海量的，一分鐘将有幾十萬級别的GPS資料等待入庫，而且根據jt808協定，一條0×0200指令的定位資料包，經過伺服器解析和邏輯計算後，又衍生出報警記錄，油量溫度記錄，裡程統計記錄等等，資料量也非常的大。雖然并發是提高入庫效率的手段，但是并發過高，超過資料庫伺服器承載的能力，又會造成資料庫伺服器卡殼，進而造成連鎖反應，web使用者經常會看到頁面打開過慢，資料顯示不出來，其實不是web伺服器的問題，是資料庫的壓力太大，難以及時響應。是以一個能承受10萬+終端的部标808伺服器，并不簡單的是要求代碼寫的好性能高，前期資料庫的設計和規劃能力和實際的承載能力也必須要跟得上，這就是一條流水線，那個環節掉鍊子，都是多米諾效應的崩潰。

      在實際的營運中，單台的阿裡雲伺服器并不貴，帶寬的營運成本要高于伺服器的成本，是以我們在設計架構的時候，必須要保證部标808伺服器是可以像刀片一樣是可以插拔的，通過分散壓力，來保證系統的穩定運作。當某一個伺服器子產品停用或者上線，是不需要整個平台調整或者改造開發的，web平台是無感的。

      是以我們不能讓Web平台直接面對808伺服器，而是在808服務和Web平台之間，增加一個Redis緩存伺服器，808伺服器的實時GPS資料直接push到Redis緩存中，web平台擷取實時資料的時候，不是通過RPC調用808伺服器的實時服務，而是通過Redis的API，直接從Redis緩存中擷取。利用Redis的Pipeline模式，可以批量擷取所需的實時資料。