序言

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

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

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

理論基礎(chǔ)

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

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

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

應(yīng)用實(shí)踐

（一）編碼與使用

基于MybatisPlus提供一個(gè)內(nèi)置封裝的服務(wù)類(lèi)QueueServiceImpl，透明的實(shí)現(xiàn)查詢(xún)?cè)斍榱髁康暮喜⑴c拆分，使用者可屏蔽內(nèi)部實(shí)現(xiàn)。

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

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

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

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

子類(lèi)重寫(xiě)父類(lèi)方法，可修改合并與拆分的行為。

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

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

1、ConcurrentLinkedQueue

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

2、CompletableFuture

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

其它應(yīng)用場(chǎng)景

應(yīng)用于數(shù)據(jù)庫(kù)間流量的合并請(qǐng)求與拆分，首先提高數(shù)據(jù)庫(kù)連接資源（稀缺資源）利用率，其次提高網(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請(qǐng)求，同一時(shí)刻有100個(gè)用戶(hù)發(fā)起查詢(xún)請(qǐng)求，使用流量合并與拆分的思想可將多個(gè)訂單查詢(xún)請(qǐng)求轉(zhuǎn)換成批查詢(xún)請(qǐng)求，得到結(jié)果后分發(fā)到不同的請(qǐng)求線(xiàn)程，響應(yīng)用戶(hù)請(qǐng)求。

小結(jié)

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

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

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

最新評(píng)論