本文探讨了消息消费的三种模式：最多一次、最少一次和有且仅有一次，并着重讨论了如何处理重复消息和顺序问题。对于重复消息，提出了不处理、业务处理和使用去重表三种策略；对于顺序问题，介绍了不处理、业务处理（状态机）和利用额外字段（时间戳和版本号）的方法。此外，还提到了Kafka等消息队列的特性以及使用partitionkey确保消息顺序的可能性。
consumer消费到重复消息怎么办?
消息消费模式
消息消费一般存在三种模式：最多一次，最少一次和有且仅有一次。
最多一次
这种可靠性最低，不管消费是否成功，投递一次就算完了。这种类型一般用在可靠性不高的场景中，比如我们一个对日志分析展示的场景，如果这种日志分析出现一定的缺失对业务也影响不大，那我们可以使用这种方式，这种方式性能最高。
最少一次
基本上所有追求可靠性的消息队列都会采用这种模式。因为网络是不可靠的，要在不可靠的网络基础上构建可靠的业务，就必须使用重试来实现，那么重试就有可能引入重复的消息。
有且仅有一次
这是人们最期望的方式。也就是我如果真正的处理失败了(业务失败)你才给我重发，如果仅仅是因为网络等原因导致的超时不能给我重发消息。但是这种仅仅靠消息队列自身是很难保证的。不过借助一些其他手段，是能达到有且仅有一次的『效果』。
通过上面的描述，我们知道有且仅有一次的消息投递模式是很难达到的，那如果我们需要消息的可靠性，就必须接受重复消息这个事实。那么对于重复消息到底该怎么办呢？下面会列出一些场景和解决方案：
处理方式
不处理
有人可能会说这也算解决方案么？我当然不是说所有的重复消息都可以不处理的，但是是有场景是可以的。比如我们有一个缓存，数据库更新之后我们发送一条消息去将缓存删掉，等下一次数据访问的时候缓存没有命中，从数据库重新加载新数据并更新缓存。这里的消息就是删除缓存的消息，那么删除缓存这个消息就是可以接受重复消息的，这种重复消息对业务几乎没有影响(影响也是有，可能会稍微降低缓存命中率)，我们权衡一下处理重复消息的成本和这个对业务的影响，那么不处理就是个最佳方案了。可能有同学说，降低缓存命中率也不行啊，还是得解决。那么我们看这个重复消息会降低多少命中率呢？那就得看重复消息多不多呢？重复消息一般是网络不稳定导致的，这在内网里这种情况其实并不常见，所以我觉得是可以接受的。
业务处理
有同学讲这不是废话么？重复消息当然是我们业务处理啊。我这里说的业务处理是说有很多业务逻辑自身就是能处理重复消息的，也就是有很多业务逻辑本来就是幂等的。这里有个题外话：即使我们不使用消息，也要尽量将我们的接口设计为幂等的。比如我们有一个创建新订单的消息，接到消息后会向数据库保存新订单。那么如果我们接到了重复订单(订单号相同)，这样的订单肯定是不能保存的，但是这里切记一点，虽然最终我们不会保存两个一样的订单，但是收到重复订单的时候你就回复成功就可以了，不要抛出异常，因为抛出异常一般会认为是消息消费失败，又会重发。这在早期我们很多同学犯这个错误，就直接将DuplicateKeyException异常抛出了(其实对于接口幂等设计时也是一样，第二次重复调用的时候你返回成功的响应就行了，如果要告诉人家是重复的也在另外的字段告诉，而不是标识成功或失败响应的地方标识，这样会让请求方的处理代码更舒服些)。
去重表
如果我们不能接受重复消息，但是我们的业务逻辑自身又没办法处理重复消息该怎么办呢？那就得借助额外的手段了。也就是引入一个去重表，我们在从消息里提取一个或多个字段作为我们去重表的唯一索引，在消息处理成功的时候我们在去重表记录，如果又接到重复的消息先查去重表，如果已经成功消费过这个消息则直接返回成功就行了。而且我们还可以根据我们对去重这个事情要求的可靠等级选择将去重表建在不同的位置：数据库或redis等。放在redis里那么去重的可靠性就是redis的可靠性，一般达到99.9%应该是没有问题的，而且放在redis里我们可以设置一个过期时间，因为重复消息这个东西一般会在一个短期时间区间内发生，比如很少几个小时后甚至是几分钟后还出现重复消息。那么如果我们对可靠性要求更高则可以将去重表放在数据库里，但使用数据库成本也更高，而且数据库一般没有自动过期机制，所以可能还需要一个自动的『垃圾回收』处理机制，将多久之前的去重表里的数据删除掉。很多mq支持幂等检查
消息顺序
消息投递的顺序是消费者关心的第二个问题。很遗憾，实现顺序消费的成本也是非常高的，所以大多数消息队列没有提供顺序消费模式。Kafka因为它独特的存储模型（partition内的消息是有序的），所以提供了顺序消费这种方式，但是也是有其他限制的。那么如果我要求顺序消费该怎么办呢？
处理方式
不处理
这个我就不啰嗦了，其实这个场景可以直接借用上面重复消息里的场景，删除缓存的消息先发的后到是没有多大关系的。
业务处理（状态机）
和上面一样，绝大多数业务逻辑是本身就是能处理顺序的。比如我们的交易系统里有很多很多状态机，状态机有严格的状态扭转流程。比如我们的支付状态机，我们从待支付->支付完成->退款中->退款完成。那假设现在我们是待支付状态，然后用户支付后又立即申请退款，那么有可能退款中的消息比支付完成的消息先到(这种几率也是非常非常低的)，这是不可以的，不满足状态机扭转条件，所以我们可以抛出异常告诉消息队列消费失败即可，等到后面支付完成的消息到达后将状态扭转为支付完成，然后等到退款中的消息到之后才将状态扭转为退款中。
额外字段（作用和状态机很像）
不要求严格有序（time）
那么如果我们的系统没有状态机这种东西，靠业务逻辑不好处理顺序该怎么办呢？那我们可以借助额外的字段来处理了。一般在数据库设计中，我们都建议每个数据库表都有这样两个字段：created_time和updated_time，也就是这条数据的创建时间戳和更新时间戳。那么如果我们不要求消息严格有序的时候就可以借助updated_time字段来控制顺序了。比如我们接到一条消息，然后需要更新数据库，然后我们发现消息中携带的时间戳比我们数据库中记录的时间戳还小呢，那这条消息我不用消费了，直接返回成功就行了。使用这种方式有两个限制：1. 不要求严格有序，只要有序就可以了，中间可能少几条的更新对业务没有影响。 2. 服务器之间的时间不能出现较大的偏差(这个通过时间同步服务一般都能保障)。
严格有序（stamp）
那么如果我们要求严格有序呢？就是中间不能出现缺口。那么这种就不能依靠时间戳了，那我们可以添加一个整型的version字段，消息里也携带了一个version字段，每次更新数据的时候我们采用这种更新方式(乐观锁): update tbl set …, version=version+1 where version=@message.version。如果这条语句没有更新成功，则返回行数就不为1，这个时候我们抛出异常让消息队列重试，等到合适的消息到来的时候就会更新成功了。使用version字段这种方式可能就要producer和consumer进行协调了(其实就是有些耦合了)，因为消息里也要携带version字段。但是设计这个version字段的时候也要一些考虑，我更建议的更新方式是update tbl set …,version=@message.newversion where version=@message.oldversion。这样如果发送消息的version因为某些原因(比如有些更新并不发送消息)没有严格递增两边也可以兼容。还有一点是，要控制consumer端数据的写入点。比如我们的处理消息消费的地方更新数据外还有另外一个地方更新数据，这个地方将version给更新了，那么就会导致producer和consumer版本不一致，最后导致怎么也同步不起来了。而producer方也要控制，比如如果我们人肉直接去表里修了数据可能就没有消息发出了。
补充
如果消息队列使用是想kafka这样带partition功能的队列结构的话，可以使用partitionkey的方式，让相同业务的消息，进到同一个partition中，partition内部是有序的，这样就可以保证你的业务是绝对有序的
有问题请留言，或者公众号回复
扫一扫
2015
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
