王曉波?

同程旅行機(jī)票事業(yè)群 CTO

讀完需要

12

分鐘

速讀僅需 4 分鐘

本章和大家分享一下同程鳳凰緩存系統(tǒng)在基于 Redis 方面的設(shè)計(jì)與實(shí)踐。在本章中除了會(huì)列舉我們工作過(guò)程中遇到各種問(wèn)題和誤區(qū)外，還會(huì)給出我們相應(yīng)的解決辦法，希望能夠拋磚引玉為大家?guī)?lái)一定的啟示。??

? 本文節(jié)選自中生代技術(shù)社區(qū)出品圖書(shū)《深入分布式緩存》

1

? ?

同程鳳凰緩存系統(tǒng)遇到的問(wèn)題

2012 年～2014 年，我們的業(yè)務(wù)開(kāi)始使用一種新的互聯(lián)網(wǎng)銷(xiāo)售模式——秒殺搶購(gòu)，一時(shí)間，各個(gè)產(chǎn)品線(xiàn)開(kāi)始紛紛加人，今天秒殺門(mén)票，明天秒殺酒店。各種活動(dòng)輪番登場(chǎng)，用戶(hù)在不亦樂(lè)乎地玩著秒殺活動(dòng)的同時(shí)，也對(duì)后端技術(shù)的支撐提出了一波又一波的挑戰(zhàn)。

在第一個(gè)秒殺搶購(gòu)系統(tǒng)上線(xiàn)后不久，流量越來(lái)越大，發(fā)現(xiàn)不對(duì)了：只要秒殺搶購(gòu)一開(kāi)始，卡頓、打不開(kāi)的故障就會(huì)此起彼伏。一旦出現(xiàn)故障，所有人都急得直跳腳，因?yàn)槊霘屬?gòu)流量一下而過(guò)，沒(méi)有機(jī)會(huì)補(bǔ)救。其實(shí)問(wèn)題也很簡(jiǎn)單，一個(gè)有點(diǎn)經(jīng)驗(yàn)的兄弟就很快就將問(wèn)題定位出來(lái)：搶購(gòu)那一下太耗費(fèi)服務(wù)器資源，在同一時(shí)間段內(nèi)涌入的人數(shù)大大超過(guò)了服務(wù)器的負(fù)載，服務(wù)器根本承受不了，CPU 占用率很多時(shí)候都接近了 100%，請(qǐng)求的積壓也很?chē)?yán)重，從請(qǐng)求接人到數(shù)據(jù)的讀取都有問(wèn)題，尤以數(shù)據(jù)的讀取最為嚴(yán)重。在原來(lái)的設(shè)計(jì)方式中雖然也考慮了大并發(fā)量下的數(shù)據(jù)讀取，但是因?yàn)閿?shù)據(jù)相對(duì)分散，讀取時(shí)間相對(duì)拉長(zhǎng)，不像秒殺搶購(gòu)是對(duì)同一批或同一條數(shù)據(jù)進(jìn)行超高并發(fā)的讀取。當(dāng)然秒殺搶購(gòu)不僅僅是數(shù)據(jù)讀取的集中并發(fā)，同時(shí)也是數(shù)據(jù)寫(xiě)入的集中并發(fā)。

問(wèn)題是發(fā)現(xiàn)了，表面上看起來(lái)解決沒(méi)那么簡(jiǎn)單。應(yīng)用層的問(wèn)題解決起來(lái)相對(duì)容易，實(shí)在不行多加點(diǎn)機(jī)器也能解決；但數(shù)據(jù)的問(wèn)題就不是那么簡(jiǎn)單了，靠增加機(jī)器來(lái)解決是不行的。大部分關(guān)系型數(shù)據(jù)庫(kù)沒(méi)有真正的分布式解決方案，最多做一個(gè)主從分離或多加從庫(kù)分擔(dān)讀取的壓力。但因?yàn)槊霘屬?gòu)是數(shù)據(jù)集中式超高并發(fā)的讀，所以一般的關(guān)系型數(shù)據(jù)庫(kù)因?yàn)樗旧砭窒扌院茈y支撐這樣瞬間突發(fā)的高并發(fā)，就算勉強(qiáng)頂上，也會(huì)因?yàn)槊霘屬?gòu)還有寫(xiě)的高并發(fā)，影響到讀節(jié)點(diǎn)的數(shù)據(jù)同步問(wèn)題。當(dāng)然也可以拼命提升一下服務(wù)器的硬件性能，比如換最好的 CPU、把硬盤(pán)換成 SSD 等等，但效果應(yīng)該不會(huì)太顯著，沒(méi)有解決本質(zhì)的問(wèn)題，還比較費(fèi)錢(qián)。

其實(shí)尋找新的解決方案也很簡(jiǎn)單，因?yàn)樵诋?dāng)時(shí)那個(gè)年代的開(kāi)源社區(qū)中有很多的 NoSQL 明星產(chǎn)品（如 Redis 等等）方案，這些方案也都提供了豐富的數(shù)據(jù)類(lèi)型，擁有原子性操作和強(qiáng)大的并發(fā)性能特性，感覺(jué)簡(jiǎn)直就是為搶購(gòu)量身定做的。于是我們也基于此做了一些方案，例如:數(shù)據(jù)在搶購(gòu)活動(dòng)開(kāi)始前被先放到 NoSQL 數(shù)據(jù)庫(kù)里，產(chǎn)生的訂單數(shù)據(jù)先被放到隊(duì)列中,

然后通過(guò)隊(duì)列慢慢消化……這一系列的操作解決了搶購(gòu)的問(wèn)題，這里主要不是講搶購(gòu)技術(shù)方案，我們不再細(xì)化下去。

其實(shí)這樣的解決方案在技術(shù)蠻荒時(shí)代還是相對(duì)靠譜的，在我們技術(shù)強(qiáng)壯的今天，這個(gè)方案還是單薄和弱小了一些，但是所有的技術(shù)點(diǎn)都是這樣一路走來(lái)的。下面我們來(lái)看一下，從弱小走向長(zhǎng)大，經(jīng)歷了哪些？

1.1

? ?

Redis 用法的凌亂

從運(yùn)維角度來(lái)想，Redis 是很簡(jiǎn)單的東西，安裝一下，配置一下，就輕松上線(xiàn)了，再加上 Redis 的一些單進(jìn)程、單線(xiàn)程等特性，可以很穩(wěn)定地給到應(yīng)用層去隨便使用。就像早期的我們，在很短的時(shí)間內(nèi)，Redis 實(shí)例部署達(dá)到了千個(gè)以上，用得多了真正的問(wèn)題開(kāi)始出現(xiàn)。什么問(wèn)題？亂的問(wèn)題。Redis 從使用的角度來(lái)講是需要像應(yīng)用服務(wù)一樣去治理的。為什么是需要治理的？我們先來(lái)看一些常見(jiàn)的運(yùn)維與開(kāi)發(fā)的聊天記錄，大家會(huì)不會(huì)有一些風(fēng)趣的感覺(jué)：

開(kāi)發(fā)：“Redis 為啥不能訪(fǎng)問(wèn)了?”
運(yùn)維：“剛剛服務(wù)器內(nèi)存壞了，服務(wù)器自動(dòng)重啟了。”
開(kāi)發(fā)：“為什么 Redis 延遲這么久?”
運(yùn)維：“大哥，不要在 Zset 里面放幾萬(wàn)條數(shù)據(jù)，插入排序的后果很?chē)?yán)重啊!”
開(kāi)發(fā)：“我寫(xiě)進(jìn)去的 key 呢，為什么不見(jiàn)了?”
運(yùn)維：“你的 Redis 超過(guò)最大大小了，不常用的 key 都丟了呀!”
開(kāi)發(fā)：“剛剛為啥讀取全部失敗了?”
運(yùn)維：“剛剛網(wǎng)絡(luò)臨時(shí)中斷了一下，slave 全同步了，在全同步完成之前，slave 的讀取全部失敗。”
開(kāi)發(fā)：“我剛剛想到一個(gè)好方案，我需要 800GB 的 Redis，什么時(shí)候能準(zhǔn)備好呢？”
運(yùn)維：“大哥，我們線(xiàn)上的服務(wù)器最大也就 256GB，別玩這么大好嗎？”

光看這么一小點(diǎn)就感覺(jué)問(wèn)題很多了，開(kāi)發(fā)和運(yùn)維都疲于奔命地解決這些看上去很無(wú)聊的問(wèn)題。這些問(wèn)題從本質(zhì)上來(lái)講還只是麻煩，談不上困難。但是每當(dāng)這些麻煩演變成一次 Redis 的故障時(shí)，哪怕是小故障，有時(shí)也會(huì)造成大痛苦，因?yàn)楫吘贡４嬖趦?nèi)存里的數(shù)據(jù)太脆弱了，一不小心數(shù)據(jù)就會(huì)全部消失了。為此，當(dāng)時(shí)也是絞盡腦汁，想了很多種辦法

單機(jī)不是不安全嗎？那么就開(kāi)啟主從+Keepalived，用虛 IP 地址在 master 和 slave 兩邊漂移，master 掛了直接切換到 slave。

數(shù)據(jù)放內(nèi)存不是不安全嗎？可以開(kāi)啟數(shù)據(jù)落盤(pán)，根據(jù)業(yè)務(wù)需要決定落盤(pán)規(guī)則，有 AOF 的，也有 RDB 的。

使用上不是有問(wèn)題嗎？那么多開(kāi)幾場(chǎng)培訓(xùn)，跟大家講講 Redis 的用法和規(guī)范。

以上策略在當(dāng)時(shí)似乎很完美，但是沒(méi)多久，均宣告失敗，這是必然的。

為什么呢？先看那個(gè)主從+Keepalived 的方案，這本來(lái)是個(gè)很好的方案，但是忽略了主數(shù)據(jù)節(jié)點(diǎn)掛掉的情況。我們?cè)谇懊嬲f(shuō)過(guò)，Redis 的單進(jìn)程、單線(xiàn)程設(shè)計(jì)是其簡(jiǎn)單和穩(wěn)定的基石，只要不是服務(wù)器發(fā)生了故障，在一般情況下是不會(huì)掛的。

但同時(shí)，單進(jìn)程、單線(xiàn)程的設(shè)計(jì)會(huì)導(dǎo)致 Redis 接收到復(fù)雜指令時(shí)會(huì)忙于計(jì)算而停止響應(yīng)，可能就因?yàn)橐粋€(gè) Zset 或者 keys 之類(lèi)的指令，Redis 計(jì)算時(shí)間稍長(zhǎng)，Keepalived 就認(rèn)為其停止了響應(yīng)，直接更改虛 IP 的指向，然后做一次主從切換。過(guò)不了多久，Zset 和 keys 之類(lèi)的指令又會(huì)從客戶(hù)端發(fā)送過(guò)來(lái)，于是從機(jī)上又開(kāi)始堵塞，Keepalived 就一直在主從機(jī)之間不斷地切換 IP。終于主節(jié)點(diǎn)和從節(jié)點(diǎn)都堵了，Keepalived 發(fā)現(xiàn)后，居然直接將虛 IP 釋放了，然后所有的客戶(hù)端都無(wú)法連接 Redis 了，只能等運(yùn)維到線(xiàn)上手工綁定才行。

數(shù)據(jù)落盤(pán)也引起了很大的問(wèn)題，RDB 屬于非阻塞式的持久化，它會(huì)創(chuàng)建一個(gè)子進(jìn)程來(lái)專(zhuān)門(mén)把內(nèi)存中的數(shù)據(jù)寫(xiě)人 RDB 文件里，同時(shí)主進(jìn)程可以處理來(lái)自客戶(hù)端的命令請(qǐng)求。但子進(jìn)程內(nèi)的數(shù)據(jù)相當(dāng)于是父進(jìn)程的一個(gè)拷貝，這相當(dāng)于兩個(gè)相同大小的 Redis 進(jìn)程在系統(tǒng)上運(yùn)行，會(huì)造成內(nèi)存使用率的大幅增加。如果在服務(wù)器內(nèi)存本身就比較緊張的情況下再進(jìn)行 RDB 配置，內(nèi)存占用率就會(huì)很容易達(dá)到 100%，繼而開(kāi)啟虛擬內(nèi)存和進(jìn)行磁盤(pán)交換，然后整個(gè) Redis 的服務(wù)性能就直線(xiàn)下降了。

另外，Zset、發(fā)布訂閱、消息隊(duì)列、Redis 的各種功能不斷被介紹，開(kāi)發(fā)者們也在利用這些特性，開(kāi)發(fā)各種應(yīng)用，但從來(lái)沒(méi)想過(guò)這么一個(gè)小小的 Redis 有這么多新奇的功能，它的缺點(diǎn)在什么地方，什么樣的場(chǎng)景是不合適用的？

這時(shí) Redis 在大部分的開(kāi)發(fā)者手上就是像是一把錘子，看什么都是釘子，隨時(shí)都一錘了事。同時(shí)也會(huì)漸漸地淡忘了開(kāi)發(fā)的一些細(xì)節(jié)點(diǎn)和規(guī)范，因?yàn)橛盟鉀Q性能的問(wèn)題是那么輕松簡(jiǎn)單，于是一些基于 Redis 的新奇功能就接連不斷地出現(xiàn)了：基于 Redis 的分布式鎖、日志系統(tǒng)、消息隊(duì)列、數(shù)據(jù)清洗，等等，各種各樣的功能不斷上線(xiàn)使用，從而引發(fā)了各種各樣的問(wèn)題。這時(shí)候原來(lái)那個(gè)救火神器就會(huì)變成

四處點(diǎn)火的神器，Redis 堵塞、網(wǎng)卡打爆、連接數(shù)爆表等問(wèn)題層出不窮，經(jīng)過(guò)這么多折騰，Redis 終于也變成了大家的噩夢(mèng)了。

1.2

? ?

從實(shí)際案例再看 Redis 的使用

第一個(gè)案例

在一個(gè)炎熱的夏天，引爆了埋藏已久的大炸彈。首先是一個(gè)產(chǎn)品線(xiàn)開(kāi)發(fā)人員搭建起了一套龐大的價(jià)格存儲(chǔ)系統(tǒng)，底層是關(guān)系型數(shù)據(jù)庫(kù)，只用來(lái)處理一些事務(wù)性的操作和存放一些基礎(chǔ)數(shù)據(jù)；在關(guān)系型數(shù)據(jù)庫(kù)的上面還有一套 MongoDB，因?yàn)?MongoDB 的文檔型數(shù)據(jù)結(jié)構(gòu)，讓他們用起來(lái)很順手，同時(shí)也可以支撐一定量的并發(fā)。在大部分情況下，一次大數(shù)據(jù)量的計(jì)算后結(jié)果可以重用但會(huì)出現(xiàn)細(xì)節(jié)數(shù)據(jù)的頻繁更新，所以他們又在 MongoDB 上搭建了一層 Redis 的緩存，這樣就形成了數(shù)據(jù)庫(kù)→ MongoDB → Redis 三級(jí)的方式，對(duì)方案本身不評(píng)價(jià)，因?yàn)檫@不是本文重點(diǎn)，我們來(lái)看 Redis 這層的情況。由于數(shù)據(jù)量巨大，所以需要 200GB 的 Redis。并且在真實(shí)的調(diào)用過(guò)程中，Redis 是請(qǐng)求量最大的點(diǎn)，當(dāng)然如果 Redis 有故障時(shí)，也會(huì)有備用方案，從后面的 MongoDB 和數(shù)據(jù)庫(kù)中重新加載數(shù)據(jù)到 Redis，就是這么一套簡(jiǎn)單的方案上線(xiàn)了。

當(dāng)這個(gè)系統(tǒng)剛開(kāi)始運(yùn)行的時(shí)候，一切都還安好，只是運(yùn)維同學(xué)有點(diǎn)傻眼了，用 200GB 的 Redis 單服務(wù)器去做，它的故障可能性太大了，所以大家建議將它分片，沒(méi)分不知道，一分嚇一跳，各種類(lèi)型用得太多了，特別是里面還有一些類(lèi)似消息隊(duì)列使用的場(chǎng)景。由于開(kāi)發(fā)同學(xué)對(duì) Redis 使用的注意點(diǎn)關(guān)注不夠，一味地濫用，一錘了事，所以讓事情變得困難了。

有些僥幸不死的想法是會(huì)傳染的，這時(shí)的每個(gè)人都心存僥幸、懶惰心理，都想著：“這個(gè)應(yīng)該沒(méi)事，以后再說(shuō)吧，先做個(gè)主從，掛了就起從”，這種僥幸也是對(duì) Redis 的虛偽的信心，無(wú)知者無(wú)畏。可惜事情往往就是怕什么來(lái)什么，在大家快樂(lè)并放肆地使用時(shí)，系統(tǒng)中重要的節(jié)點(diǎn) MongoDB 由于系統(tǒng)內(nèi)核版本的 BUG，造成整個(gè) Mongodb 集群掛了！(這里不多說(shuō) MongoDB 的事情，這也是一個(gè)好玩的“哭器”)。當(dāng)然對(duì)天天與故障為朋友的運(yùn)維同學(xué)來(lái)說(shuō)這個(gè)沒(méi)什么，對(duì)整個(gè)系統(tǒng)來(lái)說(shuō)問(wèn)題也不大，因?yàn)榇蟛糠终?qǐng)求調(diào)用都是在最上層的 Redis 中完成的，只要做一定降級(jí)就行，等拉起了 MongoDB 集群后自然就會(huì)好了。

但此時(shí)可別忘了那個(gè) Redis，是一個(gè) 200GB 大的 Redis，更是帶了個(gè)從機(jī)的 Redis，所以這時(shí)的 Redis 是絕對(duì)不能出任何問(wèn)題的，一旦有故障，所有請(qǐng)求會(huì)立即全部打向最底層的關(guān)系型數(shù)據(jù)庫(kù)，在如此大量的壓力下，數(shù)據(jù)庫(kù)瞬間就會(huì)癱瘓。但是，怕什么來(lái)什么，還是出了狀況：主從 Redis 之間的網(wǎng)絡(luò)出現(xiàn)了一點(diǎn)小動(dòng)蕩，想想這么大的一個(gè)東西在主從同步，一旦網(wǎng)絡(luò)動(dòng)蕩了一下下，會(huì)怎么樣呢？主從同步失敗，同步失敗就直接開(kāi)啟全同步，于是 200GB 的 Redis 瞬間開(kāi)始全同步，網(wǎng)卡瞬間打滿(mǎn)。為了保證 Redis 能夠繼續(xù)提供服務(wù)，運(yùn)維同學(xué)，直接關(guān)掉從機(jī)，主從同步不存在了，流量也恢復(fù)正常。不過(guò)，主從的備份架構(gòu)變成了單機(jī) Redis，心還是懸著的。俗話(huà)說(shuō)，福無(wú)雙至，禍不單行。這 Redis 由于下層降級(jí)的原因并發(fā)操作量每秒增加到 4 萬(wàn)多，AOF 和 RDB 庫(kù)明顯扛不住。同樣為了保證能持續(xù)地提供服務(wù)，運(yùn)維同學(xué)也關(guān)掉了 AOF 和 RDB 的數(shù)據(jù)持久化。連最后的保護(hù)也沒(méi)有了（其實(shí)這個(gè)保護(hù)本來(lái)也沒(méi)用，200GB 的 Redis 恢復(fù)太大了)。

至此，這個(gè) Redis 變成了完全的單機(jī)內(nèi)存型，除了祈禱它不要掛，已經(jīng)沒(méi)有任何方法了。懸著好久，直到修復(fù) MongoDB 集群，才了事。如此僥幸，沒(méi)出大事，但心里會(huì)踏實(shí)嗎？不會(huì)。在這個(gè)案例中主要的問(wèn)題在于對(duì) Redis 過(guò)度依賴(lài)，Redis 看似簡(jiǎn)單而方便地為系統(tǒng)帶來(lái)了性能提升和穩(wěn)定性，但在使用中缺乏對(duì)不同場(chǎng)景的數(shù)據(jù)的分離造成了一個(gè)邏輯上的單點(diǎn)問(wèn)題。當(dāng)然這個(gè)問(wèn)題我們可以通過(guò)更合理的應(yīng)用架構(gòu)設(shè)計(jì)來(lái)解決，但是這樣解決不夠優(yōu)雅也不夠徹底，還增加了應(yīng)用層的架構(gòu)設(shè)計(jì)的麻煩。

Redis 的問(wèn)題就應(yīng)該在基礎(chǔ)緩存層來(lái)解決，這樣即使還有類(lèi)似的情況也沒(méi)有問(wèn)題，因?yàn)榛A(chǔ)緩存層已經(jīng)能適應(yīng)這樣的用法，也會(huì)讓?xiě)?yīng)用層的設(shè)計(jì)更為簡(jiǎn)單（簡(jiǎn)單其實(shí)一直是架構(gòu)設(shè)計(jì)所追求的，Redis 的大量隨意使用本身就是追求簡(jiǎn)單的副產(chǎn)品，那我們?yōu)槭裁床蛔屵@種簡(jiǎn)單變?yōu)檎鎸?shí)呢？）

第二個(gè)案例

有個(gè)部門(mén)用自己現(xiàn)有 Redis 服務(wù)器做了一套日志系統(tǒng)，將日志數(shù)據(jù)先存儲(chǔ)到 Redis 里面，再通過(guò)其他程序讀取數(shù)據(jù)并進(jìn)行分析和計(jì)算，用來(lái)做數(shù)據(jù)報(bào)表。當(dāng)他們做完這個(gè)項(xiàng)目之后，這個(gè)日志組件讓他們覺(jué)得用得很過(guò)癮。他們都覺(jué)得這個(gè)做法不錯(cuò)，可以輕松地記錄日志，分析起來(lái)也挺快，還用什么公司的分布式日志服務(wù)啊。于是隨著時(shí)間的流逝，這個(gè) Redis 上已經(jīng)悄悄地掛載了數(shù)千個(gè)客戶(hù)端，每秒的并發(fā)量數(shù)萬(wàn)，系統(tǒng)的單核 CPU 使用率也接近 90%了，此時(shí)這個(gè) Redis 已經(jīng)開(kāi)始不堪重負(fù)。終于，壓死駱駝的最后一根稻草來(lái)了，有程序向這個(gè)日志組件寫(xiě)入了一條 7MB 的日志（哈哈，這個(gè)容量可以寫(xiě)一部小說(shuō)了，這是什么日志啊)，于是 Redis 堵死了，一旦堵死，數(shù)千個(gè)客戶(hù)端就全部無(wú)法連接，所有日志記錄的操作全部失敗。

其實(shí)日志記錄失敗本身應(yīng)該不至于影響正常業(yè)務(wù)，但是由于這個(gè)日志服務(wù)不是公司標(biāo)準(zhǔn)的分布式日志服務(wù)，所以關(guān)注的人很少，最開(kāi)始寫(xiě)它的開(kāi)發(fā)同學(xué)也不知道會(huì)有這么大的使用量，運(yùn)維同學(xué)更不知有這個(gè)非法的日志服務(wù)存在。這個(gè)服務(wù)本身也沒(méi)有很好地設(shè)計(jì)容錯(cuò)，所以在日志記錄的地方就直接拋出異常，結(jié)果全公司相當(dāng)一部分的業(yè)務(wù)系統(tǒng)都出現(xiàn)了故障，監(jiān)控系統(tǒng)中“5XX”的錯(cuò)誤直線(xiàn)上升。一幫人欲哭無(wú)淚，頂著巨大的壓力排查問(wèn)題，但是由于受災(zāi)面實(shí)在太廣，排障的壓力是可以想象的。這個(gè)案例中的問(wèn)題看似是因?yàn)橐粋€(gè)日志服務(wù)沒(méi)做好或者是開(kāi)發(fā)流程管理不到位導(dǎo)致的。而且很多日志服務(wù)也都用到了 Redis 做收集數(shù)據(jù)的緩沖，好像也沒(méi)什么問(wèn)題。其實(shí)不然，像這樣大規(guī)模大流量的日志系統(tǒng)從收集到分析要細(xì)細(xì)考慮的技術(shù)點(diǎn)是巨大的，而不只是簡(jiǎn)單的寫(xiě)人性能的問(wèn)題。

在這個(gè)案例中 Redis 給程序帶來(lái)的是超簡(jiǎn)單的性能解決方案，但這個(gè)簡(jiǎn)單是相對(duì)的，它是有場(chǎng)景限制的。在這里這樣的簡(jiǎn)單就是毒藥，無(wú)知地吃下是要害死自己的，這就像“一條在小河溝里無(wú)所不能傲慢的小魚(yú)，那是因?yàn)樗鼪](méi)見(jiàn)過(guò)大海，等到了大海……”。

在這個(gè)案例中的另一問(wèn)題：一個(gè)非法日志服務(wù)的存在，表面上是管理問(wèn)題，實(shí)質(zhì)上還是技術(shù)問(wèn)題，因?yàn)?Redis 的使用無(wú)法像關(guān)系型數(shù)據(jù)庫(kù)那樣有 DBA 的監(jiān)管，它的運(yùn)維者無(wú)法管理和提前知道里面放的是什么數(shù)據(jù)，開(kāi)發(fā)者也無(wú)須任何申明就可以向 Redis 中寫(xiě)人數(shù)據(jù)并使用；

所以這里我們發(fā)現(xiàn) Redis 的使用沒(méi)這些場(chǎng)景的管理后在長(zhǎng)期的使用中比較容易失控，我們需要一個(gè)對(duì) Redis 使用可治理和管控的透明層。

通過(guò)兩個(gè)小例子可以看到，在 Redis 亂用的那個(gè)年代里，使用它的兄弟們一定是痛的，承受了各種故障的狂轟濫炸：

• Redis 被 keys 命令堵塞了。

• Keepalived 切換虛 IP 失敗，虛 IP 被釋放了。

• 用 Redis 做計(jì)算了，Redis 的 CPU 占用率成了 100%了。

• 主從同步失敗了。

• Redis 客戶(hù)端連接數(shù)爆了。

• ... ...

（未完待續(xù)）

想要加入中生代架構(gòu)群的小伙伴，請(qǐng)?zhí)砑尤汉匣锶?strong>大白的微信

申請(qǐng)備注（姓名+公司+技術(shù)方向）才能通過(guò)哦！

阿里技術(shù)精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫(huà)像

多隆：從工程師到阿里巴巴合伙人

阿里技術(shù)專(zhuān)家楚衡：架構(gòu)制圖的工具與方法論

螞蟻集團(tuán)技術(shù)專(zhuān)家山丘：性能優(yōu)化常見(jiàn)壓測(cè)模型及優(yōu)缺點(diǎn)

阿里文娛技術(shù)專(zhuān)家戰(zhàn)獒: 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)詳解之What, Why, How?

阿里專(zhuān)家馬飛翔：一文讀懂架構(gòu)整潔之道

阿里專(zhuān)家常昊：新人如何上手項(xiàng)目管理？

螞蟻集團(tuán)沈凋墨：Kubernetes-微內(nèi)核的分布式操作系統(tǒng)

阿里合伙人范禹：常掛在阿里技術(shù)人嘴邊的四句土話(huà)

阿里技術(shù)專(zhuān)家都鐸：一文搞懂技術(shù)債

支付寶研究員兼OceanBase總架構(gòu)師楊傳輝：我在數(shù)據(jù)庫(kù)夢(mèng)之隊(duì)的十年成長(zhǎng)路

阿里技術(shù)專(zhuān)家麒燁：修煉測(cè)試基本功

阿里計(jì)算平臺(tái)掌門(mén)人賈揚(yáng)清：我對(duì)人工智能方向的一點(diǎn)淺見(jiàn)

螞蟻資深算法專(zhuān)家周俊：從原理到落地，支付寶如何打造保護(hù)隱私的共享智能？

阿里高級(jí)技術(shù)專(zhuān)家簫逸：如何畫(huà)好一張架構(gòu)圖？

阿里高級(jí)技術(shù)專(zhuān)家張建飛：應(yīng)用架構(gòu)分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)之道

螞蟻科技 Service Mesh 落地實(shí)踐與挑戰(zhàn) | GIAC 實(shí)錄

阿里6年，我的技術(shù)蛻變之路！

螞蟻集團(tuán)涵暢：再啟程，Service Mesh 前路雖長(zhǎng)，尤可期許

阿里P9專(zhuān)家右軍：大話(huà)軟件質(zhì)量穩(wěn)定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個(gè)標(biāo)簽

阿里高工流生 | 云原生時(shí)代的 DevOps 之道

阿里高級(jí)技術(shù)專(zhuān)家邱小俠：微服務(wù)架構(gòu)的理論基礎(chǔ) - 康威定律

阿里P9專(zhuān)家右軍：以終為始的架構(gòu)設(shè)計(jì)

阿里P8架構(gòu)師：淘寶技術(shù)架構(gòu)從1.0到4.0的架構(gòu)變遷！12頁(yè)P(yáng)PT詳解

阿里技術(shù)：如何畫(huà)出一張合格的技術(shù)架構(gòu)圖？

螞蟻資深技術(shù)專(zhuān)家王旭：開(kāi)源項(xiàng)目是如何讓這個(gè)世界更安全的？

阿里資深技術(shù)專(zhuān)家崮德：8 個(gè)影響我職業(yè)生涯的重要技能

儒梟：我看技術(shù)人的成長(zhǎng)路徑

阿里高級(jí)技術(shù)專(zhuān)家宋意：平凡人在阿里十年的成長(zhǎng)之旅

阿里技術(shù)專(zhuān)家甘盤(pán)：淺談雙十一背后的支付寶LDC架構(gòu)和其CAP分析

阿里技術(shù)專(zhuān)家光錐：億級(jí)長(zhǎng)連網(wǎng)關(guān)的云原生演進(jìn)之路

阿里云原生張羽辰：服務(wù)發(fā)現(xiàn)技術(shù)選型那點(diǎn)事兒

螞蟻研究員玉伯：做一個(gè)簡(jiǎn)單自由有愛(ài)的技術(shù)人

阿里高級(jí)技術(shù)專(zhuān)家至簡(jiǎn): Service Mesh 在超大規(guī)模場(chǎng)景下的落地挑戰(zhàn)

阿里巴巴山獵：手把手教你玩轉(zhuǎn)全鏈路監(jiān)控

阿里涉江：你真的會(huì)學(xué)習(xí)嗎？從結(jié)構(gòu)化思維說(shuō)起

螞蟻金服資深技術(shù)專(zhuān)家經(jīng)國(guó)：云原生時(shí)代微服務(wù)的高可用架構(gòu)設(shè)計(jì)

深入分布式緩存之EVCache探秘開(kāi)局篇

? ?END ? ?? #架構(gòu)師必備#點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的同程旅行王晓波：同程凤凰缓存系统在基于 Redis 方面的设计与实践（上篇）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。