秒殺系統分析以及難題解決

前言 ~

        咱們知道如今的京東、淘寶、以及相似購物的一些項目，他們都會按期或者不按期的舉行秒殺活動，以次來提升消費者的購買力，可是咱們知道秒殺這個功能怎麼實現的嘛？實現過程會遇到什麼難題嘛？如今跟隨小編的腳步，讓咱們一塊兒邁進秒殺系統的實現分析。

1、秒殺系統業務流程

        這一流程雖然看似簡單，可是裏面仍是存在着問題的，由於咱們知道秒殺活動不是隻有一我的在對該商品進行操做，而是上萬、上十萬以上的消費者在對一類商品進行操做，這樣就會產生高併發的問題，而且假若有10萬個消費者在對一類商品進行秒殺購買，那麼請求接口的次數就不止是10萬那麼少了，多是50萬，也可能更高，由於全部人在參與點擊秒殺時候，都會嘗試屢次點擊，期待增長成功的機會。

        解決這一問題，咱們能夠在前端進行按鈕頻繁點擊操做的限制，防止重複提交，減小90%的重複請求。就是讓用戶點擊一次後，就不讓他點擊了。如圖相似：

 

        就算對前端頁面按鈕操做進行了控制，那麼也會有很大的接口請求量涌入，此時若是如此巨大的接口請求量一定會對服務器產生巨大的損害。

       解決這一問題，就要考慮到負載均衡了，負載均衡簡單來講就是將多個請求平均分發給多臺服務器，由這些服務器共同處理用戶請求，到達減緩服務器負載的效果。負載均衡有硬件和軟件的解決方案，硬件可使用lvs、F五、Radware等，軟件可使用nginx，能夠實現多個tomcat的負載均衡。除了此方式，還可使用限制流量、分散流量等操做。

 

      修改庫表，主要是修改該商品做爲秒殺商品提供總的商品數量，可是畢竟是秒殺活動，因此該商品的數量是固定的，而如此大用戶量的秒殺，可能會形成商品數據呈現負數的狀況。

       解決這一問題，可使用分佈式鎖，分佈式鎖是一種悲觀鎖的形式，有些狀況下也可使用樂觀鎖。能夠給sql一個條件，當商品數量減一的結果大於或者等於0的時候，纔給予修改商品數量，若是小於0，則不給予修改。

     例如該SQL：update tb_miaosha set goods_num=goods_num-1 where goods_code='' and goods_num>=0.

 

       將用戶信息和商品信息添加到秒殺表，這裏又會出現一個問題，可能會產生，同一類商品，均由同一個用戶購買，那麼一塊兒來參加秒殺的小夥伴們可能不樂意啦，一塊兒來秒殺商品的，憑什麼都由你一我的購買了。

      解決這一問題，而前臺咱們可使用nginx進行ip限制，後臺代碼就要使用到redis-------key-value型的非關係型數據庫了，對用戶進行限制，好比限制該用戶20秒以內，只能秒殺一次，從而解決這一問題，若是redis中沒有這個key，那麼就設置，而且設置過時時間，若是redis中存在這個key，那麼就不進行設置。組合命令 set key valye EX time NX

EX：設置過時時間

time：過時時間

NX：判斷redis數據庫中是否有這個key

   後臺代碼：jedis.set("要設置的key","該key的值","NX","EX",10);

        若是使用了redis進行用戶的限制，但仍是會出現數據庫還承受不了過濾以後的請求量，這時候，應該怎麼辦勒？這時候確定會有小夥伴提出弄個數據庫集羣呀，這種方法是好，可是有沒有不用花錢買服務器弄數據庫集羣就能夠實現的呢？辦法仍是有的。

       解決方法，可使用令牌機制, 咱們知道商品數量是有限的，能秒殺成功的請求較少，咱們能夠預先（異步）初始化一個和商品數量相同的令牌池放入到內存中，當用戶發來請求，就去令牌池中取令牌，令牌數量有限，先到先得，拿到令牌的能夠請求操做數據庫，從而減緩數據庫的壓力。

        當用戶登錄的時候，讓客戶端攜帶token，發送請求到服務器端，驗證成功後讓用戶登陸成功，當用戶進入到秒殺頁面，用戶點擊秒殺按鈕的時候，讓客戶端也攜帶token，而且在服務器端設置一個令牌池，令牌池數量爲秒殺商品數量，當用戶每點擊秒殺按鈕，就去令牌池中去令牌，先到先得，直到令牌池數量爲空。

 

 

很是感謝騰訊課堂的Tony老師視頻教材！！！！