瞬時高併發（秒殺/活動）Redis方案

時間 2019-11-11

標籤瞬時併發秒殺活動 redis 方案欄目快樂工作简体版

原文原文鏈接

1、Redisredis

豐富的數據結構（Data Structures）算法

字符串（String）數據庫

Redis字符串能包含任意類型的數據後端

一個字符串類型的值最多能存儲512M字節的內容服務器

利用INCR命令簇（INCR, DECR, INCRBY）來把字符串看成原子計數器使用網絡

使用APPEND命令在字符串後添加內容數據結構

列表（List）併發

Redis列表是簡單的字符串列表，按照插入順序排序dom

你能夠添加一個元素到列表的頭部（左邊：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