京東話費(fèi)充值業(yè)務(wù)線的訂單量‘水漲船高 ’，同時(shí)對(duì)系統(tǒng)的各項(xiàng)運(yùn)行指標(biāo)要求更高，老的系統(tǒng)架構(gòu)不足以支撐新的業(yè)務(wù)量，需要對(duì)系統(tǒng)進(jìn)行升級(jí)。升級(jí)方案從以下幾個(gè)層面進(jìn)行。

1、應(yīng)用層面

引入緩存

在應(yīng)用層和數(shù)據(jù)庫層增加緩存層，熱點(diǎn)數(shù)據(jù)放入緩存。如系統(tǒng)中常用的開關(guān)、白名單等數(shù)據(jù)，讀取頻率高寫入頻率低，針對(duì)這部分?jǐn)?shù)據(jù)就可以在JimDB(Redis)中存儲(chǔ)一份，JimDB (Redis)會(huì)把高頻數(shù)據(jù)存儲(chǔ)在內(nèi)存中，讀寫性能很高。數(shù)據(jù)寫入緩存時(shí)設(shè)置一個(gè)有效期，更新數(shù)據(jù)庫成功后，異步更新緩存數(shù)據(jù)。如果實(shí)時(shí)性要求不高，也可以等緩存失效后，主動(dòng)更新緩存。引入緩存層，降低數(shù)據(jù)庫壓力，提升系統(tǒng)響應(yīng)速度。

編寫并發(fā)處理程序

多任務(wù)并發(fā)處理，充分利用CPU資源。無依賴關(guān)系的多條任務(wù)可以并行處理，提高系統(tǒng)處理能力。如結(jié)算任務(wù)，每筆訂單之間的結(jié)算操作沒有依賴關(guān)系，可以同時(shí)執(zhí)行多條結(jié)算任務(wù)

系統(tǒng)結(jié)構(gòu)優(yōu)化

讀寫分離

實(shí)時(shí)性要求不高的數(shù)據(jù)讀取從庫，降低主庫壓力。如對(duì)賬功能，讀取的是前一天的訂單數(shù)據(jù)，這些數(shù)據(jù)就沒必要從主庫中讀取。關(guān)于技術(shù)實(shí)現(xiàn)上，Spring框架本身有提供，實(shí)現(xiàn)其抽象類AbstractRoutingDataSource即可。

變化頻率低的頁面靜態(tài)化

充值應(yīng)用中有很多卡片頁，如QQ頁卡等，頁面上的數(shù)據(jù)變化的只有廣告位。這種類型的頁面就可以靜態(tài)化，定時(shí)更新頁面，推送到存儲(chǔ)介質(zhì)上，nginx配置location，直接讀取頁面，降低后端服務(wù)的壓力。

數(shù)據(jù)庫層面

當(dāng)業(yè)務(wù)量發(fā)展到一定程度后，數(shù)據(jù)庫就會(huì)成為系統(tǒng)的瓶頸。話費(fèi)充值應(yīng)用包含企業(yè)訂單業(yè)務(wù)和普通用戶訂單業(yè)務(wù)，正是由于其業(yè)務(wù)的特殊性，采用了垂直+水平分庫方案。根據(jù)業(yè)務(wù)類型進(jìn)行垂直切分，不同業(yè)務(wù)類型訂單數(shù)據(jù)獨(dú)立存儲(chǔ)，同一種業(yè)務(wù)類型在水平上由多個(gè)庫保存。垂直+水平的分庫方案能夠最大限度的降低不同業(yè)務(wù)類型訂單數(shù)據(jù)之間的相互影響，提高數(shù)據(jù)讀寫并發(fā)量。普通用戶訂單業(yè)務(wù)，根據(jù)賬戶PIN進(jìn)行hash打散可以均勻的分布到每個(gè)庫中，sharding規(guī)則就是hash(pin)值，同時(shí)這個(gè)hash(pin)值還做為本地訂單號(hào)的前綴，這樣就可以通過賬戶PIN和本地訂單號(hào)兩個(gè)維度中任一維度都可以路由到數(shù)據(jù)庫。創(chuàng)建ERP訂單成功后，把本地訂單號(hào)和ERP訂單的映射關(guān)系保存到JmiDB中，對(duì)于只有ERP訂單號(hào)的業(yè)務(wù)流程，可以通過映射關(guān)系找到本地訂單號(hào)，有了本地訂單號(hào)也就可以路由到數(shù)據(jù)庫了。而企業(yè)訂單業(yè)務(wù)，每個(gè)企業(yè)賬戶的訂單量不均，差別能達(dá)到三個(gè)數(shù)量級(jí)，如果再根據(jù)賬戶PIN進(jìn)行hash打散分布到每個(gè)書庫中的訂單就會(huì)不均勻，不能使用這種sharding規(guī)則。根據(jù)本地訂單號(hào)進(jìn)行hash，然后再作為本地訂單號(hào)的前綴。創(chuàng)建ERP訂單成功后，同樣需要保存本地訂單號(hào)和ERP訂單號(hào)的映射關(guān)系到JmiDB中，以保證在后續(xù)的業(yè)務(wù)流程中，能夠根據(jù)ERP訂單號(hào)路由到數(shù)據(jù)庫。拆分完成后，有的業(yè)務(wù)場(chǎng)景需要聚合查詢數(shù)據(jù)，如訂單管理。如果沒有聚合數(shù)據(jù)，就需要在應(yīng)用中，開發(fā)人員自行考慮聚合。通用的聚合方案是從每個(gè)庫中查詢一頁數(shù)據(jù)，在內(nèi)存中根據(jù)條件排序，返回一頁數(shù)據(jù)，如果需要翻頁的話，邏輯更為復(fù)雜。話費(fèi)充值應(yīng)用采用了第三方存儲(chǔ)，把每個(gè)分庫中的訂單數(shù)據(jù)聚合到ElasticSearch中，查詢聚合數(shù)據(jù)的場(chǎng)景讀取ElasticSearch。模擬MySQL slave的交互協(xié)議，解析數(shù)據(jù)庫的增量BinLog，同步分庫的數(shù)據(jù)到ElasticSearch中。由于數(shù)據(jù)庫主從同步存在延遲的風(fēng)險(xiǎn)，需要準(zhǔn)備一個(gè)降級(jí)方案。在話費(fèi)充值應(yīng)用中，數(shù)據(jù)庫寫訂單成功后，插入一條任務(wù)記錄，通過任務(wù)模型立即同步數(shù)據(jù)到ElasticSearch中。保證數(shù)據(jù)同步的實(shí)時(shí)性。

總結(jié)

以上是生活随笔為你收集整理的话费充值折扣数据库_《京东话费充值系统架构演进实践》--阅读的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。