序言

在并發(fā)場景中，當(dāng)熱點緩存Key失效時，流量瞬間打到數(shù)據(jù)庫中，此所謂緩存擊穿現(xiàn)象；當(dāng)大范圍的緩存Key失效時，流量也會打到數(shù)據(jù)庫中，此所謂緩存雪崩現(xiàn)象。

當(dāng)使用分布式行鎖時，能夠有效解決緩存擊穿問題；當(dāng)使用分布式表鎖時，能夠解決緩存雪崩問題。實際操作中，分布式表鎖不在考慮范圍，理由是降低并發(fā)量。

本文將從另一個角度出發(fā)，將請求流量合并和拆分，以提高系統(tǒng)的并發(fā)量。

理論基礎(chǔ)

流量的合并與拆分原理是將多條請求合并成一條請求，執(zhí)行后再將結(jié)果拆分。在數(shù)據(jù)庫與緩存架構(gòu)中，緩存Key失效的瞬間，大量重復(fù)請求打到數(shù)據(jù)庫中。實際上除了第一條請求為有效請求，隨后的請求為無效請求，浪費數(shù)據(jù)庫連接資源。

流量的合并與拆分實踐是額外喚醒一個線程，每隔固定時間（比如200毫秒）發(fā)送合并后的請求，執(zhí)行完成后將查詢結(jié)果進(jìn)行拆分，分發(fā)到原始請求中，原始請求響應(yīng)用戶請求。

從應(yīng)用到數(shù)據(jù)庫之間連接資源需求顯著下降，從而提高數(shù)據(jù)庫連接資源利用率。

應(yīng)用實踐

（一）編碼與使用

基于MybatisPlus提供一個內(nèi)置封裝的服務(wù)類QueueServiceImpl，透明的實現(xiàn)查詢詳情流量的合并與拆分，使用者可屏蔽內(nèi)部實現(xiàn)。

<dependency>
    <groupId>xin.altitude.cms</groupId>
    <artifactId>ucode-cms-common</artifactId>
    <version>1.4.4</version>
</dependency>

對于一定時間區(qū)間內(nèi)的所有請求，合并成一條請求處理。

@Override
public BuOrder getOrderById(Long orderId) {
    return getById(orderId);
}

舉例說明，如果特定時間區(qū)間內(nèi)匯集了相同的主鍵請求，那么合并后的請求查詢一次數(shù)據(jù)庫便能夠響應(yīng)所有的請求。

子類重寫父類方法，可修改合并與拆分的行為。

@Override
protected RequstConfig createRequstConfig() {
    RequstConfig config = new RequstConfig();
    /* 單次最大合并請求數(shù)量 */
    config.setMaxRequestSize(100);
    /* 核心線程池大小 */
    config.setCorePoolSize(1);
    /* 請求間隔（毫秒） */
    config.setRequestInterval(200);
    return config;
}

實現(xiàn)細(xì)節(jié)

1、ConcurrentLinkedQueue

使用ConcurrentLinkedQueue并發(fā)安全隊列用于緩沖和接收請求，定時任務(wù)以固定頻率從隊列中消費數(shù)據(jù)，將多條請求條件合并后匯總查詢。

2、CompletableFuture

CompletableFuture類是合并與拆分的關(guān)鍵類，原始請求將查詢條件封裝成CompletableFuture對象，提交到隊列中后陷入阻塞，定時任務(wù)分批次組裝查詢條件，得到結(jié)果后將結(jié)果拆分并存入CompletableFuture對象中，原始請求線程被喚醒，繼續(xù)響應(yīng)用戶請求。

其它應(yīng)用場景

應(yīng)用于數(shù)據(jù)庫間流量的合并請求與拆分，首先提高數(shù)據(jù)庫連接資源（稀缺資源）利用率，其次提高網(wǎng)絡(luò)間數(shù)據(jù)傳輸效率。100條數(shù)據(jù)收發(fā)100次與100條數(shù)據(jù)收發(fā)一次的效率差別。

1、服務(wù)間接口調(diào)用

服務(wù)間API接口調(diào)用同樣適用于流量的合并與拆分：比如向訂單服務(wù)發(fā)送Http API請求，同一時刻有100個用戶發(fā)起查詢請求，使用流量合并與拆分的思想可將多個訂單查詢請求轉(zhuǎn)換成批查詢請求，得到結(jié)果后分發(fā)到不同的請求線程，響應(yīng)用戶請求。

小結(jié)

在本文中，選用的隊列是本地并發(fā)安全的隊列，在分布式系統(tǒng)中，本地隊列是否合適？此處選用本地隊列基于兩點考慮：一是無嚴(yán)格的分布式的需求；二是CompletableFuture類不支持序列化。考慮使用Redis做分布式隊列的想法無法實現(xiàn)，你用本地隊列，盡管會有少量查詢條件數(shù)據(jù)冗余（不影響結(jié)果），回避了分布式隊列的網(wǎng)絡(luò)IO延遲，反而有更優(yōu)的查詢效率。

本方案僅在高并發(fā)場景受益，屬于針對并發(fā)場景進(jìn)行架構(gòu)的優(yōu)化，普通項目使用常規(guī)操作即可。

以上就是Java請求流量合并和拆分提高系統(tǒng)的并發(fā)量示例的詳細(xì)內(nèi)容，更多關(guān)于Java流量合并拆分提高系統(tǒng)的并發(fā)量的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論