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

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

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

Redis：做服務(wù)器端的緩存，利用Redis提供的API來(lái)達(dá)到熱點(diǎn)數(shù)據(jù)的快速存取的過(guò)程。加速后臺(tái)獲取數(shù)據(jù)，減少數(shù)據(jù)庫(kù)的請(qǐng)求量。

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

11111

Mark 調(diào)試代碼

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

插入操作放在前面，插入操作就是把秒殺單，用戶id，電話組成一個(gè)組件，這個(gè)組件沖突的概率并不是很高，因?yàn)槊霘卧谇邦^，還有用戶的電話，組成一個(gè)唯一鍵，這個(gè)時(shí)候的網(wǎng)絡(luò)延遲和GC是可以并行的，這個(gè)時(shí)候再去拿update減庫(kù)存的rowLocl行級(jí)鎖

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

最終目的：降低MySQL roollock的持有時(shí)間

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

秒殺操作通過(guò)mysql的事務(wù)來(lái)完成。

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

系統(tǒng)時(shí)間部分：new了一個(gè)對(duì)象，很簡(jiǎn)單很快，不用優(yōu)化

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

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

優(yōu)化：

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

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

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

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

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

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

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

99999

異地機(jī)房延遲分析

實(shí)際在20ms左右

同城機(jī)房延遲分析

優(yōu)化方向是：

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

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

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

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

串行化操作

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

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