導(dǎo)語(yǔ)

最近在開發(fā)一個(gè)定時(shí)活動(dòng)，而且活動(dòng)是多個(gè)場(chǎng)次的。這個(gè)是后就需要在活動(dòng)開始的時(shí)候推送信息給客戶端，結(jié)束的時(shí)候也要推送一次。簡(jiǎn)單的設(shè)計(jì)方案就是將配置緩存在redis，然后每隔一秒就輪詢r(jià)eids，獲取配置信息，然后判斷是不是到活動(dòng)開始或者結(jié)束的時(shí)間點(diǎn)，然后推送給客戶端。

但是，這里會(huì)有一個(gè)問題，如果沒有到活動(dòng)開始或結(jié)束的時(shí)間點(diǎn)，這里會(huì)造成很多無(wú)用的輪詢操作。這個(gè)操作不但增大了對(duì)這個(gè)key的訪問量，同時(shí)也會(huì)占用cpu，降低機(jī)器性能。

redis在2.8.0版本提供了一個(gè)鍵空間通知功能機(jī)制，對(duì)于這個(gè)功能的詳細(xì)描述，可以查閱官方文檔。簡(jiǎn)單總結(jié)就是，客戶端可以訂閱一個(gè)key，當(dāng)這個(gè)可以發(fā)生改變時(shí)，redis會(huì)通知到已經(jīng)訂閱的客戶端。

實(shí)現(xiàn)

這個(gè)實(shí)現(xiàn)也很簡(jiǎn)單，我們可以通過(guò)一個(gè)demo來(lái)看看如何使用這個(gè)機(jī)制。

package main

import (
   "context"
   "fmt"
   "github.com/go-redis/redis/v8"
   "time"
)

var redisCli *redis.Client

func init() {
   // 連接redis
   redisCli = redis.NewClient(redis.Options{
      Addr:     "127.0.0.1:6379",
      Password: "redis123",
   })
}

/*
 * redis key 過(guò)期自動(dòng)通知
 */
func SetExpireEvent() {
   // 設(shè)置一個(gè)鍵，并且3秒鐘之后過(guò)期
   redisCli.Set(context.Background(), "test_expire_event_notify", "測(cè)試鍵值過(guò)期通知", 3*time.Second)
}

func SubExpireEvent() {
   // 訂閱key過(guò)期事件
   sub := redisCli2.Subscribe(context.Background(), "__keyevent@0__:expired")
   
   // 這里通過(guò)一個(gè)for循環(huán)監(jiān)聽redis-server發(fā)來(lái)的消息。
   // 當(dāng)客戶端接收到redis-server發(fā)送的事件通知時(shí)，
   // 客戶端會(huì)通過(guò)一個(gè)channel告知我們。我們?cè)俑鶕?jù)
   // msg的channel字段來(lái)判斷是不是我們期望收到的消息，
   // 然后再進(jìn)行業(yè)務(wù)處理。
   for {
      msg := -sub.Channel()
      fmt.Println("Channel ", msg.Channel)
      fmt.Println("pattern ", msg.Pattern)
      fmt.Println("pattern ", msg.Payload)
      fmt.Println("PayloadSlice ", msg.PayloadSlice)
   }
}

func main() {
   SetExpireEvent()
   go SubExpireEvent()
   
   // 這里sleep是為了防止main方法直接推出
   time.Sleep(10 * time.Second)
}

代碼結(jié)果輸出如下：

上面代碼實(shí)現(xiàn)邏輯很簡(jiǎn)單，核心邏輯就是訂閱__keyevent@0__:expired這個(gè)事件，然后一個(gè)循環(huán)等待事件的通知。值得注意的是，要啟用這個(gè)特性需要修改配置文件，啟用notify-keyspace-events這個(gè)配置，可以參考配置文件中的注釋對(duì)不同事件進(jìn)行啟用。

在業(yè)務(wù)中使用

回到開始提及的業(yè)務(wù)場(chǎng)景，如何在這種場(chǎng)景中使用redis的機(jī)制呢？其實(shí)很簡(jiǎn)單，當(dāng)活動(dòng)配置到數(shù)據(jù)庫(kù)之后，會(huì)有一個(gè)更新緩存的步驟。在將數(shù)據(jù)設(shè)置在活動(dòng)緩存時(shí)，只要我們計(jì)算當(dāng)前時(shí)間到活動(dòng)開始/結(jié)束這個(gè)時(shí)間差，將這個(gè)差作為鍵的過(guò)期時(shí)間。

例如，活動(dòng)id1的開始時(shí)間為t0, 結(jié)束時(shí)間為t2, 當(dāng)前時(shí)間為t。這個(gè)時(shí)候就可以這么設(shè)置：

// 活動(dòng)開始的key設(shè)置
redisCli.Set(context.Background(), "id1:start", "活動(dòng)開始了", t0 - t)
// 活動(dòng)結(jié)束結(jié)束的key設(shè)置
redisCli.Set(context.Background(), "id1:start", "活動(dòng)開始了", t1 - t)

通過(guò)這么設(shè)置，當(dāng)活動(dòng)開啟/結(jié)束就可以接收到相應(yīng)的通知了。

總結(jié)

這種方案其實(shí)可以完全滿足文中的需求場(chǎng)景，但是這種方案其實(shí)也存在一些問題。其實(shí)這些問題在redis文檔中也有相應(yīng)說(shuō)明。

• 第一，redis-server在推送這個(gè)事件通知時(shí)，只要訂閱了這個(gè)事件的客戶端端都會(huì)收到這個(gè)消息。通常，我們的業(yè)務(wù)都是跑在多個(gè)結(jié)點(diǎn)中，所以這個(gè)時(shí)候就要根據(jù)場(chǎng)景看要不要進(jìn)行業(yè)務(wù)的原子操作。
• 第二，redis-server只會(huì)推送一次這個(gè)通知。假如說(shuō)在redis-server推送這個(gè)通知時(shí)，結(jié)點(diǎn)掛了或者由于其他異常情況沒有收到消息，redis-server不會(huì)再重新推送。
• 第三，通知可能會(huì)延遲。由于redis實(shí)現(xiàn)機(jī)制，對(duì)于過(guò)期的鍵，會(huì)有兩種機(jī)制進(jìn)行處理，一種是當(dāng)命令訪問鍵時(shí)，發(fā)現(xiàn)鍵已過(guò)期。另一種是通過(guò)后臺(tái)系統(tǒng)在后臺(tái)逐步查找過(guò)期的鍵，以便能夠收集那些從未被訪問的鍵。所以會(huì)有出現(xiàn)延遲的可能。

本文介紹了使用redis的鍵空間通知機(jī)制來(lái)實(shí)現(xiàn)了一種業(yè)務(wù)場(chǎng)景，當(dāng)然這種方式并不是最好的，還有其他方式來(lái)實(shí)現(xiàn)。在實(shí)際開發(fā)中會(huì)有很多的因素要考慮，而且實(shí)現(xiàn)方式也是多種多樣，這個(gè)就需要我們分析每一種方案的利弊，然后進(jìn)行抉擇。

到此這篇關(guān)于redis鍵空間通知使用實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)redis鍵空間通知 內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！