关于异步消息，大家都知道，如下：
这些用起来都是比较复杂的，RabbitMQ先要创建Exchange,在创建Queue,还要将Queue和Exchange通过某种规则绑定起来。发消息之前要指定routing-Key，还要控制头部信息。
即使你只需要一组消息者。那么你就要经历上面繁琐的过程。
但是Redis对于那些轻量级和只有一组消息者的消息队列；
Redis的list数据结构常用来作为异步消息队列来使用。使用rpush/lpush操作入队列，用lpop/rpop来出队列。我们都知道list是一个链表，所以操作方式如下
当然我们会遇到一些问题，比如队列空了会怎么样？客户端是通过队列的 pop 操作来获取消息，然后进行处理。处理完了再接着获取消息，再进行处理。如此循环往复，这便是作为队列消费者的客户端的生命周期。 可是如果队列空了，客户端就会陷入 pop 的死循环，不停地 pop，没有数据，接着再 pop，又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的 CPU，redis 的 QPS 也会被拉高，如果这样空轮询的客户端有几十来个，Redis 的慢查询可能会显著增多。 通常我们使用 sleep 来解决这个问题，让线程睡一会，睡个 1s 钟就可以了。不但客户端的 CPU 能降下来，Redis 的 QPS 也降下来了。（摘自Redis深度历险）
睡眠会导致消息的延迟增大·，多个消费者情况下，延迟会有所下降，因为每个消费者都是的睡眠时间是岔开来的。通过阻塞读：blocking，也就是这两个命令：blpop，brpop。
当然还有会空闲连接自动断开，顾名思义，一直阻塞，Redis客户端就成了闲置的，时间长了，服务器会断开连接，减少闲置资源，这时候就会抛出异常，所以编写消费者的时候，注意捕获异常，重试。
延时队列：
这种方式比较适合异步消息处理，将当前冲突的请求扔到另一个队列延后处理以避开冲突
我们将消息序列化成一个字符串作为 zset 的 value，这个消息的到期处理时间作为 score，然后用多个线程轮询 zset 获取到期的任务进行处理，多个线程是为了保障可用性，万一挂了一个线程还有其它线程可以继续处理。因为有多个线程，所以需要考虑并发争抢任务，确保任务不能被多次执行。
