問題：

現(xiàn)在直播平臺很火，有一個這樣的場景：幾萬個粉絲向網(wǎng)紅撒錢，粉絲點擊按鈕，錢不斷減少，網(wǎng)紅錢不斷增加。如何設(shè)計這一塊呢？如果直接存庫，可能會把庫干趴下。

?

討論：

A：這個涉及到第三方交易，不可能是加減法那么簡單

B：錢的加減請求丟到MQ里面緩存，然后一千個加減紀(jì)錄作為一筆，累計網(wǎng)紅和粉絲的錢數(shù)加減，然后更新一次數(shù)據(jù)庫，這樣一千個粉絲撒錢只需要更新一次庫，減少對庫的IO，至于單條賬單紀(jì)錄可以寫日志慢慢解析入庫，因為紀(jì)錄要求的實時性不高。

B：然后性能上堆機(jī)器，加幾個節(jié)點差不多了

A：意思是批處理代替單處理，減少調(diào)用遠(yuǎn)端接口的次數(shù)

A：批量處理固然效率高，但是并不靈活，應(yīng)該還要加上時效性。如果10個小時都達(dá)不到一千次，難道還要等到10個小時之后才發(fā)起一次連接遠(yuǎn)端接口。

A：人家交易早就取消了

B：這個場景不是面對面交易，粉絲撒錢都是以禮物的形式送的，而不是每一次請求都要完成一次銀行賬戶的交易，所以后臺只需要統(tǒng)計，這樣批處理是很快的。

A：這類交易不適合用批量處理，萬一中間有一筆有異常就很麻煩。

B：每一筆都會紀(jì)錄日志，而且統(tǒng)計只是為了給實時用戶提供熱點數(shù)據(jù)，網(wǎng)紅要知道誰給自己撒了錢，這里的過程不會直接涉及到銀行交易，不會因為某一筆異常導(dǎo)致回滾這樣的操作，一般不會出問題，只是單純地禮物累加

A：關(guān)鍵是看人家遠(yuǎn)端接口是否支持批量交易啊

B：沒有批量交易，這里的批量只是批量統(tǒng)計，然后交易可以從日志中解析，然后一條一條完成，首先把實時數(shù)據(jù)提供出去。

A：我覺得瓶頸應(yīng)該是能否保證并發(fā)調(diào)用遠(yuǎn)端接口的效率，寫回本地日志完全可以異步慢慢寫，至于實時顯示給用戶的可以不用實時統(tǒng)計，用一個變量做加減就好了。

A：加減比較簡單，但要考慮并發(fā)安全，這個變量最終肯定要固話到庫里，或者保存和庫里的一致

A：如果是調(diào)用第三方的交易平臺，沒有回滾之說法吧，交易不在本地

A：除了要考慮并發(fā)量，還要考慮的應(yīng)該是要及時把信息顯示給用戶，肯定不能等把交易成功的響應(yīng)數(shù)據(jù)都寫到庫里了再統(tǒng)計出來顯示，那樣太慢了，所以我覺得應(yīng)該盡量避免頻繁讀數(shù)據(jù)庫，實時數(shù)據(jù)可以都在內(nèi)存里，后面再同步固化到庫里

B：所以你們說了那么多 不就是在論證我的方案嗎。。 考慮并發(fā)所以才會用mq做緩存 并且足夠可靠 還有 直播這個場景你們確定了解嗎 一般是先在賬戶里充值了之后 ?撒錢只扣賬戶里的錢 或者支付成功之后才會發(fā)起一次撒錢的請求 并不是在你發(fā)起請求之后 在我說的統(tǒng)計批處理上做交易類的業(yè)務(wù) ?做的批量統(tǒng)計就是為了及時返回給用戶他們要看到的數(shù)據(jù) 寫到日志里也是為了押后處理

A：充值的話用的就是虛擬貨幣了，不能算實時交易，本人不搞電商，有搞電商的大俠出來給大家分享一下高并發(fā)交易吧

A：不涉及第三方的交易，就相對簡單得多，交易都只是在本地做加減而已，所有用戶充進(jìn)來的錢都已經(jīng)到商家口袋里了，用戶手上的都只是一堆數(shù)字，只有提現(xiàn)才涉及真正的貨幣交易

A：那些什么資金管理系統(tǒng)，其實真正的銀行賬戶就只有管理者手上的一兩個，其它上百萬上千萬客戶的賬號都只是一個個虛擬賬號，如果允許客戶內(nèi)部交易，那根本不需要經(jīng)過銀行，僅僅是內(nèi)部虛擬賬號的金額加減，再怎么轉(zhuǎn)來轉(zhuǎn)去，只要錢不出銀行賬戶就都還在管理者手上

?

我只是覺得這個思路很好，問題探討才能完美，如果侵犯當(dāng)事人的權(quán)益，可以私我刪除。謝謝！

總結(jié)

以上是生活随笔為你收集整理的直播平台虚拟币与人民币的关系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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