本篇已收錄至redis in action 學習筆記系列
1. 介紹
redis 是一款開源的內存型數據庫工具. 在項目中通常會被用於作為數據緩存工具, 這樣會提升某些熱點數據的訪問效率, 同樣也降低了數據庫的壓力. 所以了解和掌握使用 redis 是非常之必要的.
下圖是沒有使用緩存數據庫的結構, 數據都是從數據庫獲取的. 對於熱點數據的頻繁訪問會對數據庫造成很大的壓力, 可能會導致服務不可用等問題:
此時為了提升數據訪問效率, 我們可以對熱點數據進行緩存, 放入 redis 數據庫中. 由於 redis 是利用內存對數據進行存儲的. 所以速度超快. 但是內存的資源往往是有限的.
如果數據通過 redis 能夠獲取得到, 就可以直接返回給用戶使用. 如果訪問不到, 再通過服務器端訪問數據庫得到.
(上述內容和圖片都是極為簡化版本的描述, 這里旨在對 redis 的理解, 而不針對復雜場景中具體的問題的解決方案)
2. windows 環境下安裝和運行 Redis
redis 屬於 C/S 結構的工具. 也就是說你要有一個 redis server, 還有一個 redis client.
http://try.redis.io/ 這個網站提供了線上使用 redis. 基於學習為目的線上和線下都可以我覺得.
下載地址:
https://github.com/microsoftarchive/redis/releases
windows 下載 zip 壓縮文件后, 解壓到本地即可.
運行 Redis Server
在文件目錄下使用命令行執行:
redis-server.exe redis.windows.conf
運行 Redis Client
在文件目錄下使用命令行執行:
redis-cli.exe -h 127.0.0.1 -p 6379
Redis server 與 client
redis server 是單線程服務器. 基於 Event-Loop 模式來處理 Client 的請求，這樣就不必考慮線程安全的問題, 以及線程之間切換帶來的損耗.
什么是 event-loop (事件循環): 事件循環被稱作循環的原因在於，它一直在查找新的事件並且執行。一次循環的執行稱之為 tick， 在這個循環里執行的代碼稱作 task, 本篇文章不做詳述. 詳情可以上網查或者看看知乎大神寫的帖子 一次搞懂Event loop
項目初期, client 的數量比較少的時候, redis server 能夠很有效的提升數據訪問效率. 但是當 client 逐漸變多后, 原來的結構此時就顯得效率不是那么高了, 主要原因是:
-
client 多了以后, 需要訪問的數據也會變多, 然而單一 server 的內存資源是有限的. 會造成部分數量的數據無法命中緩存.
-
單一 redis 的吞吐量無法滿足數量增多的 client. 這個比較好理解, 其實就是 server 端的單一時間內的處理任務的能力有限.
此時則需要增加 redis 服務器. 使用分布式最常使用的解決方案, redis 服務器集群來解決上述兩個問題.
解決兩個問題:
- 擴大緩存容量
- 提升事件吞吐能力
提出問題: 怎樣根據業務場景設計出合理的復雜均衡算法, 將不同的熱點數據平均分布到 redis server 中? 這個算法在服務端一般在什么位置?
上圖中的架構雖然能夠解決一部分問題, 但是還不能滿足更復雜的場景. 比如:
- 當某一台 redis server 宕機, 數據丟失時會導致大量的數據訪問請求直接到數據庫端.
- 某一熱點數據的訪問量激增, 導致單一服務器過於忙碌, 服務器使用體驗降低.
為解決上面兩個問題, 可能除了分布式集群外, 我們還需要引入"Master-Slave(主-從)"服務器機制來解決.
比如每個緩存數據中心都安排兩台 redis 服務器, Master負責接收客戶端的寫入請求，將數據寫到Master后，同步給Slave，實現數據備份。一旦Master掛了，可以將Slave提拔為Master；或者一旦Master發現自己忙不過來了，可以把一些查詢請求，轉發給Slave去處理，也就是Master負責讀寫或者只負責寫，Slave負責讀. 這樣就能夠解決上面的兩個問題.
始終記住在分布式的架構中, 當單一服務器無法滿足需求時, 架構的設計要允許服務器能夠橫向擴展, 才是好的分布式架構. 比如上面的方案, 在更重要的緩存中心節點上, 可能會安排更多個 slave 服務器, 以保證性能.