做网站属于什么技术,辽宁省建设工程信息网招标规定,网络营销推广策划案,嵌入式软件开发公司文章目录 什么是消息乱序消费了#xff1f;顺序生产#xff0c;顺序存储#xff0c;顺序消费如何解决乱序数据库乐观锁是怎么解决这个乱序问题吗 保证消息顺序消费两种方案固定分区方案乐观锁实现方案 前几天刷着视频看见评论区有大佬问了这个问题#xff1a;你们的kafka消… 文章目录 什么是消息乱序消费了顺序生产顺序存储顺序消费如何解决乱序数据库乐观锁是怎么解决这个乱序问题吗 保证消息顺序消费两种方案固定分区方案乐观锁实现方案 前几天刷着视频看见评论区有大佬问了这个问题你们的kafka消息里会有乱序消费的情况吗如果有是怎么解决的了以下是我的理解 什么是消息乱序消费了
消息乱序消费一般指我们消费者应用程序不按照上游系统 业务发生的顺序进行了业务消息的颠倒处理最终导致消费业务出错。 举个例子
顺序生产顺序存储顺序消费
kafka一般建议同一个业务属性数据都往一个分区上发送而kafka的一个分区只能被一个消费者实例消费不能被多个消费者实例消费。
也就是说在生产端如果能保证 把一个业务属性的消息按顺序放入同一个分区那么kakfa中间件的broker也是顺序存储顺序给到消费者的。而kafka的一个分区只能被一个消费者消费也就不存在多线程并发消费导致的顺序问题了。
比如上面的例子不就是两个消费者拉取了不同分区上的数据导致消息乱序处理最终数据不一致。同一个促销数据都往一个分区上发送就不会存在这样的乱序问题了。 能给一个 kafka 指定 发送到固定分区的代码吗 有的只需要一行代码
KafkaProducer.send(new ProducerRecord[String,String](topic,key,msg),new Callback(){} )topic主题这个玩消息的都知道不解释了 key: 这个是指定发送到固定分区的关键。一般填写订单号或者促销ID。kafka在计算消息该发往那个分区时会默认使用hash算法把相同的key发送到固定的分区上 msg: 具体消息内容
订单算佣业务了也是利用kafka监听订单数据变化但是为什么没有使用固定分区方案了
把订单支付消息和订单退款消息拆分为了两个topic这个从使用固定分区方案的前提里就否定了我们不能使用此方案。
如何解决乱序
主要是根据自身业务实际特性使用了数据库乐观锁的思想解决先发后至后发先至这种数据乱序问题。
我们算佣业务主要关注订单的两个状态一个是订单支付状态一个是订单退款状态。 订单退款发生时间肯定是在订单支付后而上游订单业务是能保证这两个业务在时间发生上的前后顺序的即订单的支付时间肯定是早于订单退款时间。所以主要是利用订单ID订单更新时间戳做为数据库佣金表的更新条件进行数据的乱序处理。
数据库乐观锁是怎么解决这个乱序问题吗
当佣金表里订单数据更新时间大于更新条件时间 就放弃本次更新表明消息数据是个老数据即查询时不加锁
而小于更新条件时间的表明是个订单新数据进行数据更新。即在更新时 利用数据库的行锁来保证并发更新时的情况。即真实发生修改时加锁。
我们算佣业务其实是只关注佣金的最终状态不关注中间状态所以能用这种方式保证算佣数据的最终一致性而不用太关注订单的中间状态变化导致佣金的中间变化。
保证消息顺序消费两种方案
固定分区方案
1、生产端指定同一类业务消息往同一个分区发送。比如指定发送key为订单号这样同一个订单号的消息都会发送同一个分区 2、消费端单线程进行消费
乐观锁实现方案
如果上游不能保证生产的顺序可让上游加上数据更新时间利用唯一ID数据更新时间乐观锁思想保证业务数据处理的最终一致性。
