微服務架構下靜態資料通用快取機制
在分散式系統中，特別是最近很火的微服務架構下，有沒有或者能不能總結出一個業務靜態資料的通用快取處理機制或方案，這篇文章將結合一些實際的研發經驗，嘗試理清其中存在的問題以及探尋通用的解決之道。
什麼是靜態資料
這裡靜態資料是指不經常發生變化或者變化頻率比較低的資料，比如車型庫、使用者基本資訊、車輛基本資訊等，車型庫這種可能每個月會更新一次，使用者和車輛基本資訊的變化來源於使用者註冊、修改，這個操作的頻率相對也是比較低的。
另外這類資料的另一個特點是要求準確率和實時性都比較高，不能出現丟失、錯誤，以及過長時間的更新讀延遲。
具體是不是應該歸類為靜態資料要看具體的業務，以及對變化頻率高低的劃分標準。在我們的業務定義中，上邊這幾類資料都歸為靜態資料。
為什麼需要快取
在面向使用者或車輛的業務場景中，車型資訊、使用者基本資訊和車輛基本資訊有著廣泛而高頻的業務需求。在這裡快取的目的就是為了提高資料查詢效率。靜態資料通常都儲存在關係型資料庫中，這類資料庫的IO效率普遍不高，應對高併發的查詢往往捉襟見肘。使用快取可以極大的提升讀操作的吞吐量，特別是KV類的快取，沒有複雜的關係操作，時間複雜度一般都在O(1)。注意這裡說的快取指記憶體快取。
當然除了使用快取，還可以通過其它手段來提高IO吞吐量，比如讀寫分離，分庫分表，但是這類面向關係型資料庫的方案更傾向於同時提高讀寫效率，對於單純提升讀吞吐量的需求，這類方案不夠徹底，不能在有限的資源情況下發揮更好的作用。
通用快取機制
下面將直接給出一個我認為的通用處理機制，然後會對其進行分析。
對於某個具體的業務，其涉及到六個核心程式：
-
業務服務：提供對某種業務資料的操作介面，比如車輛服務，提供對車輛基本資訊的增刪改查服務。
-
快取處理程式：從佇列接收資料，然後寫入快取。
-
資料一致處理程式：負責檢查快取資料庫和關係型資料庫中資料是否一致，如果不一致則使用關係資料庫進行更新。
-
快取資料庫（Redis）：支援持久化的快取資料庫，這裡直接選了Redis，這個基本是業界標準了。
以及兩個外部定義：
-
資料生產者：業務靜態資料的來源，可以理解為前端APP、Web系統的某個功能或者模組。
-
資料消費者：需要使用這些業務靜態資料的服務或者系統，比如報警系統需要獲取車輛對應的使用者資訊以便傳送報警。
下面以問答的形式來說明為什麼是這樣一種機制。