文章目录
- 1.消息可靠性保障
- 2.消息的幂等性保障
1.消息可靠性保障
在实际生产环境中,可能会由于网络问题导致消息接收异常产生某种影响,基于这种情况我们需要保障消息的可靠性。
RabbitMQ中的消息可靠性也称为消息补偿,如下图所示,可以保证消息的可靠性。
分为9种种步骤实现消息补偿
1、生产者处理业务逻辑,将数据写入到数据库。
2、生产者将业务数据写入数据库后,向Q1消息队列发送消息数据。
3、生产者向Q1发送完消息数据后,过段时间后,会发送一个延迟消息到达Q3队列。
4、消费者从Q1队列中读取消息数据。
5、读取消息数据后,消费者根据业务逻辑向数据库中写入数据。
6.、消费者充当发布者的身份向Q2队列写入一条确认收到消息的数据,表示消费者已经收到数据并且进行了业务处理。
7、回调检查系统从Q2队列中读取消费者发送的消息数据。
8、回调检查系统再将消息数据写入到MQ数据库中,作用于记录消息传递是否成功的标志。
如果消费者接收消息出现了异常,接收失败了,第三步发送延迟消息就起到了保证消息可靠性的重要环节,生产者会发生一个延迟消息到Q3队列中,回调系统也会从Q3队列中读取延迟消息,延迟消息和正常消息是一模一样的,回调检查系统会把延迟消息的ID与MQ数据库中的消息ID进行比对,如果存在数据那么久不会再做任何处理,如果发现数据库中不存在这个消息ID,回调检查系统此时就会调用生产者重新发送消息,来保证消息传递的可靠性。
还有另外一种情况,如何延迟消息和正常消息都接收异常了,又该如何处理呢?
很简单,如上图所示,会有一个定时检查的服务,业务数据入库时也会携带消息数据的ID,用消息数据的ID去比对MQ数据库中的消息ID,当数据不存在时,定时检查服务会去调用生产者再次发生消息数据,保证消息的可靠性。
2.消息的幂等性保障
幂等性的概念:一次或者多次请求相同的资源,触发一样的业务逻辑,最终返回的结果应该是最初同样的结果,例如你9点吃早饭,那么而不管你吃了多少次早饭,都应该是9点去,不能出现不同的结果。
在MQ消息队列中,正常情况下,无论发送了多少次相同的消息,最终的结果都应该是一样的,就比如一个消息数据要扣款五百,发送了很多次,绝对不能出现多次扣款的情况。
如何保证消息的幂等性,方式有很多种,比如通过数据库的乐观锁来实现。
数据库的乐观锁主要是在数据中加上一个version字段,当通过MQ的消息触发数据库数据的修改,修改的时候匹配的条件就需要加上version这个字段,只有数据中version=1存在时修改数据,第一条消息记录造成了数据修改,那么第二条消息发送过来的时候也会匹配version=1的数据,此时就不会造成数据的修改了,因为库中已经不存在这个数据了。
如下图所示,发送时就携带了一个version=1的消息数据,消费者读取数据进行处理时,也会在数据库中查询version=1的数据进行修改,如果第一次发送过来的消息被成功处理了,version的值就会被修改,那么库中就没有version=1的数据了,即使后面发送过来多条相同的数据,条件已经不满足了,也不会被数据库修改。
第一次执行时version为1
update account set memory=memory-500,version=version+1 where id =1 and version=1
修改的数据也是匹配的version=1的数据,将数据里面的钱扣五百元,然后再将version+1,从而将version变成了2
第二次执行时,version已经是2了,从而无法匹配数据无法进行操作,保证数据的幂等性
update account set memory=memory-500,version=version+1 where id =1 and version=1