隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)架構(gòu)的不斷演變， 技術(shù)架構(gòu)的滯后， 帶來(lái)的是嚴(yán)重的系統(tǒng)瓶頸與漏洞， 前段時(shí)間大半個(gè)月都在優(yōu)化數(shù)據(jù)處理， 由于歷史數(shù)據(jù)過(guò)大，多至6千萬(wàn)數(shù)據(jù)，mysql數(shù)據(jù)庫(kù)負(fù)載過(guò)高， 壓力過(guò)大， ?系統(tǒng)又在不斷運(yùn)行， 需要做到不停服務(wù)不影響支付功能的前提下短時(shí)間內(nèi)實(shí)現(xiàn)數(shù)據(jù)優(yōu)化， 前期想到的是分表處理， 但無(wú)論是垂直拆分還是水平拆分都將影響服務(wù)的運(yùn)行， 最終與幾位老程序員商量 在分布式dubbo框架的基礎(chǔ)上增加 solr 搜索引擎 + mq異步隊(duì)列 + 數(shù)據(jù)庫(kù)異步備份數(shù)據(jù)來(lái)達(dá)到支付網(wǎng)關(guān)的高可用， 上線了幾十天，效果還是杠杠的

由于solr搜索引擎是寫到磁盤中的， 通過(guò)建立索引， 它的查詢效率極高， 提高了接口的訪問(wèn)速度，減少了請(qǐng)求時(shí)間， 為以后的支付重構(gòu)奠定了基礎(chǔ)

之前一直擔(dān)心上線后會(huì)頻發(fā)故障，上線的時(shí)候也沒有停服務(wù)， ?事實(shí)證明擔(dān)心是多余的，開始拆分表， 將數(shù)據(jù)拆分出去，最終遷移了6千多萬(wàn)的數(shù)據(jù)

支付 + 訂單 + 賬務(wù) 密不可分

如何避免重復(fù)支付， 如何解決支付的冪等性問(wèn)題？

如何解決不同支付渠道金額換算問(wèn)題？

如何實(shí)現(xiàn)不同支付渠道自由切換， 配置支付路由?

技術(shù)與業(yè)務(wù)密不可分，?實(shí)踐證明這些都是可以通過(guò)有效的方案解決的!?

更多支付相關(guān)知識(shí)，可以參考： 支付之家?