[發(fā)明專利]一種基于Jedis的將多線程并發(fā)請求合并批量提交并分發(fā)結(jié)果的實(shí)現(xiàn)方法

有效

• 申請?zhí)枺?/td>: 201611029743.7
• 申請日: 2016-11-15
• 公開（公告）號(hào): CN108073414B
• 公開（公告）日: 2020-07-28
• 發(fā)明（設(shè)計(jì)）人: 石志光;歐陽軍;陳丹
• 申請（專利權(quán)）人: 北京億陽信通科技有限公司
• 主分類號(hào): G06F9/38
• 分類號(hào): G06F9/38
• 代理公司: 北京辰權(quán)知識(shí)產(chǎn)權(quán)代理有限公司 11619
• 代理人: 劉廣達(dá)

本發(fā)明提供一種基于Jedis的將多線程并發(fā)請求合并批量提交并分發(fā)結(jié)果的實(shí)現(xiàn)方法。本發(fā)明將同一進(jìn)程內(nèi)多個(gè)Redis請求合并到同一個(gè)Pipeline中批量提交，再將返回結(jié)果分發(fā)給原來的各個(gè)請求。提供了同步請求和異步請求兩種不同的請求模式，可以根據(jù)多種配置實(shí)現(xiàn)不同的提交策略。另外，本發(fā)明還提供了客戶端主動(dòng)提交接口，每個(gè)請求可根據(jù)業(yè)務(wù)需要實(shí)時(shí)觸發(fā)批量提交。最終經(jīng)過測試，通過以上技術(shù)方案實(shí)現(xiàn)，可以大大提高客戶端并發(fā)請求的響應(yīng)性能。

技術(shù)領(lǐng)域

本發(fā)明屬于數(shù)據(jù)庫技術(shù)領(lǐng)域，尤其涉及一種基于Jedis的將多線程并發(fā)請求合并批量提交并分發(fā)結(jié)果的實(shí)現(xiàn)方法。

背景技術(shù)

Redis是一種目前較流行的NoSQL數(shù)據(jù)庫。Jedis是Redis官方推薦的Java客戶端開發(fā)包。在單進(jìn)程多線程應(yīng)用中，在通過Jedis訪問Redis服務(wù)器時(shí)：如果使用普通的方式訪問，每個(gè)線程各自都會(huì)持有一個(gè)單獨(dú)的連接，并通過各自持有的連接單獨(dú)發(fā)起請求，等待響應(yīng)結(jié)果。而Redis的特點(diǎn)是服務(wù)器端采用了單線程處理模式，即服務(wù)端只能順序處理收到的請求。這就造成了多個(gè)客戶端請求之間的相互等待，進(jìn)而影響了應(yīng)用的整體性能。

也可以采用另外一種方式，通過管道方式Pipeline，Pipeline適用于批處理，當(dāng)有大量的操作需要一次性執(zhí)行的時(shí)候，可以用Pipeline。Jedis自身已有提供Pipeline方式，該方式在客戶端發(fā)送請求時(shí)是異步，下發(fā)請求后可以不等待返回接著再發(fā)送后續(xù)請求，在將請求全部發(fā)送后，再執(zhí)行提交操作，然后一次性獲取到之前全部請求的結(jié)果。這種方式可以通過異步提高客戶端的吞吐量，但是由于多個(gè)客戶端提交請求的并發(fā)操作，每個(gè)客戶端都會(huì)執(zhí)行自己的提交請求，而且由于服務(wù)器端只能同時(shí)處理一個(gè)客戶端的請求，這樣也會(huì)造成不同客戶端之間執(zhí)行提交請求時(shí)的相互等待，同樣會(huì)影響應(yīng)用整體的性能。

發(fā)明內(nèi)容

本發(fā)明就是為了解決類似于如上描述的這種問題，來提高應(yīng)用的整體性能。本發(fā)明的總體思路是，將Jedis進(jìn)程內(nèi)多線程并發(fā)請求收集起來，同時(shí)通過原有底層單一連接Pipeline執(zhí)行異步請求，將請求統(tǒng)一提交，然后再一次性獲取請求的結(jié)果，最后把請求的結(jié)果分發(fā)給各個(gè)調(diào)用線程。

本發(fā)明的目的是通過以下技術(shù)方案實(shí)現(xiàn)的。

本發(fā)明提出了一種基于Jedis的將多線程并發(fā)請求合并批量提交并分發(fā)結(jié)果的實(shí)現(xiàn)方法，所述Jedis的封裝包括以下模塊：基本操作模塊、監(jiān)聽器模塊、喚醒器模塊；其中，PipelineWrapper是基本操作模塊的主類，TimerMonitor是監(jiān)聽器模塊的主類，Notifier是喚醒器模塊的主類；

所述方法包括：

客戶端線程向PipelineWrapper發(fā)起請求，所述請求包括同步請求op()、異步請求opAsync()或批量提交sync()中的一種；

所述請求首先向PipelineWrapper請求全局排它鎖；

獲得鎖之后，向底層的Pipeline發(fā)起op()、opAsync()請求或者sync()請求的其中一種；

所述op()、opAsync()請求對PipelineWrapper的操作計(jì)數(shù)屬性opCount執(zhí)行+1操作，一旦opCountmaxOpCount，觸發(fā)批量提交sync()的執(zhí)行；

釋放全局排它鎖；

獲取結(jié)果并返回。

對于同步請求op()，每次執(zhí)行都會(huì)向同步操作上報(bào)隊(duì)列(respQueue)中增加一個(gè)代表該請求結(jié)果是否已經(jīng)可以讀取的信號(hào)量(Semaphore)，該信號(hào)量會(huì)在批量提交sync()執(zhí)行時(shí)由Notifier喚醒。所述TimerMonitor會(huì)按照設(shè)定的間隔時(shí)間，周期性地執(zhí)行PipelineWrapper的批量提交方法sync()，觸發(fā)底層批量提交的執(zhí)行。