Redis 架構是如何演進的？為什么？

作者：碼哥 2024-04-24 07:00:00

Redis 受歡迎主要原因是極高的性能以及豐富、方便使用的數據結構，這些簡單好用的數據結構大幅度降低開發業務復雜度。大家都在緊貼用戶需求，開發更多的數據結構。

Redis 現在已經十分流行，互聯網幾乎所有項目都會用到，在使用 Redis 時，你知道是如何保證穩定和高效的提供服務呢，它的架構演化路程是什么呢？

2010 年，Redis 1.0 版本發布，這個架構非常簡單。你的業務系統可以把 Redis 作為緩存系統，從 MySQL 查詢數據，接著寫入到 Redis 中，之后業務系統再從 Redis 中讀取這些數據。

就這樣想享受 Redis 快到飛起的性能。然而，隨著時間的推移，業務體諒發展起來，忽然有一天，Redis 宕機，所有的流量會打到 MySQL 上，嚴重的話還會壓垮 MySQL。

于是趕緊重啟 Redis，可是因為 Redis 都是把數據保存在內存中，盡管你把 Redis 重啟了，之前的戶數也丟失了。流量依然會打到 MySQL 上，咋辦呢？

于是，2013 年，Redis 2.8 版本發布，迎來了數據持久化。我們總不能每次寫數據都寫磁盤，這樣太慢了，于是 Redis 引入 RDB 內存快照的方式實現持久化。

定時的把當前 Redis Redis 中的數據，寫到磁盤上的 RDB 文件就可以了。除了 RDB 內存快照文件做持久化以外，還支持 AOF 文件。也就是將每次寫指令都寫到 AOF 文件中。

似乎經過上面的優化，你再也不擔心 Redis 宕機了，即使宕機，也可以通過持久化文件快速恢復 Redis 中的數據。

可事情并沒這么簡單，如果一個一個實例宕機，我們是否可以部署多個 Redis 實例，并保持實時數據同步，當一個實例宕機，手動從剩下的實例提升為 master 繼續提供服務實現高可用。

就這樣，Redis 2.8 版本添加了主從復制功能。主從復制架構誕生了，master 處理實時讀寫請求，另一個叫做 slave 的節點同步 master 的數據。通過主從架構縮短不可用時間，并且還可以讓 slave 節點分擔一部分讀請求，提升應用整體性能。

有了主從復制就萬無一失了么？答案是否定的。

因為我們通過人工介入來實現主從切換的，就必須要算上人的反應時間、操作時間，所以，在這期間你的業務應用依舊會受到影響。

如何把這個過程自動化？

我們可以引入一個檢查員，讓這個檢察院實時監測 master 的健康狀態，這個觀察者就叫做哨兵。

2012 年，Redis 在 2.6 版本首次發布哨兵模式，直到 Redis 2.8 版本第二版才變成生產可用。

哨兵是 Redis 的一種運行模式，它專注于對 Redis 實例（主節點、從節點）運行狀態的監控，并能夠在主節點發生故障時通過一系列的機制實現選主及主從切換，實現故障轉移，確保整個 Redis 系統的可用性。結合 Redis 的官方文檔，可以知道 Redis 哨兵具備的能力有如下幾個：

2015 年，Redis 3.0 發布，這是一個里程碑版本，新增了 Redis 集群。

使用 Redis Cluster 集群，主要解決了大數據量存儲導致的各種慢問題，同時也便于橫向拓展。

Redis 集群是一種分布式數據庫方案，集群通過分片（sharding）來進行數據管理（「分治思想」的一種實踐）。

將數據劃分為 16384 的 slots，每個節點負責一部分槽位。槽位的信息存儲于每個節點中。是一個無中心架構，并提供復制和故障轉移功能。

2017 年，Redis 5.0 發布，該版本最大的變化，就是新增了 stream 數據類型。
2020 年，Redis 6.0 發布，該版本引入了網絡 IO 多線程，Redis 模型主要分為網絡模塊和命令處理模塊，作者認為正常情況下，redis 單線程模型中，網絡模塊往往成為瓶頸高發地；
2022 年，Redis 7.0 發布，該版本就是重構了 dict 結構，內存占用更小，內存成本會大大減少，RDB 版本不向下兼容。

責任編輯：姜華來源：碼哥跳動