本文原鏈接：https://blog.csdn.net/weixin_38035852/article/details/81384733
Sanno限時秒殺搶票系統
亮點：在高並發情況下的秒殺優化，我們知道當並發數達到一定量的時候，會對數據庫服務器帶來很大的壓力，那么如何緩解這些壓力以及提高並發的QPS就是整個項目的重點。（不斷的提高QPS）。
亮點3個：
1.利用緩存減少數據庫的壓力，以及讀取緩存的速度遠遠快於數據庫（網絡時延+IO）
2.頁面靜態化技術加快用戶訪問速度，提高QPS，異步下單增強用戶體驗，以及內存標記減少Redis的訪問。
3.安全性優化：雙重md5密碼校驗，秒殺接口地址的隱藏，接口限流防刷，數學公式驗證碼。
整個的提升了系統的安全性能，
在高並發量的前提下，一台服務器都是無法承擔如此大的並發訪問的。我們知道淘寶雙11QPS能達到上千萬，所以一台服務器的訪問量最少都需要上萬，所以需要集群服務器才能實現一項高並發業務。
緩解數據庫壓力：
1.本項目大量的利用了緩存技術,包括用戶信息緩存（分布式session），商品信息的緩存，商品庫存緩存，訂單的緩存，減少了對數據庫服務器的訪問。
用戶信息緩存引出：分布式session.
2.分布式session
我們知道當服務器集群的時候，若用戶第一個請求在第一台服務器上，第二個請求在其他服務器上，會出現session的丟失的情況，丟失用戶信息。而且在這種高並發場景下，一定是很多服務器同步工作，所以如何解決session分布式的問題是一個重點。
本項目采用：利用redis緩存的方法，另外布置一個Redis服務器專門用於存放用戶的session信息。這樣就不會出現用戶session丟失的情況。（每次需要session，從緩存中取即可）
這種方式的優點：相對其他的分布式方式，
1.服務器文件同步（不建議使用，這樣會造成文件重復，資源浪費）
2.session存數據庫（不建議用，會加大數據庫壓力）
3.使用cookie（不建議用，cookie不太安全）
對於集群中機器數多、網絡環境復雜的情況有很好的處理效果。
大量的緩存引用也出現了一個問題，如何識別不同模塊中的緩存（key值重復，如何辨別是不同模塊的key）。 引出：通用緩存key封裝
3.通用緩存key封裝
利用一個抽象類，定義BaseKey（前綴）,定義了緩存的String prefix(前綴) 以及緩存的過期時間。讓不同模塊繼承它。
這樣每次存入一個模塊的緩存的時候，加上這個緩存特定的前綴，以及可以統一制定不同的過期時間。
4.頁面靜態化以及前后端分離
頁面靜態化的主要目的是為了加快頁面的加載速度。做法：將訂票的詳情頁面做成靜態HTML，放在CDN（減少了服務端的壓力）上做為靜態數據發送給用戶端，而數據信息通過前端ajax 異步發送請求來獲取。只獲取動態數據信息部分，加載速度可以達到全部渲染的2倍。
難點：
1.大量的使用了緩存，那么就存在緩存的過期時間控制以及緩存擊穿以及緩存雪崩等問題？
解決：首先針對不同的緩存設置不同的過期時間，比如session緩存，在userKey這個前綴中，設置是30分鍾過期，並且加入一層再登陸增加緩存時間的機制。這樣每次取session,都會延長30分鍾，相對來說，就減少了緩存過期的幾率。
針對熱點數據，比如演唱會票這種票詳情信息，熱點商品由於考慮到是一般搶票10分鍾內幾乎搶完，於是就設置為10分鍾的緩存。
針對熱點數據的緩存擊穿問題，萬一一波一波的搶票，（火車票）這種，某個時間點萬一大量並發，剛好我的這個票緩存時間過了，去訪問數據庫。對於這種熱點數據，我將過期時間一起存入緩存中，取出來的時候，比對一下過期時間和當前時間，少於1分鍾，我就更新一下緩存，防止他過期。
2.大量的使用緩存，對於緩存服務器，也有很大的壓力，有時候Redis 壓力比mysql還要大很多，思考如何減少Redis的訪問？
一般搶票，票的數量也少，大概1000張左右，但是並發量可能在幾萬。
在Redis預減庫存的時候，內存中維護一個isOvermap作為一個標記，當沒有庫存的時候，將其置為true。每次搶票業務 訪問Redis之前，查一下map,true說明沒有庫存，就直接返回No_stock。
3.高並發的時候，業務來不及同步處理，Redis壓力，數據庫有時候會有大量的insert 和update 操作,甚至請求堆積過多的時候，to many connections？
想到了消息隊列，用來異步處理請求。每次請求過來，先不去處理請求，而是放入消息隊列，然后在后台布置一個監聽器，分別監聽不同業務的消息隊列，有消息來的時候，在進行秒殺搶票操作。這樣防止多個請求同時操作的時候，數據庫連接過多的異常。
4.為了在前端就限制同一時間的高並發，我也想到了一些前端就限制掉一些用戶的做法。
數學公式驗證碼