風(fēng)險(xiǎn)評(píng)估
生產(chǎn)前壓力測(cè)試
使用JMeter做初期庫(kù)存數(shù)秒殺，看看Redis以及訂單接口是否異?；蛘叱瑫r(shí)，預(yù)估本次活動(dòng)的訪問(wèn)流量，做上線上的驗(yàn)證。
生產(chǎn)可降級(jí)熔斷
當(dāng)瞬間秒殺產(chǎn)品庫(kù)存太大，造成的Redis寫(xiě)暴增，可能造成線程阻塞最后寫(xiě)超時(shí)對(duì)于如上的異常，添加一個(gè)秒殺開(kāi)關(guān)，大量異常時(shí)開(kāi)關(guān)關(guān)閉停止一切秒殺活動(dòng)，以免造成更大的損失。
由于訂單還沒(méi)有做sharding，當(dāng)每秒寫(xiě)超過(guò)單機(jī)承受能力甚至影響正常的非秒殺產(chǎn)品下單該怎么辦？對(duì)于如上的異常添加一個(gè)秒殺開(kāi)關(guān)，如果超時(shí)或者異常切換到訂單臨時(shí)表中，啟用定時(shí)任務(wù)將訂單從臨時(shí)表數(shù)據(jù)取出來(lái)然后調(diào)用下單接口更新到訂單庫(kù)。
監(jiān)控
監(jiān)控Redis調(diào)用性能，這邊主要是看讀和寫(xiě)的性能兩個(gè)指標(biāo)，看接口日志是否超時(shí)或者異常，查看公司埋點(diǎn)框架mertic統(tǒng)計(jì)是否有拐點(diǎn)，因?yàn)閮?nèi)存消耗很少通過(guò)Zabbix查看Redis集群CPU信息。
監(jiān)控下單接口性能，看是否超時(shí)或者異常，統(tǒng)計(jì)booking庫(kù)中失敗或者未到order庫(kù)的訂單數(shù)，定時(shí)預(yù)警超過(guò)閥值自動(dòng)發(fā)郵件通知相關(guān)人員。
觀察訂單master數(shù)據(jù)庫(kù)的性能，目前master機(jī)器是32核128g內(nèi)存，通過(guò)Zabbix查看其CPU內(nèi)存以及IO使用情況，查看slave機(jī)器的延遲分發(fā)情況，因?yàn)橛唵涡畔@示都是從slave機(jī)器讀取的。
鑒于目前數(shù)據(jù)庫(kù)還不支持sharding，對(duì)于大量的insert只能通過(guò)增加CPU、內(nèi)存和SSD來(lái)彌補(bǔ)，不利于橫向擴(kuò)展且代價(jià)也比較昂貴，后期還是應(yīng)該完善訂單庫(kù)sharding，降低單點(diǎn)單庫(kù)的數(shù)據(jù)更新壓力，是個(gè)長(zhǎng)遠(yuǎn)的策略?？傊竽憞L試小心驗(yàn)證，多備預(yù)案服務(wù)做到可切換可降級(jí)，減少系統(tǒng)間耦合盡量將風(fēng)險(xiǎn)降到最低。
推薦一個(gè)架構(gòu)類的會(huì)議
當(dāng)業(yè)務(wù)量爆發(fā)增長(zhǎng)時(shí)，高可用架構(gòu)是永恒的話題。出行、電商、社交網(wǎng)絡(luò)、房產(chǎn)，每個(gè)看似不同領(lǐng)域的技術(shù)架構(gòu)都承受著相同的高并發(fā)沖擊。滴滴、京東、Facebook以及鏈家，四個(gè)不同的行業(yè)巨頭將在這里分享他們自己在對(duì)高可用架構(gòu)的見(jiàn)解。