Redis键通知机制
一、概念
自从redis2.8以后出了一个新特性，Keyspace Notifications 称为“键空间通知”。
这个特性大概是，凡是实现了Redis的Pub/Sub的客户端，只需要订阅相应Channel，就可以获得对Key操作的一些事件，从而可以处理一些业务。
比如：
1、当你del一个key时，就可以触发一个del事件通知。
2、一个key的失效时间到了，就会触发expire事件通知。
3、对一个库所有key操作，都可以获取通知。比如对0库所有key的操作。
注意事项：
1）因为 Redis 目前的订阅与发布功能采取的是发送即忘（fire and forget）策略， 所以如果你的程序需要可靠事件通知（reliable notification of events）， 那么目前的键空间通知可能并不适合你：当订阅事件的客户端断线时， 它会丢失所有在断线期间分发给它的事件。并不能确保消息送达。
2）Redis Pub/Sub 是一种并不可靠地消息机制，他不会做信息的存储，只是在线转发，那么肯定也没有ack确认机制，另外只有订阅段监听时才会转发！所以Keyspace Notification 也不是可靠地通知系统，如果你的系统需要很好的可靠性，那么Keyspace Notification可能并不是一种很好的选择。
配置：默认情况下，Redis 并不会开启Keyspace Notification， 我们可以通过修改redis.conf的notify-keyspace-events 或者使用CONFIG SET命令来开启该功能，设置参数，来开启全部或者部分通知， 以下是设置参数详细说明列表：
过期通知的发送时间：
Redis 使用以下两种方式删除过期的键：
1）当一个键被访问时，程序会对这个键进行检查，如果键已经过期，那么该键将被删除。
2）底层系统会在后台渐进地查找并删除那些过期的键，从而处理那些已经过期、但是不会被访问到的键。
当过期键被以上两个程序的任意一个发现、 并且将键从数据库中删除时， Redis 会产生一个 expired 通知。
Redis 并不保证生存时间（TTL）变为 0 的键会立即被删除： 如果程序没有访问这个过期键， 或者带有生存时间的键非常多的话， 那么在键的生存时间变为 0 ， 直到键真正被删除这中间， 可能会有一段比较显著的时间间隔。
因此， Redis 产生 expired 通知的时间为过期键被删除的时候， 而不是键的生存时间变为 0 的时候。
二、订阅
1）subscribe & psubscribe命令来对特定主题进行订阅，完成事件通知的过程。
SUBSCRIBE channel [channel ...]
PSUBSCRIBE channelPattern [channelPattern ...]
区别：PSUBSCRIBE 跟 SUBSCRIBE 唯一不同，就是支持通配符。每个模式以 * 作为匹配符，比如 huangz* 匹配所有以 huangz。显然支持通配符的性能消耗会大一点。
2）订阅的表达式
__key空间/事件@数据库id__:对象
比如：
[email protected]__:mykey 订阅数据库0中 mykey的相关事件
[email protected]__:del 订阅数据库0中的 del事件
两者的区别在于，一个是符合key就通知，一个是符合事件就通知。
对于key在哪个数据库，我们很难知道，那么可以使用"*"匹配所有：
__key*__:*
原文地址：https://www.cnblogs.com/hld123/p/10812848.html