你是一個程序員，你維護了一個 商品服務(wù)，它背后直連 mysql 數(shù)據(jù)庫。
假設(shè)商品服務(wù)需要對外提供 每秒 1w 次查詢，但背后的 mysql 卻只能提供每秒 5k 次查詢，那 mysql 根本頂不住！分分鐘會被壓垮。

這類大流量查詢場景非常常見，比如雙十一秒殺和春節(jié)搶車票。
那么問題就來了，有沒有辦法在 mysql 不被壓垮的同時，讓商品服務(wù)支持每秒 1w 次查詢 ？
當(dāng)然有，沒有什么是加一層中間層不能解決的，如果有，那就再加一層。
這次我們要加的中間層是Redis。

本地緩存

我們知道，查詢內(nèi)存的速度比查詢磁盤要快， mysql 數(shù)據(jù)主要存放在磁盤里，如果能將 mysql 里的數(shù)據(jù)放內(nèi)存里，查詢完全不走磁盤，那必然能大大提升查詢性能。

我們很容易想到，可以在商品服務(wù)的內(nèi)存中，申請一個字典，在 python 里叫 dict，在 java 里叫 map。

key 是商品 ID，value 是商品數(shù)據(jù)。通過商品 ID, 就能查到商品數(shù)據(jù)。

發(fā)生查詢時，優(yōu)先去查內(nèi)存字典，沒結(jié)果再跑到 mysql 數(shù)據(jù)庫里查詢，再將結(jié)果順手放內(nèi)存字典里，下次就又能從內(nèi)存里查出來啦。

像這樣，放在服務(wù)內(nèi)部的緩存，就是所謂的本地緩存。
有了本地緩存的加持，真正打到 mysql 的查詢量就跟你喜歡的女生回你的消息字數(shù)一樣少，將查詢請求干到 1w qps 是很輕松的事情。

遠程緩存

但問題又來了，為了保證系統(tǒng)高可用，商品服務(wù)經(jīng)常不止一個實例，如果每個實例都重復(fù)緩存一份本地內(nèi)存，那就有些浪費內(nèi)存條了。
所以更好的解決方案是將這部分字典內(nèi)存抽出來，單獨做成一個服務(wù)。它就是所謂的遠程緩存服務(wù)。

但這就引入另外一個問題，多個商品服務(wù)通過網(wǎng)絡(luò)去讀寫同一份遠程緩存，會存在并發(fā)問題。怎么辦呢？
很簡單！對外不管有多少有個網(wǎng)絡(luò)連接，收到讀寫命令后，都統(tǒng)一塞到一個線程上，在一個線程上對字典進行讀寫，什么并發(fā)問題和線程切換開銷，完全不存在！

這個遠程緩存服務(wù)足以滿足大部分場景，但它屬實過于簡陋，我們來看下怎么優(yōu)化它。

多種數(shù)據(jù)類型支持

現(xiàn)在緩存服務(wù)里，只有一個字典類型。key 和 value 都是字符串。但我們平時寫代碼的時候，還會用到很多其他內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)，是不是也可以在緩存服務(wù)里提供類似的數(shù)據(jù)結(jié)構(gòu)？
于是我們對字段的 value 進行擴展，除了 字符串, 還支持先進先出的隊列 List 和用于去重的 Set 類型，再加入可以做排行榜的 ZSet，現(xiàn)在緩存服務(wù)就更強了。

內(nèi)存過期策略

緩存服務(wù)支持的數(shù)據(jù)結(jié)構(gòu)變多了之后，塞到內(nèi)存里的數(shù)據(jù)就越來越多了，內(nèi)存又小又貴，遲早扛不住。
怎么辦呢？我們可以給緩存里的數(shù)據(jù)加個過期時間，一旦數(shù)據(jù)過期，就從內(nèi)存里刪掉，可以很大程度緩解掉內(nèi)存增長速度。
但問題又又來了，我怎么知道哪些數(shù)據(jù)該設(shè)置多長過期時間呢？
完全沒辦法，只能交給調(diào)用方去做判斷，讓用戶通過 expire 命令的形式來指定哪些數(shù)據(jù)多久過期。

緩存淘汰

但你不能指望每個調(diào)用方都是老實人，如果都不設(shè)置過期時間，那內(nèi)存還是得炸。
有解法嗎？
有！在內(nèi)存接近上限的時候，根據(jù)一些策略刪除掉一些內(nèi)存。比如可以將最近最少使用的內(nèi)存刪掉，也就是所謂的 LRU,這樣不僅解決了內(nèi)存過大的問題，還讓 redis 里的數(shù)據(jù)全是熱點數(shù)據(jù)。真是一箭雙雕。

持久化

現(xiàn)在內(nèi)存過大的問題是解決了。但還有個問題，mysql 之所以過得那么舒服，那是因為前面有個緩存服務(wù)擋住了大部分流量。一旦緩存服務(wù)重啟，那內(nèi)存就全丟了，這時候流量會全都打到 mysql 身上，疼得它嗷嗷叫。

所以我們還需要給 redis 加入最大程度的持久化保證。確保服務(wù)重啟后不至于什么數(shù)據(jù)都沒有。
于是可以在緩存服務(wù)里加個異步線程，定期將全量內(nèi)存數(shù)據(jù)定期持久化到磁盤文件里，而這種將內(nèi)存數(shù)據(jù)生成快照保存到文件的方式，就是所謂的 RDB，Redis Database Backup。

它可以每隔幾分鐘記錄下緩存服務(wù) 的全量數(shù)據(jù)，類似于游戲的"存檔"。
這樣就算進程掛了，重啟的時候，通過加載快照文件，就能復(fù)原大部分數(shù)據(jù)。
之所以說是大部分，是因為"存檔"之后寫入的數(shù)據(jù)可能會丟。
那還有其他方式可以保留更多數(shù)據(jù)嗎？有！
全量數(shù)據(jù)備份當(dāng)然耗時，那我們化整為零，在每次寫入數(shù)據(jù)時，順手將數(shù)據(jù)記錄到文件緩存中，并每秒將文件緩存刷入磁盤，這種持久化機制叫 AOF，Append Only File，服務(wù)啟動時跟著文件重新執(zhí)行一遍就能將大部分數(shù)據(jù)還原，最大程度保證了數(shù)據(jù)持久化。

那問題就來了，AOF 文件會不會很大？沒事，定期重寫壓縮就行，比如 a 被依次賦值 a=1，a=2，最終保留 a=2 就夠了。

簡化網(wǎng)絡(luò)協(xié)議

剛剛提到遠程緩存服務(wù)對外提供讀寫能力，那是對外提供的 HTTP 接口嗎？
當(dāng)然不是！
我們知道， HTTP 是基于 TCP 做的通信，實現(xiàn)了很多笨重的特性。
既然當(dāng)初是為了性能，特地上的緩存服務(wù)，那就索性徹底點，拋棄 HTTP，直接基于 TCP 做傳輸就好！傳輸協(xié)議也設(shè)計得簡單點，比如只要通過 TCP 傳入 SET key value，就能完成寫入。傳入"GET key" 就能獲得對應(yīng)的 value。非常簡潔。
那傳輸協(xié)議的解析需要我們自己寫代碼去實現(xiàn)嗎？
完全不需要，redis 官方提供了一個命令行工具，redis-cli，通過它，我們可以輸入一些命令，讀寫 Redis 服務(wù)器里的各種內(nèi)存數(shù)據(jù)。

不想用命令行也沒關(guān)系，各路大神已經(jīng)用各種語言將 redis-cli 支持的命令實現(xiàn)了一遍，完全不需要自己手寫。

Redis 是什么？

好了，到這里，當(dāng)初那個簡陋的遠程緩存服務(wù)，就成了一個高性能，支持多種數(shù)據(jù)類型和各種緩存淘汰策略，并提供一定持久化能力的超強緩存服務(wù)，沒錯，它就是我們常說的 Redis，全稱 Remote Dictionary Server，這名字就很精辟了，說白了 redis 就是個遠程的字典服務(wù)。

redis 作為架構(gòu)中最常用的提速神器，是萬金油一般的存在，將它放在 mysql 面前擋一道查詢只是最基礎(chǔ)的用法。
通過擴展插件，還能實現(xiàn)各種高階玩法。
比如 RedisJSON 支持復(fù)雜的 JSON 查詢和更新，說白了就是內(nèi)存版本的 MongoDB。
RediSearch 支持全文搜索，說白了就是內(nèi)存丐版的 es。
RedisGraph 支持圖數(shù)據(jù)庫功能，類似 Neo4j，RedisTimeSeries 處理時間序列數(shù)據(jù)，也就是內(nèi)存版 InfluxDB。大有一種要在內(nèi)存里將所有中間件都實現(xiàn)一遍的味道。

現(xiàn)在大家通了嗎？

總結(jié)

• redis 本質(zhì)上就是個遠程字典服務(wù)，所有讀寫命令等核心邏輯，都在一個線程上完成。什么并發(fā)問題和線程切換開銷，完全不存在！
• redis 支持多種數(shù)據(jù)類型、內(nèi)存過期策略和多種緩存失效策略，通過 TCP 對外提供了一套非常簡單的傳輸協(xié)議。
• redis 加入了最大程度的持久化保證。將數(shù)據(jù)持久化為 rdb 和 AOF,確保服務(wù)重啟后不至于什么數(shù)據(jù)都沒有。
• redis 支持多種擴展，玩法非常多，比如 RediSearch 和 RedisJSON。