在现代分布式系统中,消息中间件被广泛应用以实现异步化、解耦和削峰等功能,消息的可靠投递(即“至少一次”语义)往往会导致消息重复投递的问题,为了解决这一问题,应用程序需要自行实现幂等性,确保每条消息仅被处理一次,本文将探讨如何通过MapReduce和消息幂等机制来实现消息去重。
一、消息重复的原因
消息中间件如RocketMQ、RabbitMQ等通常保证消息“至少一次”投递,这意味着如果消费者在处理消息时出现故障或崩溃,消息中间件会重新投递该消息,这种机制保证了消息不会丢失,但也带来了消息重复的问题,当消费者A成功接收并开始处理消息M时,若此时程序重启,消息中间件会认为消息M未被成功消费,从而再次投递。
二、简单的消息去重方案
假设业务逻辑是插入订单表数据并更新库存:
INSERT INTO t_order VALUES ...; UPDATE t_inv SET count = count 1 WHERE good_id = 'good123';
要实现幂等性,可以在插入前检查订单是否已存在:
SELECT * FROM t_order WHERE order_no = 'order123'; if(order != null) { return ; // 消息重复,直接返回 }
这种方法在大多数情况下有效,但在并发场景下可能会失效,如果两条消息在短时间内到达,第一条消息还未完成消费逻辑,第二条消息就可能穿透检查机制,导致重复消费。
三、并发场景下的去重方案
在并发场景下,可以使用事务和行锁来保证幂等性:
SELECT * FROM t_order WHERE order_no = 'THIS_ORDER_NO' FOR UPDATE; if(order.status != null) { return ; // 消息重复,直接返回 }
此方法通过行锁防止并发操作,但会降低系统的并发度,更高级的解决方案包括使用乐观锁,但这需要更复杂的代码开发和库表设计。
四、基于数据库事务的Exactly Once语义
针对基于数据库事务的消费逻辑,可以通过增加一个消息消费记录表来实现Exactly Once语义,具体步骤如下:
1、开启事务。
2、将消息插入到消息消费记录表,处理好主键冲突问题。
3、执行原消费逻辑(如更新订单状态)。
4、提交事务。
这样,即使服务在事务提交前崩溃,消息仍会被视为已消费,如果事务未提交,消息将继续投递,直到成功,这种方法依赖于关系型数据库的事务特性,适用于需要强一致性的业务场景。
五、通用的消息幂等处理工具类
为了简化消息幂等处理,可以抽象出一个通用的工具类,以下是一个示例:
public class MessageDeDuplicator { private Map<String, String> messageStatusMap = new ConcurrentHashMap<>(); public boolean isMessageProcessed(String messageId) { return messageStatusMap.containsKey(messageId); } public void markMessageAsProcessed(String messageId) { messageStatusMap.put(messageId, "PROCESSED"); } }
在消费逻辑中,首先检查消息是否已处理,再进行实际的业务逻辑处理:
public void consume(String messageId, MessageConsumer consumer) { if (messageDeDuplicator.isMessageProcessed(messageId)) { return; // 消息重复,直接返回 } try { consumer.consume(messageId); messageDeDuplicator.markMessageAsProcessed(messageId); } catch (Exception e) { // 处理异常,如重新投递消息或记录日志 } }
这种方法通过内存中的哈希表实现快速去重,适用于对性能要求较高的场景,但需要注意,内存中的数据在系统重启后会丢失,因此需要结合持久化存储方案,如Redis或数据库。
通过MapReduce和消息幂等机制,可以实现高效的消息去重,不同的业务场景可以选择适合的去重策略,如简单的数据库查询、事务控制或通用的工具类,随着分布式系统和消息中间件技术的发展,更多高效、可靠的去重方案将被提出和应用。
FAQs
Q1: 为什么消息中间件不能保证消息不重复?
A1: 消息中间件为了保证消息不丢失,通常会采用“至少一次”的投递语义,这意味着只要生产者成功发送了消息,消息中间件就会确保消息至少被消费者处理一次,这种机制导致了消息重复的可能性。
Q2: 如何在高并发场景下实现消息幂等?
A2: 在高并发场景下,可以通过事务和行锁来保证消息幂等,使用SELECT ... FOR UPDATE
语句锁定记录,确保同一时间只有一个消费者能处理该消息,还可以采用乐观锁机制,通过版本号或时间戳判断消息是否已被处理。
小伙伴们,上文介绍了“mapreduce去重源码_通过消息幂等实现消息去重”的内容,你了解清楚吗?希望对你有所帮助,任何问题可以给我留言,让我们下期再见吧。
原创文章,作者:未希,如若转载,请注明出处:https://www.kdun.com/ask/1335246.html
本网站发布或转载的文章及图片均来自网络,其原创性以及文中表达的观点和判断不代表本网站。如有问题,请联系客服处理。
发表回复