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