您好,登錄后才能下訂單哦!
【準備】
首先我們要考慮的是為什么要解決高并發,高并發瓶頸出現在哪里,有了解過的朋友肯定知道是在數據庫,因為在大量請求去操作數據庫時會出現數據的錯亂,超賣,系統崩潰,mysql死鎖等現象。
【思路】
(一)、 頁面靜態化:就是將整個頁面存儲到redis中,下次訪問時去讀取redis中的頁面值
(二)、主要對整個網站的靜態資源文件進行加速,如圖片,css,js等
(三)、數學驗證碼:用戶在計算驗證碼結果時可以減少大量請求同時進入,減少redis, mysql,服務器的壓力。
(四)、庫存標識:這是一個巨大優化,通過標識來判斷redis的庫存是否足夠,如不足就中斷去讀取redis庫存。例:boolean over = map.get(goodsId);當我們map通過key讀取到value值為true的時候,就返回錯誤提示給用戶, if(over) { return Result.error(‘庫存不足’); }.....這樣不管以后有多個請求進入都只運行兩行代碼,以下的操作無法進入。
(五)、生成動態url:主要是防止惡意用戶通過固定url進行提前秒殺商品(安全方面問題這個不可掉以輕心,你連安全措施都沒做好以下的那些操作都是白搭的)
(六)、 redis預減庫存:在用戶秒殺商品前去redis獲取當前的庫存數量,然后在秒殺時候直接減去redis存儲的庫存(大家放心這里Redis和MySQL數據是同步的,只要進入MQ隊列操作完成下單,MySQL數據庫會-1數量),從而避開去MySQL讀取庫存數據。
(七)、MQ消息隊列:它是一個中間消息鍵,通過生產者發送消息給消費者,進行業務操作,而生產者無需知道執行結果,也就是用戶點擊秒殺之后等待處理結果,之后再去輪詢查詢處理結果(異步操作),這樣就避開了不斷請求去操作數據庫。(這里的輪詢查詢也是直接從redis里面去查詢,因為秒殺成功之后會將秒殺的結果放到redis中,輪詢時候通過key去查詢)
(八)、Nginx:解決高并發的好方法,也就是我們多增加幾個tomcat服務器。當用戶訪問的時候,請求可以提交到空閑的tomcat服務器上。
(九)、數據庫集群、庫表散列
①大型網站都有復雜的應用,這些應用必須使用數據庫,那么在面對大量訪問的時候,數據庫的瓶頸很快就能顯現出來,這時一臺數據庫將很快無法滿足應用,于是我們需要使用數據庫集群或者庫表散列。
②在數據庫集群方面,很多數據庫都有自己的解決方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是類似的方案,您使用了什么樣的DB,就參考相應的解決方案來實施即可。
③上面提到的數據庫集群由于在架構、成本、擴張性方面都會受到所采用DB類型的限制,于是我們需要從應用程序的角度來考慮改善系統架構,庫表散列是常用并且最有效的解決方案。
④我們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離,不同的模塊對應不同的數據庫或者表,再按照一定的策略對某個頁面或者功能進行更小的數據庫散列,比如用戶表,按照用戶ID進行表散列,這樣就能夠低成本的提升系統的性能并且有很好的擴展性。
(十)、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量并發請求采用的高端解決辦法。
(十一)反向代理
客戶端直接訪問的服務器并不是直接提供服務的服務器,它從別的服務器獲取資源,然后將結果返回給用戶。
代理服務器和反向代理服務器:
代理服務器是代我們訪獲取資源,然后將結果返回。例如,訪問外網的代理服務器。反向代理服務器是我們正常訪問一臺服務器的時候,服務器自己調用了別的服務器。
反向代理就是說,用戶的請求請求到負載均衡的設備上,負載均衡設備再講請求分發到空閑的應用服務器上處理,處理完成之后再通過負載均衡設備返回給用戶,這樣對于用戶來說,后來的分發是不可見的。
反向代理的實現
1)需要有一個負載均衡設備來分發用戶請求,將用戶請求分發到空閑的服務器上
2)服務器返回自己的服務到負載均衡設備
3)負載均衡將服務器的服務返回用戶
代理服務器我們主動使用,是為我們服務的,不需要有自己的域名;反向代理是服務器自己使用的,我們并不知道,有自己的域名。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。