GPS部標監控平臺的架構設計(十一)-基於Memcached的分佈式Gps監控平臺

部標gps監控平臺的架構，隨着平臺接入的車輛愈來愈多，架構也面臨愈來愈大的負載挑戰，咱們固然但願軟件儘量的優化並可以接入更多的車輛，減小在硬件上的投資。可是當車輛增多到某一個臨界點的時候，仍然要面臨的三個問題：

1）鏈接的限制

      服務器軟件接入終端的鏈接數是有限的，不管如何優化，都是有限的，接入的增多就會排隊，超時timeout重置reset等問題就會出現;

2）部標808服務器軟件的內存限制的問題

      內存的限制，服務器操做系統中一個進程所承受的內存是有限制的，超過則致使服務器軟件進程內存溢出而退出。

3）數據庫承受的併發壓力和數據壓力愈來愈大，隨着gps數據和報警數據海量增加，數據庫備份、數據庫服務器響應速度變慢，進而網站的響應速度等都會變慢。用戶體驗效果會愈來愈差。

對於第一個問題，咱們採用多個分佈式的gps服務器或者負載均衡來解決，對於後面兩個問題，咱們引入Memcached這個分佈式的緩存服務器，來解決內存和數據庫併發壓力這兩個問題，關於Memcached的介紹，網上有不少，官方中文網站：http://memcache.com.cn/。

這裏重點說一下，Memcached在部標監控平臺架構中的位置和應用。

1.GPS監控平臺包含了808服務器、809服務器、web服務器、油耗里程定位計算服務等多個子系統，這些系統對於實時數據和靜態數據的調用特色是高頻次調用，基於Memcached的分佈式緩存，解決了各個子系統之間共享緩存的問題，也解決了採用本地緩存形成的數據同步困難的問題，如車輛信息中的車牌號用戶在web界面上進行更改，採用本地緩存，則只是更新到web子系統，若是採用EHcache，須要作比較複雜的配置，這徹底不必。

2.不一樣於電子商務平臺的訂單數據對於事務一致性要求很高，監控系統的特色是實時，它對於數據的時效性要求較高，因此即便Memcached沒有集羣，是一個單點的緩存服務，即便緩存服務不運行或者運行故障，咱們在架構設計的時候，只要考慮到這點，整個系統在Memcached故障的狀況下，仍然能夠運行或者支撐住一直到Memcached恢復服務。

3.對於gps監控，咱們須要看到實時的gps數據和報警，這些實時的數據，咱們能夠放在內存當中，而不是直接保存在數據庫中，這樣能夠減小數據庫的壓力。運行在不一樣進程的模塊，能夠共享實時的gps數據，而不用不斷的查詢和更新數據庫。因此咱們把Memcached做爲一箇中央緩存系統，而後對Memcached client封裝成一個ICacheService接口的標準Memcached實現，裏面作了Memcached故障失效的判斷，由各個子系統引用，各個子系統共享信息，一個系統負責更新和維護數據，因爲數據放在緩存服務器上，這樣808gps服務器的內存壓力就大大減少了。這樣咱們能夠肆無忌憚的調用車輛信息而不用擔憂頻繁查詢數據庫的性能損失了。

Memcached架構以下圖所示：

Memcached做爲服務器端，要想調用，還須要各個模塊集成Memcached緩存，網上提供了.NET和.java的客戶端，咱們須要結合本身系統的數據結構和架構，封裝成面向對象的緩存服務。

GPS部標監控平臺的架構設計系列文章已經寫到十一章了，若是須要閱覽之前一到十的文章，請閱讀》GPS部標監控平臺的架構設計系列