大流量讀系統的設計伎倆，當這些伎倆全部窮盡以后，仍然產生大流量又該如何處置呢？所以秒殺系統還要處置以下關鍵問題。
1.Java處置大并發起態央求優化的問題
Java和通用的Web效勞器（ Nginx或 Apache）相比，在處置大并發的HTP央求時要弱一點，所以普通我們都會對大流量的Web系統做靜態化改造，讓大部分央求和數據直接在 Nginx I效勞器或者Web代理效勞器（ Varnish、 squid等）上直接返回（可以減少數據的序列化與反序列化），Java層只處置少量數據的動態央求。針對這些央求可以運用以下優化伎倆：
直接運用 Servlet處置央求。避免運用傳統的MVC框架，這樣可以繞過一大堆復雜且用處不大的處置邏輯，儉省1毫秒的時間一取決于對MVC框架的依賴程度；
直接輸出流數據。運用 resp. getoutputstreamo而不是 resp. get Writer）可以省掉一些不變字符數據的編碼，提升性能；數據輸出時，舉薦運用JSON而不是模板引擎（普通都是解釋執行）來輸出頁面。
2.同一商品被大并發讀的問題
或許會覺得這個問題很容易處置，無非就是將熱點數據放到Tair緩存里。集中式Tair緩存為了保證命中率普通都會采用分歧性Hash，所以同一個key會落到同臺機器上。固然單臺Tair緩存機器也能支撐1秒30萬次的央求，但還是遠缺乏以對付大秒級別的熱點商品，該如何徹底處置單點的瓶頸呢？答案是采用應用層的Localcache，即在秒殺系統的單機上緩存商品相關的數據。那么如何 Cache數據？答案是劃分紅動態數據和靜態數據分別處置。
像商品的標題和描畫這此機器上、并不時緩存到秒殺終了像庫存這類動態數據會采用被動失效的方式緩存一定時間（普通是數秒），失效后再去Tai緩存拉取最新的數據。
可能還會有疑問，像庫存這種頻繁更新的數據一旦數據不分歧會不會招致超賣？這就要用到前面引見的讀數據的分層校驗準繩了，讀的場景可以允許一定的臟數據，由于這里的誤判只會招致少量原本無庫存的下單央求被誤以為有庫存，可以等到真正寫數據時再保證最終的分歧性，經過在數據的高可用性和分歧性之間的平衡來處置高并發的數據讀取問題。
3.同一數據大并發更新問題
采用 Localcache和數據的分層校驗可以一定程度上處置大并發讀問題，但是無論如何還是避免不了減庫存這類的大并發寫問題，這也是秒殺場景中最中心的技術難題。
同一數據在數據庫里肯定是一行存儲（ MYSQL），所以會有大量的線程來競爭INNODB行鎖，并發度越高時等候的線程也會越多，TPS會降落而RT會上升，數據庫的吞吐量會嚴重遭到影響。這里會呈現一個問題，即單個熱點商品會影響整個數據庫的性能，呈現我們不愿意看到的0.01%商品影響9999的商品的情況。此處的處置思緒也是要遵照前面引見的第一個準繩“隔離” 把熱點商品放到單獨的熱點庫中固然這會帶來維護的省事（要做熱點數據的動態遷移以及單獨的數據庫等）把熱點商品分別到單獨的數據庫并沒有處置并發鎖的問題，要處置并發鎖問題有以下兩種辦法。
第一種是在應用層做排隊。按照商品維度設置隊列次第執行，這樣能減少同一臺機器對數據庫同一行記載操作的并發度，也能控制單個商品占用數據庫銜接的數量防止熱點商品占用太多的數據庫銜接。
第二種是在數據庫層做排隊。應用層只能做到單機的排隊，但是應用層機器數量很多，用這種排隊方式控制并發仍然是很有限的，假設能在數據庫層做全局排隊是最理想的。數據庫團隊開發了 MYSQL的 INNODB層上的 patch，可以做到在數據庫層上對單行記載并發排隊。
你可能會有疑問：排隊和鎖競爭不都是要等得嗎，有何區別？假設熟習 MYSQL的話，應該知道 INNODB內部的死鎖檢測以及 MYSQL Server和 INNODB的切換會比較耗性能， MYSQL中心團隊還做了很多其他方面的網站制造優化，如 COMMIT_ON_ SUCCESS和 ROLLBACK ON FAIL的 patch，配合在SQL里面加hint，在事務里不需求等候應用層提交 COMMIT而在數據執行完最后一條SQL后，根據 TARGET AFFECT ROW結果就直接提交或回滾，這樣可以減少網絡的等候時間。
更多精彩請關注：http://www.jukabz.cn
更多精彩請關注：http://www.jukabz.cn
