-
CDN：Content Delivery Network，即內容分發網絡。放置一些靜態化資源，或者可以將動態數據分離，比如秒殺詳情頁，做成HTML放在cdn上，動態數據可以通過ajax請求后臺獲取。一些js依賴直接用公網的CDN，自己開發的一些頁面也做靜態化處理推送到CDN。用戶在CDN獲取到的數據不需要再訪問我們的服務器，動靜態分離可以降低服務器請求量。
WebServer一般不直接對外訪問，之前都會放置Nginx，Nginx是一個集群化的，部署在多個服務器上，用來做我們的Http服務器，響應客戶請求。同時他還會為后端的Tomcat，Jetty這些servlet容器來做反向代理，以達到負載均衡的效果。
Redis：做服務器端的緩存，利用Redis提供的API來達到熱點數據的快速存取的過程。加速后臺獲取數據，減少數據庫的請求量。
MySQL：借助MySQL的事務來達到秒殺的數據的一致性和完整性。
查看全部 -
11111
查看全部 -
Mark 調試代碼
查看全部 -
更新庫存的是熱點操作，會出現行級鎖，而插入購買記錄的行為沒有行級鎖?？梢韵炔迦胭徺I明細，可以避免因重復秒殺帶來的不必要的更新庫存操作，減少不必要的行級鎖的占用。然后再去更新庫存。代碼中，根據熱點商品競爭的結果，來決定下一步是rollback還是commit，降低了網絡延遲和GC影響一半的時間
插入操作放在前面，插入操作就是把秒殺單，用戶id，電話組成一個組件，這個組件沖突的概率并不是很高，因為秒殺單在前頭，還有用戶的電話，組成一個唯一鍵，這個時候的網絡延遲和GC是可以并行的，這個時候再去拿update減庫存的rowLocl行級鎖
rowLock:? 行級鎖，鎖的粒度最小，并發度最高，加鎖慢
最終目的：降低MySQL roollock的持有時間
查看全部 -
回顧事務執行
秒殺操作通過mysql的事務來完成。
查看全部 -
詳情頁：做靜態化放到CDN中，各個公司CDN不同，不細講
系統時間部分：new了一個對象，很簡單很快，不用優化
地址暴露接口（高并發點）: 不方便做成靜態放到CDN中，需要放到服務器端，通過邏輯去控制；但是該接口調用頻繁，不希望放到數據庫中-->使用redis優化.
執行秒殺操作：高并發點
查看全部 -
優化：
前端： 動靜態數據做分離，減少請求與響應時間；按鈕防重復，防止用戶發送無效的重復請求，因為秒殺活動一般都會有購買數量的限制，敲的次數再多，最后還是要查看是否已購。影響了效率，可有前端代為處理并優化
后端：使用CDN換存重要的靜態資源等；在后端對活動結束時間、商品選購時間、業務的相關邏輯要求都放在后端代碼中，并調用緩存來進行暫存，已減少對DB的直接操作，提高效率
????1,前端控制觸發次數，比如限制控制按鈕的觸發
????2,使用CDN和緩存機制達到動靜分離
????3,減少行級鎖和GC的時間，將食物控制在mysql中進行，比如存儲過程
查看全部 -
方法一：成本高，大公司使用
方法二：放到服務器端完成，MySQL執行sql效率非常高
查看全部 -
99999
查看全部 -
異地機房延遲分析
實際在20ms左右
查看全部 -
同城機房延遲分析
查看全部 -
優化方向是：
查看全部 -
不是MySQL慢，也不是Java慢。而是Java和數據庫通訊之間會有網絡延遲/GC，這些時間也要加在事務的執行周期里面。而同一行的事務是串性化的。
第一個用戶執行一次商品購買時，對DB的update減庫存操作不是執行完就結束，后續還涉及到GC內存滿了，等待自動回收過程中的網絡響應的延遲問題；
除此之外，用戶的每一次購買操作都是一個具體的事務，其中還涉及到了用戶個人的購買明細，可理解為淘寶的已購買這一項，而這又是一個insert 的操作，執行完后又或許可能再一次出現GC進行內存的清理而導致延遲，直到反應過來后，繼續執行后續的事務提交commit或者失敗后的回滾rollback
而這時另一個用戶的update 操作已經開始很久了超過了 4W分之一秒的理想時間，所以，實際秒殺項目中，需要對每一個用戶的update時間，即行級鎖的時間進行優化，因為，下一個用戶還在等待，他后面或許還有一個它也在等待....哈士奇瞪著眼等著呢
查看全部 -
串行化操作
查看全部 -
壓力測試下，一條update 可以 達到 4W 的 QPS ，等同于一件商品能在一秒內被銷售掉 4W 件，這應該是理想值吧！
那么，對于實際執行中的低效是什么原因？這才是并發中要優化的重點吧！
查看全部
舉報