消息中间件 | 如何保证消息不重复 | 1、消费端处理消息的业务逻辑保持幂等性或者借助redis等其他产品进行去重处理。更加通用的方法是,给你的数据增加一个版本号属性,每次更数据前,比较当前数据的版本号是否和消息中的版本号一致,如果不一致就拒绝更新数据,更新数据的同时 将版本号+1,一样可以实现幂等更新 2、保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现。 | |
RabbitMQ教程 | fanout direct topic headers | RabbitMQ教程(安装与使用详解,Spring集成)-CSDN博客 https://www.cnblogs.com/dwlsxj/p/RabbitMQ.html | |
kafka分区数和消费者数关系 | 如果你的分区数是N,那么最好线程数也保持为N,这样通常能够达到最大的吞吐量。超过N的配置只是浪费系统资源,因为多出的线程不会被分配到任何分区。 | ||
各个消息中间件的比较 | RabbitMQ 一个比较有特色的功能是支持非常灵活的路由配置,和其他消息队列不同的是,它在生产者(Producer)和队列(Queue)之间增加了一个 Exchange 模块,你可以理解为交换机。消息消费完后立即删除,不保留历史消息。 为当客户端发送一条消息的时候,Kafka 并不会立即发送出去,而是要等一会儿攒一批再发送 Kafka 的消费者读取消息是可以重演的(replayable)。 | ||
7 | 消息队列的推拉模型 | RabbitMQ消费端为推模型 Kafka为拉模型 | |
kafka丢消息 | 1、在生产阶段,你需要捕获消息发送的错误,并重发消息。事务型 Producer 能够保证将消息原子性地写入到多个分区中。这批消息要么全部写入成功,要么全部失败。另外,事务型 Producer 也不惧进程的重启。Producer 重启回来后,Kafka 依然保证它们发送消息的精确一次处理。 设置了 acks=all ,一定不会丢,要求是,你的 leader 接收到消息,所有的 follower 都同步到了消息之后,才认为本次写成功了 2、在存储阶段,你可以通过配置刷盘和复制相关的参数,让消息写入到多个副本的磁盘上,来确保消息不会因为某个 Broker 宕机或者磁盘损坏而丢失。 3、在消费阶段,你需要在处理完全部消费业务逻辑之后,再发送消费确认。 | http://svip.iocoder.cn 14 | 幂等生产者和事务生产者是一回事吗?-Kafka核心技术与实战-极客时间 05 | 如何确保消息不会丢失?-消息队列高手课-极客时间 | |
解决kafka消息堆积问题 | 消息积压处理: 1、发送端优化,增加批量和线程并发两种方式处理 2、消费端优化,优化业务逻辑代码、水平扩容增加并发并同步扩容分区数量 查看消息积压的方法: 1、消息队列内置监控,查看发送端发送消息与消费端消费消息的速度变化 2、查看日志是否有大量的消费错误 3、打印堆栈信息,查看消费线程卡点信息 | ||
kafka重平衡rebalance机制 | 触发时机: ● 组成员个数发生变化。例如有新的 consumer 实例加入该消费组或者离开组。 ● 订阅的 Topic 个数发生变化。 ● 订阅 Topic 的分区数发生变化。 | ||
rocketMQ实现精确一次投递 | |||
RabbitMQ解决消息丢失问题 | 生产者:开启生产者事务或者confirm模式 broker:开启持久化(queue持久化+消息持久化) 消费者:手动ack | ||
Kafka同步副本和异步副本 | |||
RabbitMQ的queue和kafka里的分区有什么区别 |
05-24
1680