如何保證分佈式系統本地緩存節點會話一致性

概述

分佈式系統經常會採用緩存提高系統吞吐量,從緩存存儲的方案,緩存分爲本地緩存和分佈式中間件緩存(redis、memcached等)。對於分佈式中間件緩存的節點同步其實還是很好處理的,應用服務器集羣都是向中間件緩存操作緩存數據,只需要保證緩存中間件節點的數據一致性即可保證緩存數據一致性。當然,對於不同的緩存中間件,節點數據同步機制也處理方案也會有所不同,衍生了一系列解決方案:一致性hash、數據標識hash存儲、分片,讀寫分離等等。我覺得相對分佈式系統緩存節點數據一致性,本地緩存節點數據一致性更加有挑戰(當然後續如果有機會也會寫一篇分佈式緩存節點數據一致性的介紹)。

當然從設計方案上肯定優先考慮分佈式緩存,但是對於頻繁讀取並且數據量較小情況,採用本地緩存將會大大提高系統的吞吐量,讀取一次分佈式緩存,就算是內部機房情況,都會有0.5ms的時間損耗,如果遇到業務複雜,並且性能,時延需要嚴格控制的情況,那採用本地緩存無非是一種不錯的解決方案。本文,將進一步闡述在分佈式系統中本地緩存節點數據一致性的解決方案(主要是會保證用戶體驗方面,對數據允許一定時間髒讀)

  

 

方案一  MVCC 和 全局時間鍾方案

MVCC即多版本併發控制(Multi-Version Concurrency Control),原本是數據庫系統如Oracle、Mysql、PostgreSQL等爲了更好的處理鎖機制,纔有樂觀鎖的一種實現方式。通過保存數據在某個時間點的快照來實現,這意味着一個事務無論運行多長時間,在同一個事務裏能夠看到數據一致的視圖。根據事務開始的時間不同,同時也意味着在同一個時刻不同事務看到的相同表裏的數據可能是不同的。藉助這樣的方案也可以在緩存系統實現本地緩存數據一致性的,通過快照方式,各個分佈式節點可以在該時間點,查詢當前時間點對應的快照。

 

 

方案二  環形刷新算法方案

待續。。。

 

方案三  採用流量定向實現回話一致性

 

方案三 延遲時間檢測方案

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章