秒殺系統設計

秒殺系統設計

會出現的問題

高併發

• 秒殺就是短時間的，瞬間用戶極多。
• Redis也就能抗住幾萬的QPS，在大量請求下：緩存雪崩、緩存擊穿、緩存穿透都是可能發生的，

超賣

• 多賣出了商品

惡意請求

• 腳本惡意請求

連接暴露

• 導致可以提前請求訪問
• 或者寫腳本壓秒訪問

數據庫

• 幾秒鐘十幾萬的QPS，直接打到數據庫上，可能導致數據庫掛掉，要是沒有降級、限流、熔斷，別的一起掛掉。

解決

服務單一職責

把秒殺單獨形成一個服務，單獨建立數據庫，萬一秒殺掛掉也不至於影響其他服務

秒殺連接加鹽

• URL動態化，可以通過MD5之類的加密算法加密隨機的字符串去做url，然後通過前端代碼獲取url後臺校驗才能通過

  public static String getKuaishouSign(String url){
          try {
              //初始化MessageDigest
              MessageDigest md5=MessageDigest.getInstance("MD5");
              //更新
              md5.update((url).getBytes("UTF-8"));
              //生成摘要
              byte[] b=md5.digest();
              int i;
              StringBuffer buf=new StringBuffer();
              for(int offeset=0;offeset<b.length;offeset++){
                  i=b[offeset];
                  if(i<0){
                      i+=256;
                  }
                  if(i<16){
                      buf.append("0");
                  }
                  buf.append(Integer.toHexString(i));
              }
              url=buf.toString();
              System.out.println(url);
          }catch (Exception e){
  
          }
          return url;
      }
  

Redis集羣

• Redis集羣
• 主從同步
• 讀寫分離
• 哨兵
• 持久化
  [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-xE0dEKDK-1582682829457)(https://raw.githubusercontent.com/iszhonghu/Picture-bed/master/img/20200119152357.png)]

Nginx

資源靜態化

​ 秒殺一般都是特定的商品還有頁面模板，現在一般都是前後端分離的，所以頁面一般都是不會經過後端的，但是前端也要自己的服務器啊，那就把能提前放入cdn服務器的東西都放進去，反正把所有能提升效率的步驟都做一下，減少真正秒殺時候服務器的壓力。

按鍵控制

• 提前置灰

限流

• 前端限流
  • 不允許持續點擊
• 後端限流
  • 直接關閉後續無效的請求

庫存預熱

• 提前將商品庫存加載到Redis中，後續在異步修改數據庫

限流、降級、熔斷、隔離

​ 限流，頂不住就擋一部分出去但是不能說不行，降級，降級了還是被打掛了，熔斷，至少不要影響別的系統，隔離，你本身就獨立的，但是你會調用其他的系統嘛，你快不行了你別拖累兄弟們啊。

削峯填谷