对,你没有看错,上一篇分享插件使用,现在分享插件引发的事故
大背景:
使用延迟队列的目的是要对一部分MQ数据做延迟查询,具体如下:
场景: 生产者(业务方)发送MQ消息,消费者(数据服务)接收到MQ之后,查询业务方数据,之后做计算并落库
存在问题:业务方使用主从分离模式,写主,读从。所以当消费者接收到MQ之后去查询业务方接口,业务方查询的其实是从库,这个时候数据很有可能就不一致,实际情况下看10%左右的概率会出现
从服务分层的角度讲,这个问题并不应该数据服务解决,因为数据服务就应该信任接口的数据,在当时的那个场景,那个时间点,查询到的就是这个数据
但是业务方才是老大,毕竟数据只是辅助,这里就体现了数据服务的弟位。
其实解决方案有接收到MQ之后延迟查询,做一个sleep这样的操作,但是当时觉得这样太粗暴,整体延时并不是一个好的办法,毕竟绝大部分情况下是不需要这样处理的
BTW:实际场景中这个消息队列是很多业务服务共用的
此时就想到了延迟队列,服务内部使用一个延迟队列,来完成对指定消息的延迟即:
原有队列 -> 数据服务 -> 延迟队列 ->数据服务
不需要延迟的可以在第一次被数据服务消费的时候就处理掉,其余的经过延迟队列之后再次由数据服务消费处理掉
实际上线之后平稳运行了一段时间之后出现了情况:
- 丢消息
- 某一个rabbitMQ 节点内存被占满,并且节点重启之后依瞬