赞
踩
为了避免有的小伙伴第一次接触顺序消费的概念,我还是先介绍一下顺序消费是个什么东西。
双十一,大量的用户抢在0点下订单。为了用户的友好体验,我们把订单生成逻辑与支付逻辑包装成一个个的MQ消息发送到Kafka中,让kafka积压部分消息,防止瞬间的流量压垮服务。
那么这里的问题就出现了,订单生成与支付都被包装成了消息。这两个消息是有严格的先后顺序的,订单生成逻辑肯定在支付之前。
那么kafka怎么保证它们的顺序呢?
不同topic:
如果支付与订单生成对应不同的topic,你只能在consumer层面去处理了。而因为consumer是分布式的,所以你为了保证顺序消费,只能找一个中间方(比如redis的队列)来维护MQ的顺序,成本太大,逻辑太恶心。
同一个topic:
如果我们把消息发送到同一个topic呢?我们知道一个topic可以对应多个分区,分别对应了多个consumer。其实与不同topic没什么本质上的差别。
同一个topic,同一个分区:
Kafka的消息在分区内是严格有序的。也就是说我们可以把同一笔订单的所有消息,按照生成的顺序一个个发送到同一个topic的同一个分区。那么consumer就能顺序的消费到同一笔订单的消息。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。