keyspace notifications
以__keyspace@<db>__:为前缀
后面跟的是key的名称
以__keyevent@<db>__:为前缀
后面跟的是消息事件类型
例：__keyevent@0__:expired
延迟队列实现原理
其实就是当这个key过期之后，Redis会发布一个key过期的事件到__keyevent@<db>__:expired这个channel，<br>只要我们的服务监听这个channel，那么就能知道过期的Key，从而就算实现了延迟队列功能<br>
这种方式有什么坑
依赖key清除时机，时效性较差<br>
惰性删除
定时删除
丢消息太频繁
Redis实现的发布订阅模式，消息是没有持久化机制，当消息发布到某个channel之后，如果没有客户端订阅<br>这个channel，那么这个消息就丢了，并不会像MQ一样进行持久化，等有消费者订阅的时候再给消费者消费。<br>
消息消费只有广播模式
只有这一种模式
多个消费者订阅同一个channel，那么每个消费者都能消费到发布<br>到这个channel的所有消息<br>
如果通过监听channel来获取延迟任务，那么一旦服务实例有多个的话，<br>还得保证消息不能重复处理，额外地增加了代码开发量<br>
接收到所有key的某个事件
这个不属于Redis发布订阅模式的问题，而是Redis本身事件通知的问题
当消费者监听了以__keyevent@<db>__:开头的消息，那么会导致所有的key发生了事件都会被通知给消费者
