繼續(xù)答星球水友提問(wèn)：盤(pán)口數(shù)據(jù)頻繁變化，如何做緩存與推送，如何降低數(shù)據(jù)庫(kù)壓力?

并沒(méi)有做過(guò)相關(guān)的業(yè)務(wù)，結(jié)合自己的架構(gòu)經(jīng)驗(yàn)，說(shuō)說(shuō)自己的思路和想法，希望對(duì)大家有啟示。

一、業(yè)務(wù)抽象

• 有很多客戶(hù)端關(guān)注盤(pán)口，假設(shè)百萬(wàn)級(jí)別;
• 數(shù)據(jù)量不一定很大，上市交易的股票個(gè)數(shù)，假設(shè)萬(wàn)級(jí)別;
• 寫(xiě)的量比較大，每秒鐘有很多交易發(fā)生，假設(shè)每秒百級(jí)別;
• 計(jì)算比較復(fù)雜，有求和/分組/排序等操作;

二、潛在技術(shù)折衷

1. 客戶(hù)端與服務(wù)端連接如何選型?

首先，盤(pán)口客戶(hù)端與服務(wù)器建立TCP長(zhǎng)連接，而不是每次請(qǐng)求都建立與銷(xiāo)毀短連接，能極大提升性能，降低服務(wù)器壓力。

2. 業(yè)務(wù)的實(shí)時(shí)性如何滿(mǎn)足?

盤(pán)口業(yè)務(wù)，對(duì)數(shù)據(jù)實(shí)時(shí)性的要求較高，服務(wù)端可以通過(guò)TCP長(zhǎng)連接推送，保證消息的實(shí)時(shí)性。

由于推送量級(jí)巨大，可以獨(dú)立推送集群，專(zhuān)門(mén)實(shí)施推送。推送集群獨(dú)立化之后，增加推送服務(wù)器數(shù)量，就可以線(xiàn)性提升推送能力。

如上圖所示，假設(shè)有100W用戶(hù)接收實(shí)時(shí)推送：

• 搭建專(zhuān)門(mén)的推送集群，維護(hù)與客戶(hù)端的tcp長(zhǎng)連接，實(shí)時(shí)推送
• 每臺(tái)推送服務(wù)維護(hù)10W長(zhǎng)連接，10臺(tái)推送服務(wù)即可服務(wù)100W用戶(hù)
• 推送集群與業(yè)務(wù)集群之間，通過(guò)MQ解耦，推送集群只單純的推送消息，無(wú)任何業(yè)務(wù)邏輯計(jì)算，推送消息的內(nèi)容，都是業(yè)務(wù)集群計(jì)算好的

3. 推送服務(wù)最大的瓶頸是，如何將一條消息，最快的推送給與之連接的10W個(gè)客戶(hù)端?

• 如果消息量不大，例如幾秒鐘一個(gè)消息，可以開(kāi)多線(xiàn)程，例如100個(gè)線(xiàn)程，并發(fā)推送

畫(huà)外音：對(duì)應(yīng)水友提到的，如果量不大，可以成交一筆推送一筆。

• 如果消息量過(guò)大，例如一秒鐘幾百個(gè)消息，可以將消息暫存一秒，批量推送

畫(huà)外音：對(duì)應(yīng)水友提到的，如果消息量巨大，批量推送是很好的方法。

4. 數(shù)據(jù)量，寫(xiě)入量，擴(kuò)展性如何滿(mǎn)足?

股票個(gè)數(shù)較少，數(shù)據(jù)量不是瓶頸。

流水?dāng)?shù)據(jù)寫(xiě)入量，每秒百級(jí)別，甚至千級(jí)別，數(shù)據(jù)庫(kù)寫(xiě)性能也不是瓶頸，理論上一個(gè)庫(kù)可以抗住。

假如每秒寫(xiě)入量達(dá)到萬(wàn)級(jí)別，可以在數(shù)據(jù)庫(kù)層面實(shí)施水平切分，將不同股票的流水拆到不同水平切分的庫(kù)里去，就能線(xiàn)性增加數(shù)據(jù)庫(kù)的寫(xiě)入量。

畫(huà)外音：水平拆分后，同一個(gè)股票，數(shù)據(jù)在同一個(gè)庫(kù)里，不同股票，可能在不同的庫(kù)里，理論上不會(huì)有跨庫(kù)查詢(xún)的需求。

如果每秒寫(xiě)入量達(dá)到十萬(wàn)，百萬(wàn)級(jí)別，還可以加入MQ緩沖請(qǐng)求，削峰填谷，保護(hù)數(shù)據(jù)庫(kù)。

如論如何，根據(jù)本業(yè)務(wù)的數(shù)據(jù)量與寫(xiě)入量，單庫(kù)應(yīng)該是沒(méi)有問(wèn)題的。

5. 復(fù)雜的業(yè)務(wù)邏輯操作，如何滿(mǎn)足?

本業(yè)務(wù)的寫(xiě)入量不大，但讀取量很大，肯定不能每個(gè)讀取請(qǐng)求都sum/group by/order by，這樣數(shù)據(jù)庫(kù)肯定扛不住。

水友已經(jīng)想到了，可以用緩存來(lái)降低數(shù)據(jù)庫(kù)的壓力，但擔(dān)心“隨著時(shí)間的推移，這個(gè)偏差勢(shì)必會(huì)慢慢放大”。

關(guān)于緩存的一致性的放大，可以這么搞：

• 做一個(gè)異步的線(xiàn)程，每秒鐘訪(fǎng)問(wèn)一次數(shù)據(jù)庫(kù)，將復(fù)雜的業(yè)務(wù)邏輯計(jì)算出來(lái)，放入高可用緩存
• 所有的讀請(qǐng)求不再耦合業(yè)務(wù)邏輯計(jì)算，都直接從高可用緩存讀結(jié)果

如此一來(lái)，復(fù)雜業(yè)務(wù)邏輯的計(jì)算，每秒鐘只會(huì)有一次。

帶來(lái)的問(wèn)題是，一秒內(nèi)可能有很多流水寫(xiě)入數(shù)據(jù)庫(kù)，但不會(huì)實(shí)時(shí)的反應(yīng)到緩存里，用戶(hù)最差情況下，會(huì)讀到一秒前的盤(pán)口數(shù)據(jù)。

無(wú)論如何，這是一個(gè)性能與一致性的設(shè)計(jì)折衷。

上面的所有方案，都是基于在線(xiàn)客戶(hù)量級(jí)巨大，推送消息巨大的前提下，采用推送方案。很多時(shí)候，工程師都會(huì)妄加猜測(cè)，把問(wèn)題想得很復(fù)雜，把方案搞得很復(fù)雜。

如果在線(xiàn)用戶(hù)量很小，用戶(hù)能夠接受的盤(pán)口時(shí)延較長(zhǎng)(例如5s)，完全可以采用輪詢(xún)拉取方案：

• 取消整個(gè)推送集群與MQ集群;
• 盤(pán)口數(shù)據(jù)，異步線(xiàn)程每1s寫(xiě)入高可用緩存一次;
• 客戶(hù)端每5s輪詢(xún)拉取最新的盤(pán)口數(shù)據(jù)，都只從緩存中拉取;

搞定!

反正，肯定不能每個(gè)讀請(qǐng)求都sum/group by/order by掃庫(kù)計(jì)算，這個(gè)是最需要優(yōu)化的。

三、總結(jié)

• 長(zhǎng)連接比短連接性能好很多倍
• 推送量巨大時(shí)，推送集群需要與業(yè)務(wù)集群解耦
• 推送量巨大時(shí)，并發(fā)推送與批量推送是一個(gè)常見(jiàn)的優(yōu)化手段
• 寫(xiě)入量巨大時(shí)，水平切分能夠擴(kuò)容，MQ緩沖可以保護(hù)數(shù)據(jù)庫(kù)
• 業(yè)務(wù)復(fù)雜，讀取量巨大時(shí)，加入緩存，定時(shí)計(jì)算，能夠極大降低數(shù)據(jù)庫(kù)壓力

思路比結(jié)論重要，希望大家有收獲。

【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文