信息系統實踐手記5-CACHE設計一例

說明：信息系統實踐手記系列是系筆者在平時研發中先後遇到的大小的問題，也許朴實和細微，但往往卻是經常遇到的問題。筆者對其中比較典型的加以收集，描述，歸納和分享。

摘要：此文描述了筆者接觸過的部分信息系統或平臺之間的對接構型和情況，掛一漏萬的總結分享之。

正文

系列隨筆目錄：信息系統實踐手記 （http://www.cnblogs.com/taichu/p/5305603.html）

作者：太初

轉載說明：請指明原作者，連接，及出處。

1.CACHE是啥？

      最近一直在弄scala，Spark，Python，數據挖掘的東西，以及複雜科學的一些研究，在充實和忙碌之餘，雖然興趣濃厚，但體力不支，疲勞的很，無奈耽擱了實踐手記。

      原本計劃按照至少2周掛出一篇來分享，實在抱歉。要分享的東西太多，碼字太費時間，有時候甚至覺得開會也許更好（很多人反感開會，那是因為咱們沒開過會）！其實很多東西除了領路人，還是考自己去走，去體會，總結。

      閑話不說，切入正題。

      很多研發人員，尤其是開發程式的同志，找到一個cache框架或類庫可用，比如hibernate的cache功能，然後就一股腦用上去。雖然會有效果，且很愉悅，這是好事，既增加了經驗，也體會了框架的魅力和效率，但其實還有最重要東西可以進一步去領會。究竟為啥要用CACHE？CACHE是啥？什麼樣的場景用什麼樣的CACHE？很少有人靜下心來問。

      那CACHE到底是啥呢？還真難於表述清晰，但有一些要點：

• CACHE的產生是為了緩解處理鏈上不同節點之間速度不協調的情況。舉若幹例子：
• 電腦系統：一般有速度梯度：CPU內部寄存器（register）>記憶體>磁碟IO>網路IO，為協調它們之間傳遞數據的速度差，就可設置緩存結構，叫CACHE；
• 說明1：以上說的是一般情況，不考慮特別的磁陣RAID，告訴SCSI，千兆或萬兆網路等；
• 說明2：CPU內部也分L1，L2，L3等多級CACHE，早先的386/486處理器沒分那麼多CACHE層次；
• 地鐵系統：有時候出事故，人特多，站內站外由管理員把守入口分批放人到1層大廳，則1層大廳是一個CACHE；管理員分批從大廳放人到B1層站臺，則B1站臺也是一個CACHE；當CACHE快撐滿的時候，管理員就會喊“慢慢來，不要擠，暫時關閉，大家耐心等待！”，於是人就被囤積在不同的CACHE里，以便協調地鐵運量和人流涌入的速度差問題。
• 工廠流水線：另一個典型例子是工廠的流水線。以前老式流水線每個工位站1個人，處理1個裝配動作，比如給黃小鴨玩具裝上1條腿。一個工件，如果流經10個處理節點，那就會有10個人來處理10個步驟。顯然，老闆期望流水線一直處於充滿狀態，則最高效的源源不斷有產出。但意外總會發生，比如某工件N流轉到Px節點，Px節點的工人很累，處理較慢，導致Px-1步驟流出的工件不斷堆積，而這個Px處理節點處理台的工件堆積場所，就是一個BUFFER緩存區（也就是CACHE），它越來越滿，就提醒Px的工人，加緊乾，否則一旦CACHE撐爆，就無法剋服（追上）速度差（時間差）的問題！（畫外音：可以看出流水線機制的高效和科學，以及“殘酷”）。
• 生產者消費者模式：經典的程式設計模式“生產者和消費者”模型也有一個CACHE的設計，就是協調生產和消費的速度差，類似“工廠流水線”
• CACHE實際上是用空間上的代價來緩解時間上的不協調。
  • 你肯定要問“既然速度有差異，那CACHE再大也沒用？”，的確，再大的CACHE也是用來臨時剋服速度差異的，它期望可以用空間暫時的堆積追回偶發導致的時間不協調（速度差是絕對的，這個在設計場景之前就知道，但速度不協調是偶發的，這個要區別開！）。如果永遠無法“追回來”，那麼再大的CACHE也會有問題，那麼就是設計上的問題了，就不是CACHE機制可以解決的。
  • 處理節點Px往往速度不同，所以必須用不同演算法來安排。比如：
    • 通過編譯程式的安排，將C/C++等編譯性語言的代碼做安排，並充分考慮到CPU/MEM/DISK/NETWORK的差異；保持MEM代碼段高命中，降低頁丟失中斷，否則就要從代存（相對於記憶體MEM來說，磁碟就是外存設備，磁碟IO比MEM慢很多）。
    • 通過解釋器（如JAVA的虛擬機JVM），將JAVA等解釋性語言的代碼，弄成偽指令，它也充分的考慮了CPU/MEM/DISK/NETWORK的速度差異；程式本身是死的，但編譯器或解釋器可以做很多，合理的安排程式段，數據段，以及考慮如何導入多核心的CPU等等。
    • 程式本身也應該充分利用諸如“多線程”，“併發計算”，“分散式計算”等方法，來從巨集觀的演算法層面，考慮到，解決掉速度差異，從而適當的利用CACHE來防止偶發的速度不協調，而不是演算法本身有永久性的硬傷“速度不匹配”。可以適當的使用一些主流成熟前三名的框架來解決實際問題。
    • 程式終究是要達成業務需要的，也就是完成功能目標（Feature）。而功能和業務本身是有特點的，有時空特性的，是高併發業務？還是隨機業務？業務的時空特性如何？是否和上下班高峰有關？ 是否和網站的維護周期有關？是否和購物的時間段有關？總之從業務觸發，需要專業的領域知識（行業支持），並且需要深厚的技術功底，這樣的從場景出發的系統分析和系統設計行為，是何其重要！這方面的人才非常緊缺。
• CACHE所處理的時空不協調，可能是偶發的，也可能是來自於業務模型；
  • 通過上述的不同層次（編譯器，解釋器，程式，框架類庫，業務場景分析）的處置，基本上摸透並能夠妥善的處理業務，達成場景，使用必要的CACHE結構了。但業務模型總是會偶發時空不一致，尤其是在當今多任務的電腦架構（以前主機時代只有大型機是多進程的，現在微機也是多任務並細化到線程了！）。很容易計算力不夠需要增加更多CPU的core，數據量大沒地方放，就增加MEM，MEM增加後也會導致低速的磁碟IO和網路IO也變大。
  • 另外在對業務模型不斷調優和擴容的過程中，不協調也會自然產生的，而如果程式模型比較優秀，相關必要的地方本來就有CACHE，那麼CACHE將為程式運作提供餘地。
  • 即便是簡單的業務模型，而且調優完成，且一直正常運作。但也可能因為“網路故障，CPU失效，記憶體或磁碟損壞，某個計算節點離線”等問題而打破平衡。這時候，甚至連寫LOG日誌來記錄狀態也顯得很奢侈或捉襟見肘。此時，如果程式在框架設計上已經未雨綢繆的安排了充分和必要的CACHE，則完全可以提升健壯性，甚至在偶發災難衝擊中堅強運行，恢復運作。
• 客觀世界和程式世界都是複雜的，而複雜系統無處不存在意外和不協調，CACHE則應運而生，無處不在：
• CPU裡面的微指令集中用到了L1，L2，L3，它們就是各級CACHE；
• MEM，DISK，網卡等設備，無論在硬體的介面程式BIOS中，還是在程式員編製的應用程式中，都安排了CACHE，來處理設備受到外界速度不匹配的衝擊。
• 程式設計中很多模式，比如消費者生產者，就必然有CACHE存在，以緩解生產和消費的速度不匹配；
• 真實世界的倉庫存貨，小超市囤貨，高架路上的緊急停車帶，上下岔道區域，展覽會門口的回形排隊護欄，流水線的每個節點的BUFFER緩衝帶等等，都是CACHE的好例子；

      只有理解了自然現象，業務規律和程式能力邊界，才能深入體會如何在程式設計中，在什麼樣的業務場景下使用怎樣的CACHE設計，以便到達好處和結果。不建議只為了技術用技術，必須明確使用的目的為何，才能正確的使用。

2.CACHE設計一例

      這裡簡單舉一個例子，還是前幾篇分享的客戶端和伺服器，它們是提供GIS地圖服務的伺服器和客戶端；而這個提供GIS業務的伺服器就用到很多CACHE； 劈開客戶端業務展現不說，很多後臺服務是由做GIS業務的應用SERVER提供，簡稱為GS，而GS需要從設備管理平臺，簡稱DS獲取設備信息；

1. 因為DS不提供設備信息的訂閱（很遺憾），則無法使用高效的觀察者模式來獲取設備變更信息，而只能由GS通過階段同步（輪詢模型）來花巨大的代價向DS獲取其實很少變化的設備更新信息。為了階段同步，GS只能在記憶體（或DB）做了一個CACHE，來存放比如每30分鐘的同步信息；
2. 最先因為是30分鐘同步，而按照J2EE經典的用法，通過DAO，業務是從DB獲取數據，所以同步數據放在DB。為了提升速度，解決業務場景的高速要求和DB處理的慢速情況，將DB的數據“上提”到記憶體的CACHE中，以後做業務直接插CACHE，處理CACHE；這裡就自然的引發了一個問題，CACHE的臟數據需要同步回到DB，因為數據存在於連個地方，一個CACHE是臨時的，一個DB是持久化的，那麼它們之間也有同步問題，這是使用CACHE經常要面臨的情況。其實最後因為原來程式框架做的不佳，導致了批量修改完成後，還遺留了不少小尾巴，只能casebycase的處理，找到一個算一個，當讓也可以在人力允許的範圍內做大面積的回歸測試，不細說。
3. 我們GS平臺，還和第三方，比如一個城市的路口卡口管理平臺（簡稱KS）對接，上次講過平臺對接問題了，這裡假設順利對接。那麼KS的數據，也會階段性的同步到我們GS來。一個典型的應用是GS向KS訂閱了一種“告警A”，當KS發生時間A而發出“告警A”時，將會推送到GS平臺，那麼GS平臺分發給客戶端。這裡顯然有速度的不協調，如果告警頻繁，GS一時處理不過來，那麼就要CACHE，怎麼弄？也可以不用自己寫代碼，我們GS和GS的客戶端是通過ActiveMQ的消息中間件來傳遞消息。訂閱之後，不同主題的消息和用戶就會有自己的BUFFER來存放，即便KS平臺突發大量告警A到GS，GS來不及分發，那就放入MQ自己管理的緩存隊列，MQ自己處理。當然這裡我們看到了上面討論過的CACHE的幾個問題：
   1. 如果KS平臺的“告警A”一直高頻持續發送，那麼最終GS接收代碼來不急放入MQ，或者來得及放入MQ，但MQ終將崩潰。所以這裡就遇到了前幾篇提到的平臺對接中，對兩個有交互的平臺之間的信令和數據的“時空特性”一定要定義清晰，比如我們GS和KS就定義了最高併發不能超過1秒10條（10CAPS），否則GS拒絕而不是通過CACHE儘量容納和處理。萬事都有限度，討論清楚就行！
   2. 這裡還有一個隱蔽問題，大家不知道看出來沒有。這裡假設我GS的JAVA接收代碼，從網路socket套接字獲取的批量位元組流，速度極快，放入MQ幾乎不花時間。如果沒有這個假設，而且放入速度的確很慢，那麼MQ不會最終“爆炸”，首先奔潰的及時GS的接收代碼片段。這個判斷，一般是根據程式員的經驗和業界的經驗來確定的。它總是非常快，放入message，總是比消費處理message快不少。
4. CACHE也能存在於高層次和高抽象級別的。比如當前的hibernate庫支持對象到DATA MODEL的映射，而業務是針對對象，不是直接赤裸的和數據交互的。針對對象的操作比如func1()也是可以CACHE緩存的，以便第二次同樣的調用func1()的時候，極大的提升速度和效率。 這裡當然也會看到一個臟數據和失效的問題，不再討論。

[END]