Java解決高併發秒殺

一：問題

首先咱們要考慮的是爲何要解決高併發，高併發瓶頸出如今哪裏，有了解過的朋友確定知道是在數據庫，由於在大量請求去操做數據庫時會出現數據的錯亂，超賣，系統崩潰，mysql死鎖等現象。

二：思路

• 1. 頁面靜態化：就是將整個頁面存儲到redis中，下次訪問時去讀取redis中的頁面值

• 2. cdn：主要對整個網站的靜態資源文件進行加速，如圖片，css，js等(去阿里看教程)

• 3.數學驗證碼：用戶在計算驗證碼結果時能夠減小大量請求同時進入，減小redis, mysql，服務器的壓力。

• 4：庫存標識：這是一個巨大優化，經過標識來判斷redis的庫存是否足夠，如不足就中斷去讀取redis庫存。例：boolean over = map.get(goodsId);當咱們map經過key讀取到value值爲true的時候，就返回錯誤提示給用戶， if(over) { return Result.error(‘庫存不足’); }.....這樣無論之後有多個請求進入都只運行兩行代碼，如下的操做沒法進入。

• 5.生成動態url：主要是防止惡意用戶經過固定url進行提早秒殺商品（安全方面問題這個不可掉以輕心，你連安全措施都沒作好如下的那些操做都是白搭的）

• 6. redis預減庫存：在用戶秒殺商品前去redis獲取當前的庫存數量，而後在秒殺時候直接減去redis存儲的庫存（你們放心這裏Redis和MySQL數據是同步的，只要進入MQ隊列操做完成下單，MySQL數據庫會-1數量），從而避開去MySQL讀取庫存數據。

• 7. MQ消息隊列：它是一箇中間消息鍵，經過生產者發送消息給消費者，進行業務操做，而生產者無需知道執行結果，也就是用戶點擊秒殺以後等待處理結果，以後再去輪詢查詢處理結果（異步操做），這樣就避開了不斷請求去操做數據庫。（這裏的輪詢查詢也是直接從redis裏面去查詢，由於秒殺成功以後會將秒殺的結果放到redis中，輪詢時候經過key去查詢）

• 8. Nginx：解決高併發的好方法，也就是咱們多增長几個tomcat服務器。當用戶訪問的時候，請求能夠提交到空閒的tomcat服務器上。

• 9.數據庫集羣、庫表散列

  ①大型網站都有複雜的應用，這些應用必須使用數據庫，那麼在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快沒法知足應用，因而咱們須要使用數據庫集羣或者庫表散列。

  ②在數據庫集羣方面，不少數據庫都有本身的解決方案，Oracle、Sybase等都有很好的方案，經常使用的MySQL提供的Master/Slave也是相似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施便可。

  ③上面提到的數據庫集羣因爲在架構、成本、擴張性方面都會受到所採用DB類型的限制，因而咱們須要從應用程序的角度來考慮改善系統架構，庫表散列是經常使用而且最有效的解決方案。

  ④咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高系統的性能而且有很好的擴展性。

• 10.負載均衡

負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的高端解決辦法。

• 11.反向代理

客戶端直接訪問的服務器並非直接提供服務的服務器，它從別的服務器獲取資源，而後將結果返回給用戶。

代理服務器和反向代理服務器：

代理服務器是代咱們訪獲取資源，而後將結果返回。例如，訪問外網的代理服務器。反向代理服務器是咱們正常訪問一臺服務器的時候，服務器本身調用了別的服務器。

反向代理就是說，用戶的請求請求到負載均衡的設備上，負載均衡設備再講請求分發到空閒的應用服務器上處理，處理完成以後再經過負載均衡設備返回給用戶，這樣對於用戶來講，後來的分發是不可見的。

反向代理的實現

1）須要有一個負載均衡設備來分發用戶請求，將用戶請求分發到空閒的服務器上

2）服務器返回本身的服務到負載均衡設備

3）負載均衡將服務器的服務返回用戶

代理服務器咱們主動使用，是爲咱們服務的，不須要有本身的域名；反向代理是服務器本身使用的，咱們並不知道，有本身的域名。

感謝閱讀至文末，彩蛋奉上

Java學習、面試；文檔、視頻資源免費獲取

部分資料截圖以下