背景
公司由于业务爆发式增长,新上了许多业务系统,例如:本地生活、社区团购、旅投B2B、旅投B2C等系统;同时,由于业务系统越来越多,为了运营方便,把分销、营销、订单、会员等多个业务系统公共业务,抽离出一个独立平台来操作,例如:统一会员、统一订单、统一分销等系统。
需求
基于上述的背景,我负责的电商项目要与这些中台系统进行对接。在对接的过程中其中有一个需求是:
商城推送所有的商品到统一分销系统,分销系统设置相应的商品,分销系统把设置佣金的分销商品推送给商城,商城售卖该商品。
设计思路
-
定时任务:定时推送商城有状态变更的商品到统一分销中心,推送商品后,需要把推送信息记录到推送记录表中。
-
消息重试:如果出现推送失败,根据相应的商品id调用重试接口进行重试,或者等待下一次定时任务推送数据。
-
确保幂等性:为了保证每一个批次的商品数据不重复,推送数据的时候都会对商品id进行去重。
-
性能:要计算出每一分钟传送商品的极限数量,然后根据商品总数量除以每分钟的数量,算出第一次历史迁移商品的时间,并合理规划每次定时任务推送的商品数量。
可靠消息最终一致性
可靠消息最终一致性是一种分布式系统中常用的设计模式,用于在异步通信的场景下保障消息传递的可靠性和系统的最终一致性。以下是一种常见的可靠消息最终一致性方案的概述:
-
发送方将消息发送到消息队列:发送方将要发送的消息写入消息队列,例如 Apache Kafka、RabbitMQ 等。
-
接收方从消息队列中消费消息:接收方从消息队列中消费消息,处理消息并更新本地状态。
-
确认消息处理完成:接收方在处理消息后,向消息队列发送确认消息,通知消息队列消息已经处理完成。
-
消息队列持久化消息:消息队列将消息进行持久化,确保消息在存储中不会丢失。
-
异步处理消息:接收方可能会异步处理消息,例如将消息写入数据库、调用其他服务等,以完成消息的实际处理逻辑。
-
处理失败时进行重试:如果消息处理失败,接收方可以进行重试操作,例如重新发送消息到消息队列等。
-
使用定时任务进行消息回溯:如果消息处理失败或者发生异常情况,可以使用定时任务或者其他方式对消息进行回溯,重新处理失败的消息。
-
确保幂等性:在消息处理的过程中,需要确保处理逻辑是幂等的,即多次处理相同的消息产生的结果是一致的,以防止重复处理消息导致的副作用。
-
最终一致性:由于消息的处理是异步的,不同接收方可能在不同时间点处理消息,因此系统可能在瞬时出现不一致的状态,但通过消息的重试和回溯机制,最终可以保证系统的一致性。
需要注意的是,可靠消息最终一致性方案并不是适用于所有的场景,需要根据具体的业务需求和系统架构来选择合适的消息传递方式和一致性保障策略。同时,实现可靠消息最终一致性方案时,还需要考虑消息队列的选型、消息序列化、异常处理、重试策略、消息回溯机制等细节问题,以保障系统的稳定性和可靠性。
END
勇气是一个人处于逆境中的光明,赠友人。