Kafka与其他三个消息系统关键区别是
- kafka是持久化日志,这些日志可以被重复读取和无限期保留
- kafka是分布式系统,它以集群方式运行,可以灵活伸缩
- kafka支持实时的流式处理
Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别
ActiveMQ没经过大规模吞吐量验证,社区也不活跃。RabbitMQ是开源的,有稳定的支持,社区活跃度高,RocketMQ阿里出品,有可能会突然黄掉。所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。
为什么要使用消息队列
如果能结合自己做过的项目说明,那是最好的。
- 解耦。
- 削峰
- 异步
消息队列缺点
- 系统可用性减低。本来只需要维护业务系统,现在还需要维护消息系统
- 复杂度上升。通上
- 一致性问题。可能会出现各个业务系统数据不一致的情况。
消息重复原因
- 生产者发送数据后,消息系统写入消息后,由于宕机或者返回超时等问题,导致生产者重试发送。
- 消费者获取到消息后,由于消费者宕机或者网络延迟,导致消息系统没有收到消息响应,重复发送。
如何解决消息重复。即接口的幂等性
参考https://blog.csdn.net/zgsxhdzxl/article/details/104414475 分布式系统的接口幂等性设计
消息的可靠性传输
- activeMQ
- 生产者
应该采用持久化方式或者事务方式
- 消费者
activemq有四种确认机制
- AUTO_ACKNOWLEDGE = 1 自动确认
- CLIENT_ACKNOWLEDGE = 2 客户端手动确认
- DUPS_OK_ACKNOWLEDGE = 3 自动批量确认
- SESSION_TRANSACTED = 0 事务提交并确认
AUTO_ACKNOWLEDGE
自动确认
“同步”(receive)方法返回message给消息时会立即确认。
在"异步"(messageListener)方式中,将会首先调用listener.onMessage(message),如果onMessage方法正常结束,消息将会正常确认。如果onMessage方法异常,将导致消费者要求ActiveMQ重发消息。
CLIENT_ACKNOWLEDGE :
客户端手动确认,这就意味着AcitveMQ将不会“自作主张”的为你ACK任何消息,开发者需要自己择机确认。
我们可以在当前消息处理成功之后,立即调用message.acknowledge()方法来"逐个"确认消息,这样可以尽可能的减少因网络故障而导致消息重发的个数;当然也可以处理多条消息之后,间歇性的调用acknowledge方法来一次确认多条消息,减少ack的次数来提升consumer的效率,不过需要自行权衡。
DUPS_OK_ACKNOWLEDGE
类似于AUTO_ACK确认机制,为自动批量确认而生,而且具有“延迟”确认的特点,ActiveMQ会根据内部算法,在收到一定数量的消息自动进行确认。在此模式下,可能会出现重复消息,什么时候?当consumer故障重启后,那些尚未ACK的消息会重新发送过来。
SESSION_TRANSACTED
当session使用事务时,就是使用此模式。当决定事务中的消息可以确认时,必须调用session.commit()方法,commit方法将会导致当前session的事务中所有消息立即被确认。在事务开始之后的任何时机调用rollback(),意味着当前事务的结束,事务中所有的消息都将被重发。当然在commit之前抛出异常,也会导致事务的rollback。
- kafka
- 生产者
如果设置了ack为all,那么一定不会丢失数据
- kafka方面
需要设置分区副本至少为2.
min.insync.replicas参数:这个值必须大于1,这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系。
ack为all,这个是要求所有消息必须写入所有副本才算写入成功
retries=MAX,这个要求无限重试
- 消费者方面
关闭自动提交偏移量方式、消费者实现幂等操作。
消息的顺序执行
严格来说,消息系统不应该有顺序依赖。最简单的实现方法就是生产者-消息系统-消费者是一对一关系
- activemq
- 通过高级特性consumer独有消费者。
当接收消息的时候,有多个独占着消费者的时候,只有一个消费者可以收到消息。。这样会导致其它消费者被闲置。
- 使用messageGroups
Message Groups特性是一种负载均衡的机制。在一个消息被分发到consumer之前,broker首先检查消息JMSXGroupID属性。如果存在,那么broker会检查是否有某个consumer拥有这个message group。如果没有,那么broker会选择一个consumer,并将它关联到这个message group。此后,这个consumer会接收这个message group的所有消息,直到:Consumer被关闭。Message group被关闭,通过发送一个消息,并设置这个消息的JMSXGroupSeq为-1
- kafka
一个分区一个主题一个消费者
如果leader crash时,ISR为空怎么办
kafka有一个配置参数unclean.leader.election,默认为true,允许不同步副本成为leader,这样会导致消息不一致的情况发生。如果为false,则会导致可用性减低。
kafka生产者如何优化写入速度
- 多线程写入
- 提高batch.size
- 添加分区
- 根据实际情况修改a'cks值
- 调大缓冲区大小
传统消息传递方式
- 点对点模式
- 广播模式
kafka中zookeeper作用
zookeeper用于生产者节点的注册、leader的选举、心跳检测、分布式同步、集群、分区、偏移量信息的存储等。目前是不能脱离zookeeper的。
数据传输的事务定义
- 最多一次。消息不会重复发送,有可能一次也不发
- 最少一次。消息不会漏发,但有可能重复发送
- 精确的一次。消息肯定会发送一次并且仅仅发送一次。
kafka创建消息如何将不同的分区放置到不同的broker中
第一个分区的第一个副本位置是随机从列表中选取的。其他的副本位置就是从第1个分区之后移动。例如第一个分区在broker3上,那么第二个副本就在broker4上,第三个副本就在broker5上。