【總結】瞬時高并發（秒殺/活動）Redis方案 - goody9807－IT工程師數位筆記本

文章出處

1，Redis

豐富的數據結構（Data Structures）
- 字符串（String）
- - Redis字符串能包含任意類型的數據
  - 一個字符串類型的值最多能存儲512M字節的內容
  - 利用INCR命令簇（INCR, DECR, INCRBY）來把字符串當作原子計數器使用
  - 使用APPEND命令在字符串后添加內容
- 列表（List）
- - Redis列表是簡單的字符串列表，按照插入順序排序
  - 你可以添加一個元素到列表的頭部（左邊：LPUSH）或者尾部（右邊：RPUSH）
  - 一個列表最多可以包含232-1個元素（4294967295，每個表超過40億個元素）
  - 在社交網絡中建立一個時間線模型，使用LPUSH去添加新的元素到用戶時間線中，使用LRANGE去檢索一些最近插入的條目
  - 你可以同時使用LPUSH和LTRIM去創建一個永遠不會超過指定元素數目的列表并同時記住最后的N個元素
  - 列表可以用來當作消息傳遞的基元（primitive），例如，眾所周知的用來創建后臺任務的Resque Ruby庫
- 集合（Set）
- - Redis集合是一個無序的，不允許相同成員存在的字符串合集（Uniq操作，獲取某段時間所有數據排重值）
  - 支持一些服務端的命令從現有的集合出發去進行集合運算，如合并（并集：union）,求交(交集：intersection)，差集, 找出不同元素的操作（共同好友、二度好友）
  - 用集合跟蹤一個獨特的事。想要知道所有訪問某個博客文章的獨立IP？只要每次都用SADD來處理一個頁面訪問。那么你可以肯定重復的IP是不會插入的（利用唯一性，可以統計訪問網站的所有獨立IP）
  - Redis集合能很好的表示關系。你可以創建一個tagging系統，然后用集合來代表單個tag。接下來你可以用SADD命令把所有擁有tag的對象的所有ID添加進集合，這樣來表示這個特定的tag。如果你想要同時有3個不同tag的所有對象的所有ID，那么你需要使用SINTER
  - 使用SPOP或者SRANDMEMBER命令隨機地獲取元素
- 哈希（Hashes）
- - Redis Hashes是字符串字段和字符串值之間的映射
  - 盡管Hashes主要用來表示對象，但它們也能夠存儲許多元素
- 有序集合（Sorted Sets）
- - Redis有序集合和Redis集合類似，是不包含相同字符串的合集
  - 每個有序集合的成員都關聯著一個評分，這個評分用于把有序集合中的成員按最低分到最高分排列（排行榜應用，取TOP N操作）
  - 使用有序集合，你可以非常快地（O(log(N))）完成添加，刪除和更新元素的操作
  - 元素是在插入時就排好序的，所以很快地通過評分(score)或者位次(position)獲得一個范圍的元素（需要精準設定過期時間的應用）
  - 輕易地訪問任何你需要的東西: 有序的元素，快速的存在性測試，快速訪問集合中間元素
  - 在一個巨型在線游戲中建立一個排行榜，每當有新的記錄產生時，使用ZADD 來更新它。你可以用ZRANGE輕松地獲取排名靠前的用戶，你也可以提供一個用戶名，然后用ZRANK獲取他在排行榜中的名次。同時使用ZRANK和ZRANGE你可以獲得與指定用戶有相同分數的用戶名單。所有這些操作都非常迅速
  - 有序集合通常用來索引存儲在Redis中的數據。例如：如果你有很多的hash來表示用戶，那么你可以使用一個有序集合，這個集合的年齡字段用來當作評分，用戶ID當作值。用ZRANGEBYSCORE可以簡單快速地檢索到給定年齡段的所有用戶
復制（Replication, Redis復制很簡單易用，它通過配置允許slave Redis Servers或者Master Servers的復制品）
- 一個Master可以有多個Slaves
- Slaves能通過接口其他slave的鏈接，除了可以接受同一個master下面slaves的鏈接以外，還可以接受同一個結構圖中的其他slaves的鏈接
- redis復制是在master段是非阻塞的，這就意味著master在同一個或多個slave端執行同步的時候還可以接受查詢
- 復制在slave端也是非阻塞的，假設你在redis.conf中配置redis這個功能，當slave在執行的新的同步時，它仍可以用舊的數據信息來提供查詢，否則，你可以配置當redis slaves去master失去聯系是，slave會給發送一個客戶端錯誤
- 為了有多個slaves可以做只讀查詢，復制可以重復2次，甚至多次，具有可擴展性（例如：slaves對話與重復的排序操作，有多份數據冗余就相對簡單了）
- 他可以利用復制去避免在master端保存數據，只要對master端redis.conf進行配置，就可以避免保存（所有的保存操作），然后通過slave的鏈接，來實時的保存在slave端
LRU過期處理（Eviction）
- EVAL 和 EVALSHA 命令是從 Redis 2.6.0 版本開始的，使用內置的 Lua 解釋器，可以對 Lua 腳本進行求值
- Redis 使用單個 Lua 解釋器去運行所有腳本，并且， Redis 也保證腳本會以原子性(atomic)的方式執行： 當某個腳本正在運行的時候，不會有其他腳本或 Redis 命令被執行。這和使用MULTI / EXEC 包圍的事務很類似。在其他別的客戶端看來，腳本的效果(effect)要么是不可見的(not visible)，要么就是已完成的(already completed)
- LRU過期處理（Eviction）
- - Redis允許為每一個key設置不同的過期時間，當它們到期時將自動從服務器上刪除（EXPIRE）
事務
- MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務的基礎
- 事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷
- 事務中的命令要么全部被執行，要么全部都不執行，EXEC 命令負責觸發并執行事務中的所有命令
- Redis 的 Transactions 提供的并不是嚴格的 ACID 的事務
- Transactions 還是提供了基本的命令打包執行的功能：可以保證一連串的命令是順序在一起執行的，中間有會有其它客戶端命令插進來執行
- Redis 還提供了一個 Watch 功能，你可以對一個 key 進行 Watch，然后再執行 Transactions，在這過程中，如果這個 Watched 的值進行了修改，那么這個 Transactions 會發現并拒絕執行
數據持久化
- RDB
- - 特點
  - - RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲
  - 優點
  - - RDB是一個非常緊湊的文件,它保存了某個時間點得數據集,非常適用于數據集的備份
    - RDB是一個緊湊的單一文件, 非常適用于災難恢復
    - RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程,接下來的工作全部由子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能
    - 與AOF相比,在恢復大的數據集的時候，RDB方式會更快一些
  - 缺點
  - - 如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的數據最少的話，那么RDB不適合，Redis要完整的保存整個數據集是一個比較繁重的工作
    - RDB 需要經常fork子進程來保存數據集到硬盤上,當數據集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果數據集巨大并且CPU性能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日志文件的頻率來提高數據集的耐久度
- AOF
- - 特點
  - - AOF持久化方式記錄每次對服務器寫的操作
    - redis重啟的時候會優先載入AOF文件來恢復原始的數據,因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整
  - 優點
  - - 使用AOF 會讓你的Redis更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync
    - AOF文件是一個只進行追加的日志文件,所以不需要寫入seek
    - Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫
    - AOF 文件有序地保存了對數據庫執行的所有寫入操作，這些寫入操作以 Redis 協議的格式保存，因此 AOF 文件的內容非常容易被人讀懂，對文件進行分析（parse）也很輕松。 導出（export） AOF 文件也非常簡單
  - 缺點
  - - 對于相同的數據集來說，AOF 文件的體積通常要大于 RDB 文件的體積
    - 根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB
- 選擇
- - 同時使用兩種持久化功能
分布式
- Redis Cluster （Redis 3版本）
- Keepalived
- - 當Master掛了后，VIP漂移到Slave；Slave 上keepalived 通知redis 執行：slaveof no one ,開始提供業務
  - 當Master起來后，VIP 地址不變，Master的keepalived 通知redis 執行slaveof slave IP host，開始作為從同步數據
  - 依次類推
- Twemproxy
- - 快、輕量級、減少后端Cache Server連接數、易配置、支持ketama、modula、random、常用hash 分片算法
  - 對于客戶端而言，redis集群是透明的，客戶端簡單，遍于動態擴容
  - Proxy為單點、處理一致性hash時，集群節點可用性檢測不存在腦裂問題
  - 高性能，CPU密集型，而redis節點集群多CPU資源冗余，可部署在redis節點集群上，不需要額外設備
高可用（HA）
- Redis Sentinel（redis自帶的集群管理工具）
- - 監控（Monitoring）： Redis Sentinel實時監控主服務器和從服務器運行狀態
  - 提醒（Notification）：當被監控的某個 Redis 服務器出現問題時， Redis Sentinel 可以向系統管理員發送通知，也可以通過 API 向其他程序發送通知
  - 自動故障轉移（Automatic failover）：當一個主服務器不能正常工作時，Redis Sentinel 可以將一個從服務器升級為主服務器，并對其他從服務器進行配置，讓它們使用新的主服務器。當應用程序連接到 Redis 服務器時， Redis Sentinel會告之新的主服務器地址和端口
- 單M-S結構
- - 單M-S結構特點是在Master服務器中配置Master Redis（Redis-1M）和Master Sentinel（Sentinel-1M）
  - Slave服務器中配置Slave Redis（Redis-1S）和Slave Sentinel（Sentinel-1S）
  - 其中 Master Redis可以提供讀寫服務，但是Slave Redis只能提供只讀服務。因此，在業務壓力比較大的情況下，可以選擇將只讀業務放在Slave Redis中進行
- 雙M-S結構
- - 雙M-S結構的特點是在每臺服務器上配置一個Master Redis，同時部署一個Slave Redis。由兩個Redis Sentinel同時對4個Redis進行監控。兩個Master Redis可以同時對應用程序提供讀寫服務，即便其中一個服務器出現故障，另一個服務器也可以同時運行兩個Master Redis提供讀寫服務
  - 缺點是兩個Master redis之間無法實現數據共享，不適合存在大量用戶數據關聯的應用使用
- 單M-S結構和雙M-S結構比較
- - 單M-S結構適用于不同用戶數據存在關聯，但應用可以實現讀寫分離的業務模式。Master主要提供寫操作，Slave主要提供讀操作，充分利用硬件資源
  - 雙（多）M-S結構適用于用戶間不存在或者存在較少的數據關聯的業務模式，讀寫效率是單M-S的兩（多）倍，但要求故障時單臺服務器能夠承擔兩個Mater Redis的資源需求
發布/訂閱（Pub/Sub）
監控：Redis-Monitor
- 歷史redis運行查詢：CPU、內存、命中率、請求量、主從切換等
- 實時監控曲線

2，數據類型Redis使用場景

String
- 計數器應用
List
- 取最新N個數據的操作
- 消息隊列
- 刪除與過濾
- 實時分析正在發生的情況，用于數據統計與防止垃圾郵件（結合Set）
Set
- Uniqe操作，獲取某段時間所有數據排重值
- 實時系統，反垃圾系統
- 共同好友、二度好友
- 利用唯一性，可以統計訪問網站的所有獨立 IP
- 好友推薦的時候，根據 tag 求交集，大于某個 threshold 就可以推薦
Hashes
- 存儲、讀取、修改用戶屬性
Sorted Set
- 排行榜應用，取TOP N操作
- 需要精準設定過期時間的應用（時間戳作為Score）
- 帶有權重的元素，比如一個游戲的用戶得分排行榜
- 過期項目處理，按照時間排序