能够参考数据库乐观锁机制,好比执行一条更新库存的 SQL 语句,在并发场景,为了性能和数据可靠性,会在更新时加上查询时的版本,而且更新这个版本信息。可能你要对一个事情进行操做,这个操做可能会执行成百上千次,可是操做结果都是相同的,这就是幂等性。html
在海量订单生成的业务高峰期,生产端有可能就会重复发生了消息,这时候消费端就要实现幂等性,这就意味着咱们的消息永远不会被消费屡次,即便咱们收到了同样的消息。redis
业界主流的幂等性有两种操做:算法
1.惟一 ID + 指纹码 机制,利用数据库主键去重数据库
2.利用redis的原子性去实现
缓存
你们确定懂惟一 ID 的,就很少说了,为何须要指纹码呢?这是为了应对用户在一瞬间的频繁操做,这个指纹码多是咱们的一些规则或者时间戳加别的服务给到的惟一信息码,它并不必定是咱们系统生成的,基本都是由咱们的业务规则拼接而来,可是必定要保证惟一性,而后就利用查询语句进行判断这个id是否存在数据库中。架构
好处就是实现简单,就一个拼接,而后查询判断是否重复。并发
坏处就是在高并发时,若是是单个数据库就会有写入性能瓶颈高并发
解决方案 :根据 ID 进行分库分表,对 id 进行算法路由,落到一个具体的数据库,而后当这个 id 第二次来又会落到这个数据库,这时候就像我单库时的查重同样了。利用算法路由把单库的幂等变成多库的幂等,分摊数据流量压力,提升性能。工具
相信你们都知道 redis 的原子性操做,我这里就不须要过多介绍了。性能
使用 redis 的原子性去实现须要考虑两个点
一是 是否 要进行数据落库,若是落库的话,关键解决的问题是数据库和缓存如何作到原子性? 数据库与缓存进行同步确定要进行写操做,到底先写 redis 仍是先写数据库,这是个问题,涉及到缓存更新与淘汰的问题
二是若是不落库,那么都存储到缓存中,如何设置定时同步的策略? 不入库的话,可使用双重缓存等策略,保障一个消息副本,具体同步可使用相似 databus 这种同步工具。
先大概说一说可能会有哪些重复消费的问题。
首先就是好比rabbitmq、rocketmq、kafka,都有可能会出现消费重复消费的问题,正常。由于这问题一般不是mq本身保证的,是给你保证的。而后咱们挑一个kafka来举个例子,说说怎么重复消费吧。
kafka实际上有个offset的概念,就是每一个消息写进去,都有一个offset,表明他的序号,而后consumer消费了数据以后,每隔一段时间,会把本身消费过的消息的offset提交一下,表明我已经消费过了,下次我要是重启啥的,你就让我继续从上次消费到的offset来继续消费吧。
可是凡事总有意外,好比咱们以前生产常常遇到的,就是你有时候重启系统,看你怎么重启了,若是碰到点着急的,直接kill进程了,再重启。这会致使consumer有些消息处理了,可是没来得及提交offset,尴尬了。重启以后,少数消息会再次消费一次。
其实重复消费不可怕,可怕的是你没考虑到重复消费以后,怎么保证幂等性。
给你举个例子吧。假设你有个系统,消费一条往数据库里插入一条,要是你一个消息重复两次,你不就插入了两条,这数据不就错了?可是你要是消费到第二次的时候,本身判断一下已经消费过了,直接扔了,不就保留了一条数据?
一条数据重复出现两次,数据库里就只有一条数据,这就保证了系统的幂等性
幂等性,我通俗点说,就一个数据,或者一个请求,给你重复来屡次,你得确保对应的数据是不会改变的,不能出错。
6、其实仍是得结合业务来思考,我这里给几个思路:
(1)好比你拿个数据要写库,你先根据主键查一下,若是这数据都有了,你就别插入了,update一下好吧
(2)好比你是写redis,那没问题了,反正每次都是set,自然幂等性
(3)好比你不是上面两个场景,那作的稍微复杂一点,你须要让生产者发送每条数据的时候,里面加一个全局惟一的id,相似订单id之类的东西,而后你这里消费到了以后,先根据这个id去好比redis里查一下,以前消费过吗?若是没有消费过,你就处理,而后这个id写redis。若是消费过了,那你就别处理了,保证别重复处理相同的消息便可。
还有好比基于数据库的惟一键来保证重复数据不会重复插入多条,咱们以前线上系统就有这个问题,就是拿到数据的时候,每次重启可能会有重复,由于kafka消费者还没来得及提交offset,重复数据拿到了之后咱们插入的时候,由于有惟一键约束了,因此重复数据只会插入报错,不会致使数据库中出现脏数据
如何保证MQ的消费是幂等性的,须要结合具体的业务来看