redis秒殺系統的實現

1.如何設計一個秒殺系統

在設計任何系統之前，我們首先都需要先理解秒殺系統的業務背景

下面我簡單的舉一個例子：

在某個時間點，某某電商網站要低價賣某件商品，而且限量1千件，搶購人數超過數十萬人。
所以我們面臨的第一個秒殺的問題就是：時間極短，然後瞬間流量非常大
我們的系統必須保證秒殺搶購的結果不出錯，達到搶購的預期目的。
而且秒殺庫存的實現也需要保障秒殺結果的準確性。
總結幾個特點就是：

• 高效能：秒殺中有大量的並行讀寫，所以需要使系統能支撐起高並行存取，這是一個關鍵點。
• 高可用：藐視瞬間流量非常大，很有可能會導致系統宕機，所以需要從各方面保證系統的可用性。
• 一致性：由於秒殺請求量非常大，此時就需要我們的秒殺結果要準確。因為一旦出錯，那麼波及面會非常廣，損失非常大。

2.秒殺流程

我們先從秒殺的入口開始說起
在秒殺入口的地方會有這些問題需要解決：

2.1 前端處理

靜態資源處理

秒殺商品一般都會包含很多靜態資源，所以這些圖片什麼的靜態資源一定要放到CDN（Content Delivery Network，即內容分發網路），能放的儘量放進去。讓秒殺時後端伺服器的壓力盡可能小。
說到此處，我重點描述講解CDN

為了能在傳統IP網上釋出豐富的寬頻媒體內容，提出在現有網際網路基礎上建立一個內容分發平臺專門為網站提供服務。由於CDN是為加快網路存取速度而被優化的網路覆蓋層，因此被形象地稱為“網路加速器”。
首先要說的是應用伺服器和資源伺服器應該解耦，也就是應用伺服器只處理邏輯，而資源伺服器存放內容或者叫資源。

• CDN專注於「內容」，也就是CDN的C所代表的Content，專注於靜態資源的分發和存取，比如一張圖片，一個文字檔案，一個視訊，一個CSS，一個JS等等，任何以檔案形式儲存的，為了提高在網際網路上的存取速度和質量，都可以將這個資源部署在CDN這個網路上。
• CDN動作是「分發」，也就是如何讓剛才提到的那些「內容」快速的部署在這個網路中，從而快速為使用者服務，其實還有一層更重要的含義是使用者的快速存取與就近接入，分發的目的是為了使用者更好的體驗。
• CDN落定於「網路」，是部署於全國或者全世界的一大堆伺服器，這些伺服器基於當前網際網路的基礎架構在其上層再構成一個網路，這個網路專為資源分發而生。

那CDN的原理是什麼呢？為什麼使用者可以接入離他最近的伺服器呢？
主要是利用了DNS來判斷使用者位置，再返回給使用者最近的機房的伺服器的資源地址。
下面我再通俗的解釋一下：
肯德基的總部在美國，可是你家樓下也有一家肯德基，並且漢堡包是一模一樣的，這就是CDN（這個比喻來自知乎，覺得非常的恰當）。肯德基部署了很多個CDN在世界各地提供服務，使用者都是找到最近的店，這個計算過程就是剛才講的「就近接入」。

什麼是CDN的排程呢？

（1）DNS排程是最常用和最通用的排程方案，缺點是存在DNS劫持的風險，排程的精確度也會差一些；
（2）302排程非常適合用在大檔案下載和視訊點播這兩個應用場景，優點是可以提高排程的精確度，缺點是將會增加首包的時延（在大檔案下載和視訊點播場景下對首包時延不太敏感，而對排程精確度要求更高）
（3）HTTPDNS排程的優點是有較高的安全性（可以規避DNS劫持風險）和排程精確度，但是有個很大的缺點，需要使用者端提供支援（例如在手機APP上嵌入SDK），通用性較差。

通俗來講：

在一個商圈有兩家肯德基，有一家組織活動，雞腿隨便吃，所以顧客全部湧到這家店，已經水洩不通，另一家店則門可羅雀。這個時候CDN的排程功能就要發揮作用了，另一家店也釋出了一個訊息說，買一個漢堡，打五折。這個時候，在第一家店搶不上雞腿的顧客，馬上跑去了第二家店，這個時候兩個店的流量處於均衡狀態。這就是CDN的排程。

惡意存取行為的處理

當我們推出秒殺活動後，還需要考慮黃牛黨們開發出的各種秒殺器，可以自動填單，自動回答各種問題，以及自動模擬點選等，令我們防不勝防。
針對這些我們可以通過各種工作來限制和識別這些惡意存取。

• 例如限制IP的提交次數
• 提高各種動態驗證碼及問題的難度
• 增加黑名單賬戶

秒殺連結隱藏

如果稍微懂點程式的人可以提前拿到秒殺連結，那麼就可以通過程式在最快的時間發起秒殺請求，這樣人家就可以拿到大部分商品了。為了防止這一點，可以使秒殺連結動態化。使用MD5演演算法等加密隨機字串作為URL的一部分，秒殺開始後才將連線放出來，同時在後臺進行校驗，此時已經可以防止一大批的羊毛黨了。

前端限流

可以在秒殺按鈕點選之後灰掉幾秒鐘，幾秒鐘之內只能點選一次。
可以使用Nginx使用者請求到Nginx的時候將流量分散到多個伺服器上，而且也可以針對使用者進行一些過濾，將一些請求攔截，保證後端的穩定性。比如1萬個商品，最多放進來10萬個請求就可以了，其他的使用者就只能等著靜態頁面嘍。同時也可以在秒殺預約的時候隨機發放一些token，只有擁有這些token的客戶才有可能搶購成功。
同時在分散式的架構下，我們也可以通過gateway，redis+lua或者nginx進行限流

2.2 後端處理

後端限流

如果服務的流量到達最大值的時候，新的請求就不能再進來了。
而服務宕機的時候也需要引導請求到備用伺服器上面，然後返回一些靜態提示頁面等。
隔離就要求，秒殺的服務單獨部署，只承擔其秒殺的單一職責，即使出問題，也不會影響其他的服務。

削峰

秒殺流量在某一個時間點非常高，那麼我們讓瞬間進來的流量進到一個緩衝池，然後再進行平緩處理。比較多用到的方案就是使用訊息佇列來處理。

庫存預熱

由於秒殺的商品的數量一般都是提前已知的，這時我們可以提前將商品的一些資料提前載入到快取中。並且可以將商品分割區來進行秒殺，根據每個大區的使用者數量以及活躍程度，為每個大區分配單獨的秒殺商品數量。這樣也可以分散伺服器壓力。

使用快取

高並行的情況下必然會遇到快取雪崩，快取擊穿，快取穿透等問題。而且秒殺的場景是讀多寫少，使用Redis作為快取非常合適，為了避免單臺Redis伺服器出問題，導致快取擊穿等問題，升級使用Redis叢集是一個比較好的方案。提升可用性的效能也可以大大提高。
下面我簡單說一下快取雪崩，快取擊穿以及快取穿透

首先我們要先了解一下快取的處理流程
前臺請求，後臺先從快取中取資料，取到直接返回結果，取不到時從資料庫中取，資料庫取到更新快取，並返回結果，資料庫也沒取到，那直接返回空結果。

知道什麼是快取之後我們重點來了解一下這三個名次具體指什麼，以及如何去解決
快取穿透
描述：快取穿透是指快取和資料庫中都沒有的資料，而使用者不斷髮起請求，如發起為id為“-1”的資料或id為特別大不存在的資料。這時的使用者很可能是攻擊者，攻擊會導致資料庫壓力過大。
解決方案：

• 介面層增加校驗，如使用者鑑權校驗，id做基礎校驗，id<=0的直接攔截；
• 從快取取不到的資料，在資料庫中也沒有取到，這時也可以將key-value對寫為key-null，快取有效時間可以設定短點，如30秒（設定太長會導致正常情況也沒法使用）。這樣可以防止攻擊使用者反覆用同一個id暴力攻擊

快取擊穿
描述： 快取擊穿是指快取中沒有資料但資料庫中有的資料（一般是快取時間到期），這時由於並行使用者特別多，同時讀快取沒讀到資料，又同時去資料庫去取資料，引起資料庫壓力瞬間增大，造成過大壓力。
解決方案：

• 設定熱點資料永遠不過期。
• 加互斥鎖，互斥鎖參考程式碼如下

我簡單解釋一下程式碼思路：
我們首先從快取中獲取資料，如果資料不存在，我們則去獲取鎖，這把鎖 只需要能夠互斥，可重入即可，最簡單的就是redis的setnx來實現，獲取鎖資源以後，從資料庫讀取資料，同時將資料更新至快取，然後釋放鎖；如果獲取鎖資源失敗，我們就讓其隔一段時間之後重新嘗試去獲取鎖資源。

快取雪崩
快取雪崩是指快取中資料大批次到過期時間，而查詢資料量巨大，引起資料庫壓力過大甚至down機。
和快取擊穿不同的是，快取擊穿指並行查同一條資料，快取雪崩是不同資料都過期了，很多資料都查不到從而查資料庫。
解決方案：

• 快取資料的過期時間設定隨機，防止同一時間大量資料過期現象發生。
• 如果快取資料庫是分散式部署，將熱點資料均勻分佈在不同搞得快取資料庫中。
• 設定熱點資料永遠不過期。

3.超賣問題

秒殺中一個重要的點就是超賣問題，由於搶購人數多，流量也很大，但是也不能賣多了。
目前常見的解決方案就是：

1.資料庫要加唯一索引，減庫存的時候要先進行庫存數量判斷等，資料庫鎖，加版本號的樂觀鎖方式等等。2

.採用Redis來維護庫存，由於秒殺活動可以預先知道商品的數量，所以可以提前將商品的資料載入到Redis中，如果Redis的庫存不足的話則秒殺失敗。

3.生成訂單的時候將請求放到伺服器端的非同步佇列中去處理，可以使用Redis的佇列，或者MQ均可。

4.總體思路

其實秒殺方案的總體思路也很簡單：

1.儘可能的將請求攔截在上游；

2.後端均要處理限流；

3.儘量減少請求到資料庫；

4.多利用快取；

5.使用非同步操作-可以使用佇列等；

6.秒殺服務單一職責；

7.儘早失敗，讓秒殺請求返回

到此這篇關於redis秒殺系統的實現的文章就介紹到這了,更多相關redis 秒殺系統內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！