![]() | 1 Trim21 2024-08-27 22:48:56 +08:00 只用一个节点消费? |
![]() | 2 kechx 2024-08-27 22:51:04 +08:00 进队列前对任务进行一个 hash ,有时序性的扔在一起 |
![]() | 3 7911364440 2024-08-27 22:51:43 +08:00 给任务加个字增 id ,每个消费服务执行任务前校验一下顺序 |
![]() | 4 crysislinux 2024-08-27 22:55:34 +08:00 via Android kafka 一个分区不就是顺序执行的么。你还想要啥 |
5 MeiJiayun 2024-08-27 23:02:18 +08:00 via iPhone 指定 key ,key 相同会推送到相同分区,同一分区的消息有顺序 |
6 dddd1919 2024-08-27 23:08:55 +08:00 给串行的每个节点定义一个 topic 和 topic 的串行顺序,每个节点执行器执行完成后把消息推送到下一个 topic |
7 kur0d3s 2024-08-28 08:56:01 +08:00 要求单实例顺序执行了, 那消费者多实例的意义是啥... |
![]() | 8 Wh1t3zZ 2024-08-28 09:04:05 +08:00 "多个节点排队消费,第一个节点拿到消息后,如果没处理完,其他节点不能继续消费" 没看懂多个节点消费的意义是什么 |
10 NoKey OP @crysislinux 消费节点是多个,我测试的,即便多个消费者在一个消费者组,第一个消费者拿到消息处理的过程中,第二条消息到来,也会被消费,这个时候,第一条消息和第二条消息就是并行在处理了 |
![]() | 12 zt5b79527 2024-08-28 09:14:00 +08:00 ![]() 单个实例去消费不就完了,如果必须是多个实例,就去抢分布式锁,拿到锁的才能去消费 |
![]() | 13 frank1256 2024-08-28 09:18:27 +08:00 多节点抢锁,抢不到锁的 commit offset 要回退的,因为你第二个节点虽然拿不到锁,但已经消费到数据了 |
![]() | 14 crysislinux 2024-08-28 09:24:02 +08:00 via Android @NoKey 消费者组和分区不是一个概念吧,你搞错了。 |
![]() | 15 echoZero 2024-08-28 09:35:08 +08:00 放同一个分区。之所有会出现多条消息并行处理,因为是批量拉取消费消息,这个是你的消费逻辑问题,看一下是不是消费逻辑并发处理拉取的消息了 |
![]() | 16 zdt3476 2024-08-28 09:50:31 +08:00 你给这个 topic 只分配一个 partition 就好了,这样多消费者就不起作用了 |
![]() | 17 awalkingman 2024-08-28 10:00:48 +08:00 @zt5b79527 正解 |
![]() | 18 MoYi123 2024-08-28 10:14:46 +08:00 kafka 在这起什么作用? rpc 调用就会导致任务丢失了? |
![]() | 19 Marinaaaa 2024-08-28 10:33:00 +08:00 ![]() 1. topic 单分区 ,多消费者, 这样再多消费者也就只有一个在工作。 2. 多分区,多消费者,任务投递的指定 key ,这样同样 key 的任务在同一个分区,也是被顺序消费的。 3. 分布式锁 , 抢到锁的去消费 |
20 NoKey OP @Marinaaaa 我现在用的是第二种,指定生成者往指定分区发消息,消费者就算只有一个,也有问题:我在消费方法中加了 sleep 来模拟处理数据耗时,第一条消息还在 sleep 的时候,第二条消息到来,也会进入处理阶段,也就是消费者相当于多线程的,不断的在消费。不知道这种情况如何处理 |
21 wwhontheway 2024-08-28 10:56:39 +08:00 没看懂,你说的串行是什么? task 按顺序一个一个消费? ------------------------ 就是说,多个节点排队消费,第一个节点拿到消息后,如果没处理完,其他节点不能继续消费 ------------------------ 这又是啥?这不是串行呀。这是 task lock 保证的 |
![]() | 22 zhhmax 2024-08-28 11:17:37 +08:00 @NoKey #20 你手动提交每条消息的 offset ,然后把消费的方法改成阻塞式,这样每次消费完再手动提交之后才会消费下一条消息。 |
23 NoKey OP @wwhontheway 就是想知道 springboot+kafka ,能不能做成一个简单的串行处理队列 |
24 wwhontheway 2024-08-28 11:59:11 +08:00 @NoKey 那就是单实例呀,多实例串行,工作只有一个,其他实例闲着,何必多实例? |
![]() | 25 R4rvZ6agNVWr56V0 2024-08-28 12:23:32 +08:00 创建一个专门用于处理这些串行任务的 Kafka 主题,然后: 使用单一消费者实例,属于自己的消费者组 使用 TransactionalId 来跟踪每个任务的进度 实现一个轮询机制,定期检查任务是否已经完成,如果完成则提交 offset 并删除该任务 可以考虑使用 Kafka Streams 或 KSQL 来简化实现这个业务 |
26 csys 2024-08-28 13:09:03 +08:00 你手动指定分区或者使用相同的消息 key ,这样所有消息都会被发送到同一个分区,而一个分区只会被分配给一个消费者,相当于你只有一个订阅到此分区的消费实例在消费这些消息,其它消费者都在空跑 |
27 guojiawei0203 2024-08-28 13:16:03 +08:00 没啥量直接单分区,多分区根据 key 去 hash |
28 wysnxzm 2024-08-28 13:47:48 +08:00 将任务分组保证同一组的任务被同一个消费者消费,该消费者保证自身所有任务串行执行 这样可以在多消费者的同时保证串行 |
![]() | 29 vaynecv 2024-08-28 14:47:32 +08:00 启动的时候指定某一个实例进行消费,其他示例忽略此消息 |
30 night98 2024-08-28 18:49:07 +08:00 你是想 1 到 10 总共十条消息,无论如何都要保证按照 1 到 10 按顺序消费,不能出现 1 ,2 同时消费,然后再 3 ,4 同时消费的情况,是这个业务逻辑是吗? spring kafka 限制单次消费拉取的数据量,然后就是楼上那些说的,一起弄一下就 ok 了 实际逻辑就是一次必须只能有一个人持有消息,持有后必须按顺序消费。 |
31 tangproxy 214 天前 via Android @vaynecv 赞同,后台服务多实例,初始化的时候通过分布式锁确定订阅 topic 的实例。然后,补充一点,防止这个订阅了 topic 的实例宕机,后台其他实例监听分布式锁过期的订阅,redission 那个,再进行重新抢锁,订阅 topic 。如果过期时间比较长(默认 10 分钟)无法接受的话,可以再加个补偿,举个例子,管理后台服务的程序(运管)可能最先知道后台实例挂了,通知其他实例这个情况。 |