專案的亮點和難點

亮點：在高併發情況下的秒殺優化，我們知道當併發數達到一定量的時候，會對資料庫伺服器帶來很大的壓力，那麼如何緩解這些壓力以及提高併發的qps就是整個專案的重點。（不斷的提高qps）。

亮點3個：

整個的提公升了系統的安全效能，

在高併發量的前提下，一台伺服器都是無法承擔如此大的併發訪問的。我們知道**雙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.為了在前端就限制同一時間的高併發，我也想到了一些前端就限制掉一些使用者的做法。

數學公式驗證碼