網(wǎng)站制作的關(guān)鍵技術(shù)優(yōu)化點

大流量讀系統(tǒng)的設(shè)計手段，當這些手段全部窮盡以后，仍然產(chǎn)生大流量又該如何處理呢?所以秒殺系統(tǒng)還要解決以下關(guān)鍵問題。
1.Java處理大并發(fā)動態(tài)請求優(yōu)化的問題
Java和通用的Web服務(wù)器( Nginx或 Apache)相比，在處理大并發(fā)的HTP請求時要弱一點，所以一般我們都會對大流量的Web系統(tǒng)做靜態(tài)化改造，讓大部分請求和數(shù)據(jù)直接在 Nginx I服務(wù)器或者Web代理服務(wù)器( Varnish、 squid等)上直接返回(可以減少數(shù)據(jù)的序列化與反序列化)，Java層只處理少量數(shù)據(jù)的動態(tài)請求。針對這些請求可以使用以下優(yōu)化手段:

直接使用 Servlet處理請求。避免使用傳統(tǒng)的MVC框架，這樣可以繞過一大堆復雜且用處不大的處理邏輯，節(jié)省1毫秒的時間一取決于對MVC框架的依賴程度；
直接輸出流數(shù)據(jù)。使用 resp. getoutputstreamo而不是 resp. get Writer)可以省掉一些不變字符數(shù)據(jù)的編碼，提升性能；數(shù)據(jù)輸出時，推薦使用JSON而不是模板引擎(一般都是解釋執(zhí)行)來輸出頁面。
2.同一商品被大并發(fā)讀的問題
也許有讀者會覺得這個問題很容易解決，無非就是將熱點數(shù)據(jù)放到Tair緩存里。集中式Tair緩存為了保證命中率一般都會采用一致性Hash，所以同一個key會落到同臺機器上。雖然單臺Tair緩存機器也能支撐1秒30萬次的請求，但還是遠不足以應付大秒級別的熱點商品，該如何徹底解決單點的瓶頸呢?答案是采用應用層的Localcache，即在秒殺系統(tǒng)的單機上緩存商品相關(guān)的數(shù)據(jù)。那么如何 Cache數(shù)據(jù)?答案是劃分成動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)分別處理。
像商品的標題和描述這此機器上、并一直緩存到秒殺結(jié)束像庫存這類動態(tài)數(shù)據(jù)會采用被動失效的方式緩存一定時間(一般是數(shù)秒)，失效后再去Tai緩存拉取最新的數(shù)據(jù)。
讀者可能還會有疑問，像庫存這種頻繁更新的數(shù)據(jù)一旦數(shù)據(jù)不一致會不會導致超賣?這就要用到前面介紹的讀數(shù)據(jù)的分層校驗原則了，讀的場景可以允許一定的臟數(shù)據(jù)，因為這里的誤判只會導致少量原本無庫存的下單請求被誤認為有庫存，可以等到真正寫數(shù)據(jù)時再保證最終的一致性，通過在數(shù)據(jù)的高可用性和一致性之間的平衡來解決高并發(fā)的數(shù)據(jù)讀取問題。
3.同一數(shù)據(jù)大并發(fā)更新問題
采用 Localcache和數(shù)據(jù)的分層校驗可以一定程度上解決大并發(fā)讀問題，但是無論如何還是避免不了減庫存這類的大并發(fā)寫問題，這也是秒殺場景中最核心的技術(shù)難題。
同一數(shù)據(jù)在數(shù)據(jù)庫里肯定是一行存儲( MYSQL)，所以會有大量的線程來競爭INNODB行鎖，并發(fā)度越高時等待的線程也會越多，TPS會下降而RT會上升，數(shù)據(jù)庫的吞吐量會嚴重受到影響。這里會出現(xiàn)一個問題，即單個熱點商品會影響整個數(shù)據(jù)庫的性能，出現(xiàn)我們不愿意看到的0.01%商品影響9999的商品的情況。此處的解決思路也是要遵循前面介紹的第一個原則“隔離” 把熱點商品放到單獨的熱點庫中盡管這會帶來維護的麻煩(要做熱點數(shù)據(jù)的動態(tài)遷移以及單獨的數(shù)據(jù)庫等)把熱點商品分離到單獨的數(shù)據(jù)庫并沒有解決并發(fā)鎖的問題，要解決并發(fā)鎖問題有以下兩種辦法。
第一種是在應用層做排隊。按照商品維度設(shè)置隊列順序執(zhí)行，這樣能減少同一臺機器對數(shù)據(jù)庫同一行記錄操作的并發(fā)度，也能控制單個商品占用數(shù)據(jù)庫連接的數(shù)量防止熱點商品占用太多的數(shù)據(jù)庫連接。
第二種是在數(shù)據(jù)庫層做排隊。應用層只能做到單機的排隊，但是應用層機器數(shù)量很多，用這種排隊方式控制并發(fā)仍然是很有限的，如果能在數(shù)據(jù)庫層做全局排隊是最理想的。數(shù)據(jù)庫團隊開發(fā)了 MYSQL的 INNODB層上的 patch，可以做到在數(shù)據(jù)庫層上對單行記錄并發(fā)排隊。
你可能會有疑問:排隊和鎖競爭不都是要等得嗎，有何區(qū)別?如果熟悉 MYSQL的話，應該知道 INNODB內(nèi)部的死鎖檢測以及 MYSQL Server和 INNODB的切換會比較耗性能， MYSQL核心團隊還做了很多其他方面的網(wǎng)站制作優(yōu)化，如 COMMIT_ON_ SUCCESS和 ROLLBACK ON FAIL的 patch，配合在SQL里面加hint，在事務(wù)里不需要等待應用層提交 COMMIT而在數(shù)據(jù)執(zhí)行完最后一條SQL后，根據(jù) TARGET AFFECT ROW結(jié)果就直接提交或回滾，這樣可以減少網(wǎng)絡(luò)的等待時間(平均約0.7毫秒)。

網(wǎng)頁題目：網(wǎng)站制作的關(guān)鍵技術(shù)優(yōu)化點
分享URL：http://www.muchs.cn/news24/146974.html

網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián)，是專注品牌與效果的網(wǎng)站制作，網(wǎng)絡(luò)營銷seo公司；服務(wù)項目有網(wǎng)站制作等

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)