以Redis為例，詳談分布式系統(tǒng)緩存的細(xì)枝末節(jié)

前言：

在分布式Web程序設(shè)計(jì)中，解決高并發(fā)以及內(nèi)部解耦的關(guān)鍵技術(shù)離不開緩存和隊(duì)列，而緩存角色類似計(jì)算機(jī)硬件中CPU的各級(jí)緩存。如今的業(yè)務(wù)規(guī)模稍大的互聯(lián)網(wǎng)項(xiàng)目，即使在最初beta版的開發(fā)上，都會(huì)進(jìn)行預(yù)留設(shè)計(jì)。但是在諸多應(yīng)用場(chǎng)景里，也帶來了某些高成本的技術(shù)問題，需要細(xì)致權(quán)衡。

本系列主要圍繞 分布式系統(tǒng)中服務(wù)端緩存相關(guān)技術(shù) ，也會(huì)結(jié)合朋友間的探討提及自己的思考細(xì)節(jié)。文中若有不妥之處，懇請(qǐng)指正。本文是本系列的第一篇，打算盡可能詳細(xì)地談?wù)劸彺孀陨淼幕A(chǔ)設(shè)計(jì)應(yīng)用，以及相關(guān)的操作細(xì)節(jié)等（具體應(yīng)用主要以Redis舉例）。

一、服務(wù)端數(shù)據(jù)緩存

1

一種區(qū)分

緩存基于不同的條件有很多種劃分方式，本地緩存（Local cache）和分布式緩存（Distributed cache）是一種常見分類，兩者自身又包含很多細(xì)類。

本地并不是指程序所在本地服務(wù)器（從嚴(yán)格概念來說），而是更細(xì)粒度的指位于程序自身的內(nèi)部存儲(chǔ)空間，而分布式更多強(qiáng)調(diào)的是存儲(chǔ)在進(jìn)程之外的一個(gè)或者多個(gè)服務(wù)器上，彼此交互通信，在具體軟件項(xiàng)目的設(shè)計(jì)和應(yīng)用中，多數(shù)時(shí)候是混合一體。當(dāng)然，個(gè)人認(rèn)為對(duì)緩存本質(zhì)的理解才是最重要的，至于概念上的分類只是一個(gè)不同理解下的劃分而已。

2

一些技術(shù)成本

在具體項(xiàng)目架構(gòu)設(shè)計(jì)時(shí)，單純使用前者（本地緩存）的開發(fā)成本毋庸置疑是極低的，主要考慮的是本機(jī)的內(nèi)存負(fù)載或者極少量的磁盤I/O影響。而后者的設(shè)計(jì)初心是為了利于分布式程序之間緩存數(shù)據(jù)的高效共享和管理，除了考慮緩存所在服務(wù)器自身的內(nèi)存負(fù)載，設(shè)計(jì)時(shí)更需要充分考慮網(wǎng)絡(luò)I/O、CPU的負(fù)載，以及某些場(chǎng)景下的磁盤I/O的代價(jià)，同時(shí)還在具體設(shè)計(jì)時(shí)盡可能規(guī)避和權(quán)衡整體穩(wěn)定性和效率，這些不僅僅只是作為緩存服務(wù)器的硬件成本和技術(shù)維護(hù)。需要謹(jǐn)慎考慮的底層問題包括緩存間通信、網(wǎng)絡(luò)負(fù)載和延遲等各種需要權(quán)衡的細(xì)節(jié)。

其實(shí)如果理解了緩存本質(zhì)就該知道，任何存儲(chǔ)介質(zhì)在適當(dāng)?shù)膱?chǎng)景下都可以充當(dāng)一個(gè)高效的緩存角色并進(jìn)行項(xiàng)目集成和緩存間集群。常見主流的Memcached和Redis等均是屬于后者范疇，甚至可以包括如基于NoSQL設(shè)計(jì)的MongoDB這類文檔數(shù)據(jù)庫（但這是從角色角度講，而狹義劃分上這是基于磁盤的存儲(chǔ)庫，需要注意，各有專攻）。

這些第三方緩存在進(jìn)行項(xiàng)目集成和緩存間集群，也需要解決一些問題。甚至項(xiàng)目迭代到了后期階段，往往還需要具備較高專業(yè)知識(shí)的運(yùn)維同時(shí)參與，并且在開發(fā)中的邏輯設(shè)計(jì)和代碼實(shí)現(xiàn)也會(huì)增加一定的工作量。所以有時(shí)候在具體項(xiàng)目的設(shè)計(jì)上，一方面要盡可能預(yù)留，一方面還得根據(jù)實(shí)際情況盡可能精簡(jiǎn)。

額外說下其他體會(huì)：在個(gè)人有限的技術(shù)學(xué)習(xí)和實(shí)踐里，關(guān)于節(jié)點(diǎn)數(shù)據(jù)交互，尤其是服務(wù)間通信，是不存在完美的閉環(huán)的，理論上也都是在“當(dāng)前階段”面向“高一致”的權(quán)衡罷了（大概跟生活是一樣的吧）。

二、緩存數(shù)據(jù)庫結(jié)構(gòu)的設(shè)計(jì)細(xì)節(jié)

由于目前個(gè)人工作中大多數(shù)情況應(yīng)用的是Redis 3.x，以下若有特性關(guān)聯(lián)，均是以此作為參照說明。

1

實(shí)例（Instance）

根據(jù)業(yè)務(wù)場(chǎng)景，公共數(shù)據(jù)和業(yè)務(wù)耦合數(shù)據(jù)，一定分別使用不同的實(shí)例。如果是單實(shí)例，才可以考慮以DB劃分。當(dāng)你使用的是Redis，那么DB在Redis里是有數(shù)據(jù)隔離，但沒有嚴(yán)格權(quán)限限制，所以劃庫只是一種選擇。在Cluster集群里則是保持默認(rèn)單個(gè)庫，不過實(shí)際中我會(huì)嘗試根據(jù)項(xiàng)目大小來調(diào)整，至于在哪個(gè)開發(fā)階段則是作為預(yù)留設(shè)計(jì)。

額外需要注意的是，作為重度依賴服務(wù)器內(nèi)存的緩存產(chǎn)品，如果開啟了持久化（后面會(huì)提到），并且在為并發(fā)量極大的服務(wù)提供支持時(shí)，服務(wù)器硬件資源會(huì)出現(xiàn)大量搶占，請(qǐng)結(jié)合持久策略配置，考慮實(shí)例是否進(jìn)行分盤存儲(chǔ)。

持久化本質(zhì)是將內(nèi)存數(shù)據(jù)同步寫入硬盤（刷盤），而磁盤I/O實(shí)在有限，被迫的寫入阻塞除了造成線程阻塞和服務(wù)超時(shí)，還會(huì)導(dǎo)致額外異常甚至波及其他底層依賴服務(wù)。當(dāng)然，我的建議是，如果條件允許，最好是在項(xiàng)目初期設(shè)計(jì)時(shí)就進(jìn)行規(guī)劃并確定。

2

緩存“表”（Table）

一般緩存中并沒有傳統(tǒng)RDBMS中直觀的表概念（往往以鍵值對(duì)“KV”形式存在），但從結(jié)構(gòu)上來講，鍵值對(duì)本身就可以組裝為各種表結(jié)構(gòu)。一般我會(huì)先生成數(shù)據(jù)庫表關(guān)系圖，然后分析什么時(shí)候存儲(chǔ)字符串，什么時(shí)候存儲(chǔ)對(duì)象，然后使用緩存鍵（KEY）進(jìn)行表和字段（列）分割。

假定需要存儲(chǔ)一個(gè)登錄服務(wù)器表數(shù)據(jù)，包含字段（列）：name、sign、addr，那么可以考慮將數(shù)據(jù)結(jié)構(gòu)拆分為以下形式：

{ key : "server:name" , value : "xxxx" }

{ key : "server:sign" , value : "yyyy" }

{ key : "server:addr" , value : "zzzz" }

需要注意的是，往往在分布式緩存產(chǎn)品中，例如Redis，存在多種數(shù)據(jù)結(jié)構(gòu)（如String、Hash等），還需要根據(jù)數(shù)據(jù)關(guān)聯(lián)性和列的數(shù)量，來選擇對(duì)應(yīng)緩存的存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)，相關(guān)存儲(chǔ)空間和時(shí)間復(fù)雜度是完全不同的，而這個(gè)在初期階段是很難感受到的。

同時(shí)，就算緩存的內(nèi)存設(shè)置的足夠大，剩余也很多，也同樣需要考慮類似RDBMS中的單表容量問題，控制條目數(shù)量不能無限增長(zhǎng)（比如預(yù)知到存儲(chǔ)條目可以輕松達(dá)到百萬級(jí)），“分庫分表”的設(shè)計(jì)思路都是相通的。

3

緩存鍵（Key）

上面提到了基于緩存鍵來設(shè)計(jì)表，這里再單獨(dú)說明一下鍵相關(guān)的個(gè)人規(guī)范。在鍵長(zhǎng)度足夠簡(jiǎn)短的前提下，如果關(guān)聯(lián)相同業(yè)務(wù)模塊，則必須設(shè)計(jì)為以同一個(gè)標(biāo)識(shí)（代號(hào)）開頭，目的是方便查找和統(tǒng)計(jì)管理。

如用戶登錄服務(wù)器列表：

{ key : "ul:server:a" , value : "xxxx" }

{ key : "ul:server:b" , value : "yyyy" }

另外，每個(gè)獨(dú)立業(yè)務(wù)系統(tǒng)可考慮配置一個(gè)唯一的通用前綴標(biāo)識(shí)。當(dāng)然，這里不是必需，若實(shí)際工作中，如果使用的是不同庫，則可以忽略。

4

緩存值（value）

緩存中的值（這里指單一條目）的大小沒有平均標(biāo)準(zhǔn)，但Size自然是越小越好（若使用的是Redis，一次操作的value較大會(huì)直接影響整個(gè)Redis的響應(yīng)時(shí)間，不僅僅是指網(wǎng)絡(luò)I/O）。如果存儲(chǔ)占用空間直達(dá)10M+，建議考慮關(guān)聯(lián)的業(yè)務(wù)場(chǎng)景是否可以拆分為熱點(diǎn)和非熱點(diǎn)數(shù)據(jù)。

5

持久化（Permanence）

上面也簡(jiǎn)單提了下，一般來說，持久和緩存本身是沒有直接關(guān)系的，可以粗略想象為一個(gè)面向硬盤一個(gè)面向內(nèi)存。但如今的Web項(xiàng)目里，有些業(yè)務(wù)場(chǎng)景是高度依賴緩存的，持久化可以一方面幫助提高緩存服務(wù)重啟后的快速恢復(fù)，另一方面提供特定場(chǎng)景下的存儲(chǔ)特性。當(dāng)然，由于持久化必然需要犧牲一些性能，包括CPU的搶占和硬盤I/O影響。不過大多數(shù)時(shí)候是利大于弊，建議在應(yīng)用緩存的時(shí)候，沒有特別情況的話，盡量搭配持久化，無論是使用自身機(jī)制還是第三方來實(shí)現(xiàn)。

如果是使用的Redis，其自身就具備相關(guān)持久策略，包含AOF和RDB，我在大多數(shù)情況下是兩者同時(shí)配置的（當(dāng)然，最新官方版本本身也提供了混合模式）。如果在一些非高并發(fā)的場(chǎng)景下，或者說在一些中小項(xiàng)目的管理模塊里，僅僅只是作為優(yōu)化手段，確定了不需持久，也可以直接設(shè)置關(guān)閉，節(jié)約性能開銷損耗，但建議在程序中將該實(shí)例做好標(biāo)注，確保該實(shí)例的公共使用范圍。

6

淘汰（Eliminate）

緩存如果無限制的增長(zhǎng)，即使設(shè)置了較短的過期（Expiration ），在一些時(shí)間點(diǎn)上，高并發(fā)的一批大數(shù)據(jù)會(huì)在較短時(shí)間內(nèi)就達(dá)到了可使用內(nèi)存的峰頂，此時(shí)程序中與緩存服務(wù)器的交互會(huì)出現(xiàn)大量延遲和錯(cuò)誤，甚至給服務(wù)器自身都帶來了嚴(yán)重的不穩(wěn)定性。所以在生產(chǎn)環(huán)境里盡量給緩存配置最大內(nèi)存限制，以及適當(dāng)?shù)奶蕴呗浴?

如果使用的是Redis，自身淘汰策略選擇比較靈活。

個(gè)人的設(shè)計(jì)是，在數(shù)據(jù)呈現(xiàn)類似冪律分布情況下，總有大量數(shù)據(jù)訪問較低，我會(huì)選擇配置allkeys-lru、volatile-lru，將最少訪問的數(shù)據(jù)進(jìn)行淘汰。再比如緩存是作為日志應(yīng)用的，那么我一般是項(xiàng)目前期是配置no-enviction，后期會(huì)配置為volatile-ttl。

當(dāng)然，我也見過一種特殊業(yè)務(wù)下的設(shè)計(jì)，緩存直接用來作為輕量的持久數(shù)據(jù)庫使用，而且是終端，開始覺得有些新奇，后來發(fā)現(xiàn)是非常符合業(yè)務(wù)設(shè)計(jì)的（比如幾乎沒有任何復(fù)雜邏輯和強(qiáng)事務(wù)）。所以合情合理，確實(shí)不應(yīng)該禁錮在傳統(tǒng)設(shè)計(jì)里，畢竟架構(gòu)總是基于業(yè)務(wù)去實(shí)時(shí)組合和改變的。

順便在此給大家推薦一個(gè)Java架構(gòu)方面的交流學(xué)習(xí)群： 698581634 ，里面會(huì)分享一些資深架構(gòu)師錄制的視頻資料：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系，主要針對(duì)Java開發(fā)人員提升自己，突破瓶頸，相信你來學(xué)習(xí)，會(huì)有提升和收獲。

三、一級(jí)緩存的基礎(chǔ)CURD及相關(guān)

1

新增（Create）

如果沒有特殊業(yè)務(wù)需求（如上面提到的），插入必須設(shè)置過期時(shí)間。同時(shí)，盡量保證過期隨機(jī)性。如果是進(jìn)行批量緩存，則個(gè)人的做法是保證設(shè)置的過期時(shí)間上至少是分散的，目的是為了降低緩存雪崩等風(fēng)險(xiǎn)和影響（關(guān)于這些我會(huì)在以后的擴(kuò)展篇里嘗試闡述）。

如：批量緩存的對(duì)象是一個(gè)結(jié)果集，條目有10萬條，緩存時(shí)間基礎(chǔ)為 60*60*2（sec），現(xiàn)在需要同時(shí)進(jìn)行緩存。我的做法是默認(rèn)生成一個(gè)隨機(jī)數(shù)，如random（范圍 0 - 1000），過期時(shí)間則設(shè)置為( 60*60*2 + random ) 。

2

修改（Update）

更新一條緩存的數(shù)據(jù)，注意是否需要重新調(diào)整過期時(shí)間。同時(shí)在很多場(chǎng)合，如多個(gè)緩存間同步時(shí)，建議直接刪除該緩存，而不是更新緩存。修改操作很多時(shí)候是關(guān)聯(lián)到DB間的同步操作的，相對(duì)考究的多一些，需要權(quán)衡分布式事務(wù)上的問題，后續(xù)文章里會(huì)寫到。

3

讀取（Read）

查找緩存時(shí)，如果存在多條，并確定數(shù)據(jù)量不大，務(wù)必使用嚴(yán)格匹配key的模式，而盡量不要使用通配符方式。雖然發(fā)送指令的key數(shù)據(jù)變長(zhǎng)了，但卻避免了不必要的緩存內(nèi)的搜索性能損耗。

例如單純相信Redis里自身的存儲(chǔ)優(yōu)化，無限制的使用 keys pattern而不考慮時(shí)間復(fù)雜度，同時(shí)造成大量線程阻塞（這里與主從復(fù)制無關(guān)）。如果折中使用scan分頁替代，也并非一種“無憂”的實(shí)現(xiàn)，一是需要在程序代碼的封裝里設(shè)置較低的容量，二是請(qǐng)務(wù)必在程序邏輯里對(duì)數(shù)據(jù)幻讀等潛在問題做相關(guān)的管控處理。

另外可以額外類比一種場(chǎng)景，操作DB中的大表，命中的熱點(diǎn)數(shù)據(jù)分布靠后。

4

刪除/清空（Delete/Clear）

刪除緩存，一般有直接移除和設(shè)置時(shí)間過期（并不是任何時(shí)候都是滑動(dòng)增加過期）兩種方式，沒什么細(xì)節(jié)上的說明。不過我倒是聽過一種特殊業(yè)務(wù)場(chǎng)合，批量請(qǐng)求同類數(shù)據(jù)，并且即時(shí)性沒有很高要求，設(shè)置過期時(shí)間并將時(shí)間稍作分散。

清空緩存，我在項(xiàng)目里目前并未應(yīng)用，甚至也不提倡直接使用。但是假如在應(yīng)用時(shí)，需要慎重考慮兩個(gè)地方：一是清理時(shí)機(jī)，二是清理時(shí)效（若在Redis里，無論是flushdb或者flushall，都會(huì)形成一定阻塞）

5

鎖/信號(hào)（Locking）

本身無關(guān)緩存，屬于一些并發(fā)特性實(shí)現(xiàn)，有一定的適用場(chǎng)景。這在Redis中有一些基于原子的實(shí)現(xiàn)，但與本系列討論無關(guān)。

6

發(fā)布-訂閱（Publish-Subscribe）

為什么提到這個(gè)跟生產(chǎn)消費(fèi)（Produce-Consume）相關(guān)的動(dòng)作呢？這個(gè)機(jī)制本身是不屬于緩存自身的范疇的，而是更相關(guān)于消息隊(duì)列（Message Queue）。之所以提到，是因?yàn)槿缃裰髁鞯木彺娈a(chǎn)品都自帶這一特性，很多場(chǎng)景使用起來較方便，配置也簡(jiǎn)單，效率也夠快。只是，往往會(huì)造成濫用。最關(guān)鍵是不必要的強(qiáng)耦合也降低了整體靈活性和性能，擴(kuò)展性也實(shí)在有限。當(dāng)然，這是我目前的看法。

我的建議是：如果沒有特殊的場(chǎng)景應(yīng)用，盡量不使用。至少本人是不會(huì)優(yōu)先推薦使用緩存自身的發(fā)布訂閱的，甚至在緩存集群系統(tǒng)中，需要考究的細(xì)節(jié)更多。

而推薦的方式是，使用其他專業(yè)中間件解決，如基于MQ的產(chǎn)品替代方案。具體的候選有優(yōu)秀的開源作品如RabbitMQ、Kafka等，包括有朋友提到的近兩年國(guó)內(nèi)阿里研發(fā)的RocketMQ等等，但是個(gè)人目前使用較多的依然是RabbitMQ。當(dāng)然，這里不去過多贅述了，根據(jù)場(chǎng)景選擇，合適的場(chǎng)景選用最合適的技術(shù)方案即可吧。

原文鏈接：www.cnblogs.com/bsfz/p/9568591.html