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