背景
近幾年互聯(lián)網(wǎng)的快速發(fā)展中，互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展越來越復(fù)雜，業(yè)務(wù)也被拆分得越來越細，阿里內(nèi)部業(yè)務(wù)也發(fā)生著翻天覆地的變化，從最初的單體應(yīng)用，到后面的分布式集群，再到最近幾年大中臺小前臺的業(yè)務(wù)形態(tài)，作為后端開發(fā)，依賴的服務(wù)方越來越多，同時依賴服務(wù)方的故障因素也會越來越多的會影響到閑魚的上層業(yè)務(wù)的穩(wěn)定。 例如在閑魚主推商品流的業(yè)務(wù)場景中，商品中臺數(shù)據(jù)庫的抖動會造成主推商品流的卡頓或者頁面顯示空窗現(xiàn)象，個性化算法中臺向量集群的擴容也會造成推薦內(nèi)容延時被拖到非常長，后面還有可能依賴其他的業(yè)務(wù)中臺，作為上層業(yè)務(wù)如何保證依賴的中臺越來越多的情況下，還能保證服務(wù)的穩(wěn)定性運行呢？ 業(yè)界主流溜一遍
根據(jù)日常解決問題的經(jīng)驗，不能直接解決業(yè)務(wù)問題本身，可以折中解決業(yè)務(wù)問題也是一個不錯的辦法。上述業(yè)務(wù)問題中，當(dāng)業(yè)務(wù)出現(xiàn)問題的時候，可以折中提前置備好所需的業(yè)務(wù)數(shù)據(jù)返回給業(yè)務(wù)，也是一個不錯的辦法。在閑魚主推商品流的業(yè)務(wù)場景中，對可靠性要求非常高，因為推薦商品失敗，用戶看到推薦頁出現(xiàn)空窗，業(yè)務(wù)所需的數(shù)據(jù)量大概是5頁的推薦商品數(shù)據(jù)流，大概為3M左右。在實際解決問題中，筆者從業(yè)務(wù)所需的數(shù)據(jù)量級、可靠性要求級別等角度調(diào)研了業(yè)界一些通用解決辦法。
為了給用戶良好的業(yè)務(wù)體驗，筆者主要使用服務(wù)端數(shù)據(jù)冗余、客戶端數(shù)據(jù)冗余、熔斷機制等方法，來確保用戶對閑魚App流暢的業(yè)務(wù)體驗。筆者主要服務(wù)端數(shù)據(jù)冗余聊聊本地緩存，根據(jù)筆者在阿里斷網(wǎng)演練的經(jīng)驗，斷網(wǎng)演練時，某個區(qū)域的所有服務(wù)不可用，所以筆者在技術(shù)選型的時候沒有考慮分布式緩存Redis，Memcache之類等。目前就業(yè)界本地緩存庫有Guava、Caffeine、Ehcache、Cache2K、ConcurrentHashMap、Varnish、JackRabbit等，筆者選取了幾個性能比較優(yōu)越的緩存庫比較，下面筆者從功能上、性能上、易用性、集群能力、可視化報表上等分別比較。 筆者對照目前業(yè)務(wù)需求對比了上述四個組件，在定時失效策略能力上，除了ConcurrentHashMap都是使用定時失效能力，并且三個組件時間復(fù)雜度都是O(n)。在集群能力上，Ehcache依賴自身網(wǎng)絡(luò)協(xié)議 保證集群數(shù)據(jù)一致性，不能使用現(xiàn)有集團內(nèi)部組件保證數(shù)據(jù)一致性。在本地緩存能力上， Caffeine的寫能力優(yōu)于Guava 。在組件通用性上，Guava組件更加通用。最終筆者選用了Guava組件作為本地緩存組件，因為Guava 組件更加通用，并且很方便與 阿里內(nèi)部中間件集成配合使用。在集群數(shù)據(jù)同步能力，通過配置中心中間件實現(xiàn)數(shù)據(jù)同步，在可視化報表能力，通過定時任務(wù)打印日志，日志采集系統(tǒng)采集展示數(shù)據(jù)報表。接下來筆者介紹如何添加上述三種能力和優(yōu)化Guava本地緩存能力。
我的集群Cache組件
Guava Caching提供了定時失效、最后訪問失效、最后寫入失效策略等能力，筆者主要使用了定時失效能力，在首次寫入Key后，指定時間過后，該Key會失效，業(yè)務(wù)獲取該Key時，會調(diào)用reload方法重新同步加載該Key。如果使用invalid方法使該Key無效，業(yè)務(wù)并發(fā)再次獲取該Key，多線程加載該Key時，只有一個業(yè)務(wù)線程調(diào)用load方法加載該Key，其他線程等待該Key，加載完成后重新進入指定時間后流程。筆者在原來Guava Cache本地緩存能力上結(jié)合Spring自動 注入能力，進行工程化，添加了業(yè)務(wù)所需的如下三種能力
根據(jù)上述業(yè)務(wù)能力，整體流程圖如下所示 集群本機Cache組件的整體結(jié)構(gòu)類圖如下:
-
AbstractCacheLoader重寫父類CacheLoader的reload方法，添加異步加載能力
-
LocalCacheManager管理所有實現(xiàn)AbstractCacheConfig的子類，并上報各自本地緩存大小。
-
實現(xiàn)AbstractCacheConfig的業(yè)務(wù)配置子類，例如CurrentCacheConfig等，調(diào)用invalidate方法時，會通知集群本機Cache中Key消息。
業(yè)務(wù)同學(xué)在使用集群本機Cache組件時，只需要繼承AbstractCacheConfig抽象類，聲明為Bean，即用集群本機Cache組件，業(yè)務(wù)同學(xué)無需關(guān)心集群環(huán)境問題等。相比Guava cache組件，提供了集群本機Cache Key失效能力，以及對Key集中管理和監(jiān)控，減少了單獨使用Guava cache帶來內(nèi)存無法管理的問題。
接下來筆者介紹使用集群本機Cache組件能力的典型案例：自動置備兜底組件。 典型栗子：自動置備兜底組件
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
