最近遇到的幾個項目分別用到了本地環境和分布式緩存。對于各種類型，我們希望做成設計標桿，以后不管是業務團隊同學自己開發還是我們架構團隊幫助優化，都有一套標準的設計模版。

本文是使用Redis分布式緩存優化的項目。

要不要打破服務化的限制

當時拿到需求的時候有個糾結點：原來數據查詢服務通過RPC調用數據存儲服務，因為涉及RPC調用以及查數據庫，耗時長。所以希望我們加一層緩存，絕大多數情況下直接從Redis取數據。如下圖所示：

通常的設計要做服務化，一個服務對外提供增刪改查，而緩存這種優化應該放到服務內部。也就是說數據查詢服務查詢仍然需要通過API來調用數據存儲服務，存儲服務做不做緩存，數據查詢服務應該是不感知的。如下圖所示。

圖片

而需求方的原始需求會破環服務的封裝性。這個矛盾怎樣來解決呢？可以這樣來考慮。作為一個服務，內部的數據處理，包括存儲、邏輯處理這些是要封裝在內部的。但是可以使用策略模式提供靈活的訪問API。RPC調用是一種訪問方式，redis調用是另外一種訪問方式。這樣就不算破壞封裝行。如下圖所示：

圖片

數據一致性校驗算不算多余？

這個和需求方討論沒有達成一致。這也是為什么我連續三天都發文了。我不想破壞文章內容在實際實施時原本的先后順序，但這一篇要趕在技術評審之前發出來，作為評審前跟需求方討論的一個資料。

這個設計Redis和MySQL里數據各存儲了一份，既然有異構的存儲，架構團隊這邊認為數據一致性校驗是要做的。而需求方認為既然都是消費MQ消息后處理，如果處理的沒有問題就不會發生數據不一致的問題。所以只要有個手動運維補償機制來處理生產故障即可，沒有必要定時巡檢來做數據一致性校驗。

我一直遵從的理念是對于負責的服務或者功能，要做到：可觀測、可衡量、可應對。自己開發的功能模塊是正確的，怎樣衡量呢？

數據一致性檢查就是用來衡量正確性的。如果邏輯沒有漏洞，數據一致性檢查應該每次巡檢對比數據都是一致的。一旦出現不一致，就是邏輯上出問題了，都是需要case by case分析并做邏輯的修改或者補充的。

如果邏輯本來就簡單，跑了一年都沒有檢查出任何的數據不一致，這個檢查是不是浪費呢？服務和功能都是要演進的，要做變更。變更要做到可灰度、可監控、可應急。數據一致性檢查就是監控變更后邏輯正確性的手段。

總結來說：這個數據一致性校驗屬于業務巡檢的一項，是用來發現問題的。發現問題可以通過在設計、開發階段做嚴格的設計審查、代碼Review來避免一部分。通過邏輯來保證是否屬于過度設計？需求方對這個邏輯到底有哪些顧慮呢？

巡檢邏輯會不會增加業務的復雜性、對數據庫造成額外的壓力？

這個巡檢邏輯我們打算通過分布式調度任務來做。通過分布式調度平臺，可以手動觸發執行任務作為上線時初始化數據的手段，同時也是故障處理的應急預案，本來就是要做的，做成巡檢只是每天定時執行一次，不會增加業務的復雜性。

對數據庫的壓力方面，這個巡檢的確需要掃描數據庫。但是我們會通過控制分頁，采用>id，利用索引等手段來優化深度分頁，并且會通過觀察生產監控挑選低峰期執行，因為這是讀數據，不會加互斥鎖，表的數據量也不大，預計對數據庫的壓力可以忽略不計。

總結

我自己在溝通過程中犯了一個很嚴重的錯誤。在論證數據一致性巡檢有必要做的時候，我說：「業界都是這么做的?！刮抑按_實是調研過各個做的比較好的大廠，他們對于業務巡檢都非常重視。但是我的表達犯了在《批判性思維》這本書中介紹的「篤信權威」的錯誤。

更正確的處理方式是要從：優勢、劣勢、必要性、成本等角度來考慮。更要主動詢問需求方的顧慮。