最近遇到的幾個(gè)項(xiàng)目分別用到了本地環(huán)境和分布式緩存。對(duì)于各種類型，我們希望做成設(shè)計(jì)標(biāo)桿，以后不管是業(yè)務(wù)團(tuán)隊(duì)同學(xué)自己開發(fā)還是我們架構(gòu)團(tuán)隊(duì)幫助優(yōu)化，都有一套標(biāo)準(zhǔn)的設(shè)計(jì)模版。

本文是使用Redis分布式緩存優(yōu)化的項(xiàng)目。

要不要打破服務(wù)化的限制

當(dāng)時(shí)拿到需求的時(shí)候有個(gè)糾結(jié)點(diǎn)：原來數(shù)據(jù)查詢服務(wù)通過RPC調(diào)用數(shù)據(jù)存儲(chǔ)服務(wù)，因?yàn)樯婕癛PC調(diào)用以及查數(shù)據(jù)庫，耗時(shí)長。所以希望我們加一層緩存，絕大多數(shù)情況下直接從Redis取數(shù)據(jù)。如下圖所示：

通常的設(shè)計(jì)要做服務(wù)化，一個(gè)服務(wù)對(duì)外提供增刪改查，而緩存這種優(yōu)化應(yīng)該放到服務(wù)內(nèi)部。也就是說數(shù)據(jù)查詢服務(wù)查詢?nèi)匀恍枰ㄟ^API來調(diào)用數(shù)據(jù)存儲(chǔ)服務(wù)，存儲(chǔ)服務(wù)做不做緩存，數(shù)據(jù)查詢服務(wù)應(yīng)該是不感知的。如下圖所示。

圖片

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

圖片

數(shù)據(jù)一致性校驗(yàn)算不算多余？

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

這個(gè)設(shè)計(jì)Redis和MySQL里數(shù)據(jù)各存儲(chǔ)了一份，既然有異構(gòu)的存儲(chǔ)，架構(gòu)團(tuán)隊(duì)這邊認(rèn)為數(shù)據(jù)一致性校驗(yàn)是要做的。而需求方認(rèn)為既然都是消費(fèi)MQ消息后處理，如果處理的沒有問題就不會(huì)發(fā)生數(shù)據(jù)不一致的問題。所以只要有個(gè)手動(dòng)運(yùn)維補(bǔ)償機(jī)制來處理生產(chǎn)故障即可，沒有必要定時(shí)巡檢來做數(shù)據(jù)一致性校驗(yàn)。

我一直遵從的理念是對(duì)于負(fù)責(zé)的服務(wù)或者功能，要做到：可觀測、可衡量、可應(yīng)對(duì)。自己開發(fā)的功能模塊是正確的，怎樣衡量呢？

數(shù)據(jù)一致性檢查就是用來衡量正確性的。如果邏輯沒有漏洞，數(shù)據(jù)一致性檢查應(yīng)該每次巡檢對(duì)比數(shù)據(jù)都是一致的。一旦出現(xiàn)不一致，就是邏輯上出問題了，都是需要case by case分析并做邏輯的修改或者補(bǔ)充的。

如果邏輯本來就簡單，跑了一年都沒有檢查出任何的數(shù)據(jù)不一致，這個(gè)檢查是不是浪費(fèi)呢？服務(wù)和功能都是要演進(jìn)的，要做變更。變更要做到可灰度、可監(jiān)控、可應(yīng)急。數(shù)據(jù)一致性檢查就是監(jiān)控變更后邏輯正確性的手段。

總結(jié)來說：這個(gè)數(shù)據(jù)一致性校驗(yàn)屬于業(yè)務(wù)巡檢的一項(xiàng)，是用來發(fā)現(xiàn)問題的。發(fā)現(xiàn)問題可以通過在設(shè)計(jì)、開發(fā)階段做嚴(yán)格的設(shè)計(jì)審查、代碼Review來避免一部分。通過邏輯來保證是否屬于過度設(shè)計(jì)？需求方對(duì)這個(gè)邏輯到底有哪些顧慮呢？

巡檢邏輯會(huì)不會(huì)增加業(yè)務(wù)的復(fù)雜性、對(duì)數(shù)據(jù)庫造成額外的壓力？

這個(gè)巡檢邏輯我們打算通過分布式調(diào)度任務(wù)來做。通過分布式調(diào)度平臺(tái)，可以手動(dòng)觸發(fā)執(zhí)行任務(wù)作為上線時(shí)初始化數(shù)據(jù)的手段，同時(shí)也是故障處理的應(yīng)急預(yù)案，本來就是要做的，做成巡檢只是每天定時(shí)執(zhí)行一次，不會(huì)增加業(yè)務(wù)的復(fù)雜性。

對(duì)數(shù)據(jù)庫的壓力方面，這個(gè)巡檢的確需要掃描數(shù)據(jù)庫。但是我們會(huì)通過控制分頁，采用>id，利用索引等手段來優(yōu)化深度分頁，并且會(huì)通過觀察生產(chǎn)監(jiān)控挑選低峰期執(zhí)行，因?yàn)檫@是讀數(shù)據(jù)，不會(huì)加互斥鎖，表的數(shù)據(jù)量也不大，預(yù)計(jì)對(duì)數(shù)據(jù)庫的壓力可以忽略不計(jì)。

總結(jié)

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

更正確的處理方式是要從：優(yōu)勢(shì)、劣勢(shì)、必要性、成本等角度來考慮。更要主動(dòng)詢問需求方的顧慮。