redis实现消息消费确认(ack机制)

前言

消息中间件有很多，例如 ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。这些消息系统都很专业，无论是可靠性，容错性，高性能都有自己独特的特点，那为什么我们还要用redis做消息队列

为什么用redis做消息队列

拥有普通消息组件的特性

• redis的list,set等集合都支持pop,push这些出栈入栈的操作,详见 redis命令
• redis支持订阅发布模式
• 能依靠双队列实现消息确认模式

轻量易用

搭建一个mq需要你学习它，有的mq搭建还不是那么容易，但是redis很方便搭建，用的人多，学习成本也低

省钱省力省时

一般的公司都有redis方面的应用，例如做缓存，我们就不需要额外的服务器资源来重新搭建mq,对于开发人员来说，学习redis很简单，大多数也用过，开放起来很轻松也很快。

redis实现消息确认 ack机制

像RabbitMQ这种消息队列一般都有先消费再commit提交确认消费的机制，而kafka也可以通过提交偏移量来实现ack:Kafka ack消费确认-提交和偏移量

如何用redis实现消息发布和消费

使用list，set等集合的 pop和push就能快速实现实时的消息消费和发布。例如redis List（列表） 的 LPUSH 和 RPOP

redis如何实现消息确认 ack

什么是ack

ACK的全称为Acknowledge character，即确认字符，表示接收到的字符无错误。意思就是我把消息处理完了我再告诉mq，我业务逻辑都搞完了，你服务器可以把这条消息删了。这就是为了防止消息丢失，防止业务层消费了消息，而没把活干完。

redis实现ack的原理

维护两个队列，假如一个消息队列的key叫做task，另外一个队列的key是doing表示正在处理的任务
每次消费task的消息的同时就放到doing队列
处理完消息就删除doing对应的消息
使用定时任务检查doing队列，检查消息中的时间属性（这个需要产生消息的时候就可以加入时间戳），如果超时就把消息回滚到task队列
redis适合一般的业务系统，而像大数据处理系统，日志收集，就需要类似kafka这种大名鼎鼎的MQ!