共计 1934 个字符，预计需要花费 5 分钟才能阅读完成。
| 导读 | 最近在开发一个定时活动，而且活动是多个场次的。这个是后就需要在活动开始的时候推送信息给客户端，结束的时候也要推送一次。简单的设计方案就是将配置缓存在 redis，然后每隔一秒就轮询 reids，获取配置信息，然后判断是不是到活动开始或者结束的时间点，然后推送给客户端。 |
但是，这里会有一个问题，如果没有到活动开始或结束的时间点，这里会造成很多无用的轮询操作。这个操作不但增大了对这个 key 的访问量，同时也会占用 cpu，降低机器性能。
redis 在 2.8.0 版本提供了一个键空间通知功能机制，对于这个功能的详细描述，可以查阅官方文档。简单总结就是，客户端可以订阅一个 key，当这个可以发生改变时，redis 会通知到已经订阅的客户端。
实现
这个实现也很简单，我们可以通过一个 demo 来看看如何使用这个机制。
| 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 过期自动通知 | |
| */ | |
| func SetExpireEvent() { | |
| // 设置一个键，并且 3 秒钟之后过期 | |
| redisCli.Set(context.Background(), "test_expire_event_notify", "测试键值过期通知", 3*time.Second) | |
| } | |
| func SubExpireEvent() { | |
| // 订阅 key 过期事件 | |
| sub := redisCli2.Subscribe(context.Background(), "__keyevent@0__:expired") | |
| // 这里通过一个 for 循环监听 redis-server 发来的消息。// 当客户端接收到 redis-server 发送的事件通知时，// 客户端会通过一个 channel 告知我们。我们再根据 | |
| // msg 的 channel 字段来判断是不是我们期望收到的消息，// 然后再进行业务处理。for { | |
| msg := | |
| 代码结果输出如下： | |
| 上面代码实现逻辑很简单，核心逻辑就是订阅__keyevent@0__:expired 这个事件，然后一个循环等待事件的通知。值得注意的是，要启用这个特性需要修改配置文件，启用 notify-keyspace-events 这个配置，可以参考配置文件中的注释对不同事件进行启用。 | |
| 在业务中使用 | |
| 回到开始提及的业务场景，如何在这种场景中使用 redis 的机制呢？其实很简单，当活动配置到数据库之后，会有一个更新缓存的步骤。在将数据设置在活动缓存时，只要我们计算当前时间到活动开始 / 结束这个时间差，将这个差作为键的过期时间。 | |
| 例如，活动 id1 的开始时间为 t0, 结束时间为 t2, 当前时间为 t。这个时候就可以这么设置： | |
| // 活动开始的 key 设置 | |
| redisCli.Set(context.Background(), "id1:start", "活动开始了", t0 - t) | |
| // 活动结束结束的 key 设置 | |
| redisCli.Set(context.Background(), "id1:start", "活动开始了", t1 - t) | |
| 通过这么设置，当活动开启 / 结束就可以接收到相应的通知了。 | |
| 总结 | |
| 这种方案其实可以完全满足文中的需求场景，但是这种方案其实也存在一些问题。其实这些问题在 redis 文档中也有相应说明。 | |
| 第一，redis-server 在推送这个事件通知时，只要订阅了这个事件的客户端端都会收到这个消息。通常，我们的业务都是跑在多个结点中，所以这个时候就要根据场景看要不要进行业务的原子操作。 | |
| 第二，redis-server 只会推送一次这个通知。假如说在 redis-server 推送这个通知时，结点挂了或者由于其他异常情况没有收到消息，redis-server 不会再重新推送。 | |
| 第三，通知可能会延迟。由于 redis 实现机制，对于过期的键，会有两种机制进行处理，一种是当命令访问键时，发现键已过期。另一种是通过后台系统在后台逐步查找过期的键，以便能够收集那些从未被访问的键。所以会有出现延迟的可能。 | |
| 本文介绍了使用 redis 的键空间通知机制来实现了一种业务场景，当然这种方式并不是最好的，还有其他方式来实现。在实际开发中会有很多的因素要考虑，而且实现方式也是多种多样，这个就需要我们分析每一种方案的利弊，然后进行抉择。 | |
| 阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年，有高配 | |
| 腾讯云新客低至 82 元 / 年，老客户 99 元 / 年 | |
| 代金券：在阿里云专用满减优惠券 | |
正文完
星哥玩云-微信公众号
