第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

CDN：Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。放置一些靜態(tài)化資源，或者可以將動態(tài)數(shù)據(jù)分離，比如秒殺詳情頁，做成HTML放在cdn上，動態(tài)數(shù)據(jù)可以通過ajax請求后臺獲取。一些js依賴直接用公網(wǎng)的CDN，自己開發(fā)的一些頁面也做靜態(tài)化處理推送到CDN。用戶在CDN獲取到的數(shù)據(jù)不需要再訪問我們的服務(wù)器，動靜態(tài)分離可以降低服務(wù)器請求量。

WebServer一般不直接對外訪問，之前都會放置Nginx，Nginx是一個集群化的，部署在多個服務(wù)器上，用來做我們的Http服務(wù)器，響應(yīng)客戶請求。同時他還會為后端的Tomcat，Jetty這些servlet容器來做反向代理，以達(dá)到負(fù)載均衡的效果。

Redis：做服務(wù)器端的緩存，利用Redis提供的API來達(dá)到熱點數(shù)據(jù)的快速存取的過程。加速后臺獲取數(shù)據(jù)，減少數(shù)據(jù)庫的請求量。

MySQL：借助MySQL的事務(wù)來達(dá)到秒殺的數(shù)據(jù)的一致性和完整性。

11111

Mark 調(diào)試代碼

更新庫存的是熱點操作，會出現(xiàn)行級鎖，而插入購買記錄的行為沒有行級鎖。可以先插入購買明細(xì)，可以避免因重復(fù)秒殺帶來的不必要的更新庫存操作，減少不必要的行級鎖的占用。然后再去更新庫存。代碼中，根據(jù)熱點商品競爭的結(jié)果，來決定下一步是rollback還是commit，降低了網(wǎng)絡(luò)延遲和GC影響一半的時間

插入操作放在前面，插入操作就是把秒殺單，用戶id，電話組成一個組件，這個組件沖突的概率并不是很高，因為秒殺單在前頭，還有用戶的電話，組成一個唯一鍵，這個時候的網(wǎng)絡(luò)延遲和GC是可以并行的，這個時候再去拿update減庫存的rowLocl行級鎖

rowLock:? 行級鎖，鎖的粒度最小，并發(fā)度最高，加鎖慢

最終目的：降低MySQL roollock的持有時間

回顧事務(wù)執(zhí)行

秒殺操作通過mysql的事務(wù)來完成。

詳情頁：做靜態(tài)化放到CDN中，各個公司CDN不同，不細(xì)講

系統(tǒng)時間部分：new了一個對象，很簡單很快，不用優(yōu)化

地址暴露接口（高并發(fā)點）: 不方便做成靜態(tài)放到CDN中，需要放到服務(wù)器端，通過邏輯去控制；但是該接口調(diào)用頻繁，不希望放到數(shù)據(jù)庫中-->使用redis優(yōu)化.

執(zhí)行秒殺操作：高并發(fā)點

優(yōu)化：

前端： 動靜態(tài)數(shù)據(jù)做分離，減少請求與響應(yīng)時間；按鈕防重復(fù)，防止用戶發(fā)送無效的重復(fù)請求，因為秒殺活動一般都會有購買數(shù)量的限制，敲的次數(shù)再多，最后還是要查看是否已購。影響了效率，可有前端代為處理并優(yōu)化

后端：使用CDN換存重要的靜態(tài)資源等；在后端對活動結(jié)束時間、商品選購時間、業(yè)務(wù)的相關(guān)邏輯要求都放在后端代碼中，并調(diào)用緩存來進(jìn)行暫存，已減少對DB的直接操作，提高效率

????1,前端控制觸發(fā)次數(shù)，比如限制控制按鈕的觸發(fā)

????2,使用CDN和緩存機制達(dá)到動靜分離

????3,減少行級鎖和GC的時間，將食物控制在mysql中進(jìn)行，比如存儲過程

方法一：成本高，大公司使用

方法二：放到服務(wù)器端完成，MySQL執(zhí)行sql效率非常高

99999

異地機房延遲分析

實際在20ms左右

同城機房延遲分析

優(yōu)化方向是：

不是MySQL慢，也不是Java慢。而是Java和數(shù)據(jù)庫通訊之間會有網(wǎng)絡(luò)延遲/GC，這些時間也要加在事務(wù)的執(zhí)行周期里面。而同一行的事務(wù)是串性化的。

第一個用戶執(zhí)行一次商品購買時，對DB的update減庫存操作不是執(zhí)行完就結(jié)束，后續(xù)還涉及到GC內(nèi)存滿了，等待自動回收過程中的網(wǎng)絡(luò)響應(yīng)的延遲問題；

除此之外，用戶的每一次購買操作都是一個具體的事務(wù)，其中還涉及到了用戶個人的購買明細(xì)，可理解為淘寶的已購買這一項，而這又是一個insert 的操作，執(zhí)行完后又或許可能再一次出現(xiàn)GC進(jìn)行內(nèi)存的清理而導(dǎo)致延遲，直到反應(yīng)過來后，繼續(xù)執(zhí)行后續(xù)的事務(wù)提交commit或者失敗后的回滾rollback

而這時另一個用戶的update 操作已經(jīng)開始很久了超過了 4W分之一秒的理想時間，所以，實際秒殺項目中，需要對每一個用戶的update時間，即行級鎖的時間進(jìn)行優(yōu)化，因為，下一個用戶還在等待，他后面或許還有一個它也在等待....哈士奇瞪著眼等著呢

串行化操作

壓力測試下，一條update 可以 達(dá)到 4W 的 QPS ，等同于一件商品能在一秒內(nèi)被銷售掉 4W 件，這應(yīng)該是理想值吧！

那么，對于實際執(zhí)行中的低效是什么原因？這才是并發(fā)中要優(yōu)化的重點吧！