請求合併與拆分在併發場景中應用

Java知識圖譜發表於2022-03-16

一、序言

在併發場景中，當熱點快取Key失效時，流量瞬間打到資料庫中，此所謂快取擊穿現象；當大範圍的快取Key失效時，流量也會打到資料庫中，此所謂快取雪崩現象。

當使用分散式行鎖時，能夠有效解決快取擊穿問題；當使用分散式表鎖時，能夠解決快取雪崩問題。實際操作中，分散式表鎖不在考慮範圍，理由是降低併發量。

本文將從另一個角度出發，將請求流量合併和拆分，以提高系統的併發量。

二、理論基礎

流量的合併與拆分原理是將多條請求合併成一條請求，執行後再將結果拆分。在資料庫與快取架構中，快取Key失效的瞬間，大量重複請求打到資料庫中。實際上除了第一條請求為有效請求，隨後的請求為無效請求，浪費資料庫連線資源。

流量的合併與拆分實踐是額外喚醒一個執行緒，每隔固定時間（比如200毫秒）傳送合併後的請求，執行完成後將查詢結果進行拆分，分發到原始請求中，原始請求響應使用者請求。

f7bd6f1a6885debbba2c79e88cae2c9b2

從應用到資料庫之間連線資源需求顯著下降，從而提高資料庫連線資源利用率。

三、應用實踐

（一）編碼與使用

基於MybatisPlus提供一個內建封裝的服務類QueueServiceImpl，透明的實現查詢詳情流量的合併與拆分，使用者可遮蔽內部實現。

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

對於一定時間區間內的所有請求，合併成一條請求處理。

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

舉例說明，如果特定時間區間內彙集了相同的主鍵請求，那麼合併後的請求查詢一次資料庫便能夠響應所有的請求。

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

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

（二）實現細節

1、ConcurrentLinkedQueue

使用ConcurrentLinkedQueue併發安全佇列用於緩衝和接收請求，定時任務以固定頻率從佇列中消費資料，將多條請求條件合併後彙總查詢。

2、CompletableFuture

CompletableFuture類是合併與拆分的關鍵類，原始請求將查詢條件封裝成CompletableFuture物件，提交到佇列中後陷入阻塞，定時任務分批次組裝查詢條件，得到結果後將結果拆分並存入CompletableFuture物件中，原始請求執行緒被喚醒，繼續響應使用者請求。

3、ScheduledExecutorService

以一定的時間間隔傳送合併後的請求。

（二）其它應用場景

應用於資料庫間流量的合併請求與拆分，首先提高資料庫連線資源（稀缺資源）利用率，其次提高網路間資料傳輸效率。100條資料收發100次與100條資料收發1次的效率差別。

1、服務間介面呼叫

服務間API介面呼叫同樣適用於流量的合併與拆分：比如向訂單服務傳送Http API請求，同一時刻有100個使用者發起查詢請求，使用流量合併與拆分的思想可將多個訂單查詢請求轉換成批查詢請求，得到結果後分發到不同的請求執行緒，響應使用者請求。

四、小結

在本文中，選用的佇列是本地併發安全的佇列，在分散式系統中，本地佇列是否合適？此處選用本地佇列基於兩點考慮：一是無嚴格的分散式的需求；二是CompletableFuture類不支援序列化。考慮使用Redis做分散式佇列的想法無法實現，你用本地佇列，儘管會有少量查詢條件資料冗餘（不影響結果），迴避了分散式佇列的網路IO延遲，反而有更優的查詢效率。

本方案僅在高併發場景受益，屬於針對併發場景進行架構的優化，普通專案使用常規操作即可。

演示專案程式碼地址

相關文章