im 推消息, 量小, 所以还不想做路由中心. 所以采用广播.

@j2gg0s 业务场景你都不清楚你瞎 bb 个毛.

@yangbonis 是需要同一个服务不同实例都收到, 你说的这个大概是不同服务.

@mosesyou 我们将 docker 镜像上传到云上, 然后后续的流程我得研究一下, 问一下我们负责这一块的同事, 如果可行的话这得确是一个好办法. 多谢.

@zardly666 这个倒是可以做, 类似 snowflake 算法 workid 的生成. 但相对较麻烦, 老哥但还有没有简单点的解决办法啊 😿
@wisej consumergroup 堆积就是监控上看着有点慌. 磁盘会占用.
@sonice 额, 我们多个实例发布的时候重启, 那就会一次性有多个 old consumerGroup, 监控上看着蛇皮的很, 比较难搞.
@kifile 是, 这是一种方案, 但开发没有 KafkaAdmin 的权限, 所以代码里删除不掉, 只能手动了.... 哈哈


谢谢各位, 期待更好的方案 🐶

@mosesyou 这个业务场景需要同一个服务里的不同实例全都消费到每个 MQ

@SingeeKing 都是同一个服务, 不同实例,这个不方便给每个实例加环境变量, 哈哈

@hustmisa 可以丢弃, 因为应用上有 ack 超时重试机制, 要命的是重启后老的 groupId 不会自动心跳超时消失, 会在监控上看到消息不断堆积. 其实我想实现的就是 rocketmq 的广播的功能.. 但我们使用 kafka.

@useben 这个在固定机器上是可以的, 但我们这里 docker 镜像每次都不知道到哪个机器上了. 😢

你要用额外的 jar 包才能用 servlet 啊. 那就是 java ee 的内容

不能..

6 个月肯定不打折才行.
我很少遇到试用期要打折的公司了...

场景简单的话 server sent events 应该是简单靠谱的方案. 好像 twitter 都在用.

笔误, 前几年.

我前几天疼的时候, 10 多分钟就疼死了.. 去医院躺着碎结石, 碎着碎着躺上面就睡着了, 睡醒了就碎完了. 碎的过程一点都不疼..

去医院吧, 分分钟就碎了..

@amiwrong123 就我了解来说, 你的理解是对的, 这也是一个捎带同步的技巧..

你可以去看 happens before 规则里对 volatile 变量部分的描述.

https://blog.csdn.net/ITer_ZC/article/details/40744485


可以看看这个.