文章目录
更多相关内容可查看
Kafka和RabbitMQ什么区别
| RabbitMQ | RocketMQ | Kafka | |
|---|---|---|---|
| 公司/社区 | Rabbit | 阿里 | Apache |
| 开发语言 | Erlang | Java | Scala&Java |
| 协议支持 | AMQP，XMPP，SMTP，STOMP | 自定义协议 | 自定义协议 |
| 可用性 | 高 | 高 | 高 |
| 单机吞吐量 | 一般 | 高 | 非常高 |
| 消息延迟 | 微秒级 | 毫秒级 | 毫秒以内 |
| 消息可靠性 | 高 | 高 | 一般 |
- 底层开发语言不同 : RabbitMQ底层采用Erlang语言开发 , Kafka是基于Java和Scala语言的
- 协议支持不一样 : RabbitMQ支持AMQP和SMTP通过插件还能支持MQTT等协议 , Kafka是自定义的协议更加灵活
- Kafka的吞吐量比RabbitMQ更高 , 性能比RabbitMQ更好
- RabbitMQ基于队列存储消息和消费消息 , Kafka基于主题分区存储消息和消费消息
你们公司为什么选择Kafka ?
我们选择Kafka主要基于一下考虑 :
- Kafka的消息吞吐量比较高, 我们项目中会使用Kafka进行行为数据采集, 行为数据量是比较大的 , 所以需要吞吐量更高的消息中间件
- 我们项目中还使用了KafkaStream进行流式数据运算 , RabbitMQ没有提供流式计算的功能
- 我们团队中有其他小伙伴之前用过Kafka , 我们现在使用Kafka成本比较低, 也可以规避一些使用过程中的问题
讲一讲Kafka架构
Kafka主要包括如下部分组成 ;
- Producer：Producer 即生产者，消息的产生者，发送消息
- Broker：Broker 是 kafka 一个实例，每个服务器上有一个或多个 kafka 的实例，简单的理解就是一台 kafka 服务器，kafka cluster表示集群的意思
- Topic：消息的主题，可以理解为消息队列，kafka的数据就保存在topic。在每个 broker 上都可以创建多个 topic 。
- Partition：Topic的分区，每个 topic 可以有多个分区，分区的作用是做负载，提高 kafka 的吞吐量。同一个 topic 在不同的分区的数据是不重复的，partition 的表现形式就是一个一个的文件夹!
- Replication：每一个分区都有多个副本，副本的作用是做备胎，主分区(Leader)会将数据同步到从分区(Follower)。当主分区(Leader)故障的时候会选择一个备胎(Follower)上位，成为 Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本
- Message：每一条发送的消息主体。
- Consumer：消费者，即消息的消费方，是消息的出口。
- Consumer Group：我们可以将多个消费者组成一个消费者组，在 kafka 的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量!
- Zookeeper：kafka 集群依赖 zookeeper 来保存集群的的元信息，来保证系统的可用性。
你们项目中哪里用到了Kafka?
采购合同处理工作台
数据源/生产者：可以是走销售合同的（购销一体），也可以直接走采购合同的（购销分离），将这些数据分别加载到Kafka订单主题中
消费者：然后这些订单可以入仓，可以发运，可以实时的消费订单数据
为什么会选择使用Kafka? 有什么好处 ?
选择使用Kafka是因为Kafka作为中间件他的吞吐量比较高 , 我们的系统中主要使用Kafka来处理一些用户的行为数据 , 用户行为数据用户操作成本低 , 数据量比较大 , 需要有更高的吞吐量支持 , 并且我们在项目中需要实现根据用户行为的实时推荐 , 运营端后台管理系统首页看板数据的实体展示 !
使用Kafka有很多好处：
- ** 吞吐量提升：无需等待订阅者处理完成，响应更快速**
- 故障隔离：服务没有直接调用，不存在级联失败问题
- 调用间没有阻塞，不会造成无效的资源占用
- 耦合度极低，每个服务都可以灵活插拔，可替换
- 流量削峰：不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件
使用Kafka也有很多缺点：
- 架构复杂了，业务没有明显的流程线，不好管理
- 需要依赖于Broker的可靠、安全、性能
使用Kafka如何保证消息不丢失 ?
使用Kafka在消息的收发过程都会出现消息丢失 , Kafka分别给出了解决方案
- 生产者发送消息到Brocker丢失
设置同步发送和异步发送
- 同步发送可以通过get()获取到消息的发送结果 , 阻塞方案, 效率比较低
- 异步发送可以通过回调获取到消息的发送接口 , 非阻塞方案, 效率较高 , 可能会出现回调丢失
- 设置消息发送失败的重试次数, 设置为一个很大的值, 发送失败不断重试
- 消息在Brocker中存储丢失
Kafka提供了分区的备份机制 , 可以为每个分区设置多个副本 , 主分区服务器宕机, 副本分区还有完整数据
主分区数据同步到副本分区之前, 主分区宕机也有可能会出现消息丢失问题 , 解决方案就是设置消息确认的ACKS
| 确认机制 | 说明 |
|---|---|
| acks=0 | 生产者在成功写入消息之前不会等待任何来自服务器的响应,消息有丢失的风险，但是速度最快 |
| acks=1（默认值） | 只要集群首领节点收到消息，生产者就会收到一个来自服务器的成功响应 |
| acks=all | 只有当所有参与赋值的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应 |
- 消费者从Brocker接收消息丢失
消费者是通过offset来定位消费数据的 , 当消费者出现故障之后会触发重平衡, 会为消费者组中的消费者重新分配消费分区, 正常情况下是没有问题的 , 这也是Kafka提供的消费保障机制
但是在重平衡的过程中 , 因为Kafka默认子每隔5S自动提交偏移量 , 那么就有可能会出现消息丢失和重复消费问题
- 如果提交偏移量小于客户端处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息就会被重复处理。
- 如果提交的偏移量大于客户端的最后一个消息的偏移量，那么处于两个偏移量之间的消息将会丢失。
解决方案有二种 :
- 设置更小的自动提交偏移量的周期 , 周期越小出现问题的概率也就越小, 对消费者性能和服务器压力的影响就越大(缓解方案,不能从根本上解决问题)
- 消费完毕手动提交偏移量
- 同步提交 : 会阻塞, 效率低 , 但是会重试 , 直到成功为止
- 异步提交 : 不会阻塞 , 效率高 , 但是不会重试 , 可能会出现提交失败问题
- 同步异步结合
通过Kafka本身所提供的机制基本上已经可以保证消息不丢失 , 但是因为一些特殊的原因还是会发送消息丢失问题 , 例如 : 回调丢失 , 系统宕机, 磁盘损坏等 , 这种概率很小 , 但是如果想规避这些问题 , 进一步提高消息发送的成功率, 也可以通过程序自己进行控制
设计一个消息状态表 , 主要包含 : 消息id , 消息内容 , 主题 , 发送时间, 签收状态等字段 , 发送方业务执行完毕之后 , 向消息状态表保存一条消息记录, 消息状态为未签收 , 之后再向Kafka发送消息 , 消费方接收消息消费完毕之后 , 向发送方发送一条签收消息 , 发送方接收到签收消息之后 , 修改消息状态表中的消息状态为已签收 ! 之后通过定时任务扫描消息状态表中这些未签收的消息 , 重新发送消息, 直到成功为止 , 对于已经完成消费的消息定时清理即可 !
消息的重复消费问题如何解决的 ?
消费者是通过offset来定位消费数据的 , 当消费者出现故障之后会触发重平衡, 会为消费者组中的消费者重新分配消费分区, 正常情况下是没有问题的 , 这也是Kafka提供的消费保障机制
但是在重平衡的过程中 , 因为Kafka默认子每隔5S自动提交偏移量 , 那么就有可能会出现消息丢失和重复消费问题
如果提交偏移量小于客户端处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息就会被重复处理。
解决方案有二种 :
- 设置更小的自动提交偏移量的周期 , 周期越小出现问题的概率也就越小, 对消费者性能和服务器压力的影响就越大(缓解方案,不能从根本上解决问题)
- 消费完毕手动提交偏移量
- 同步提交 : 会阻塞, 效率低 , 但是会重试 , 直到成功为止
- 异步提交 : 不会阻塞 , 效率高 , 但是不会重试 , 可能会出现提交失败问题
- 同步异步结合
基于上面的操作如果因为网络原因, 服务器原因出现偏移量提交失败的情况 , 还是会出现重复消费 ,** 具体的解决方案其实非常简单, 为每条消息设置一个唯一的标识id , 将已经消费的消息记录保存起来 , 后期再进行消费的时候判断是否已经消费过即可 , 如果已经消费过则不消费 , 如果没有消费过则正常消费**
Kafka如何保证消费的顺序性 ?
topic分区中消息只能由消费者组中的唯一一个消费者处理，所以消息肯定是按照先后顺序进行处理的。
但是它也仅仅是保证Topic的一个分区顺序处理，不能保证跨分区的消息先后处理顺序。
所以，如果你想要顺序的处理Topic的所有消息，那就只提供一个分区。只提供一个分区又会严重影响Kafka消息的吞吐量
解决方案 :
- Kafka中发送消息可以手动指定分区也可以通过Key将消息路由到分区 , 可以将需要顺序执行的一批次消息都发送到同一个分区之中 , 这样消费者从分区消费数据就有序了
- 使用内存队列 , 只提供一个分区，消费者不消费数据 , 将需要保证顺序性的一批次消息保存到同一个内存队列 , 然后分发给底层不同的worker来处理
Kafka的高可用机制有了解过嘛 ?
Kafka作为一款使用比较广泛的消息中间件产品, 本身也提供了一些机制去实现高可用 , 主要包括 :
- Kafka 集群 : 通过集群模式, 保证Brocker的高可用
- 分区备份机制 : Kafka会为每一个分区设置副本 , 可以手动指定副本数量 , 这些副本会分配到Kafka的不同的Brocker上存储 , 这样可以保证Kafka数据高可用
- 重平衡 : 当消费者组中重新加入消费者 , 或者消费者组中有消费者宕机 , 这个时候Kafka会为消费者组中的消费者从新分配消费分区的过程就是再均衡 , 通过重平衡消实现了消费者的高可用
Kafka实现高性能的设计有了解过嘛 ?
Kafka 高性能，是多方面协同的结果，包括宏观架构、分布式存储、ISR 数据同步、以及高效的利用磁盘、操作系统特性等。总结一下其实就是六个要点
- 顺序读写
- 消息分区
- 页缓存
- 零拷贝
- 消息压缩
- 分批发送
Kafka数据清理机制了解过嘛 ?
Kafka中的数据保存在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储
日志是分段存储的，一方面能够减少单个文件内容的大小，另一方面，方便kafka 进行日志清理。
日志的清理策略有两个：
- 根据消息的保留时间，当消息在kafka中保存的时间超过了指定的时间，就会触发清理过程
log.retention.hours=168默认7天 - 根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。
kafka会启动一个后台线程，定期检查是否存在可以删除的消息。
log.retention.bytes=1073741824默认1G
通过上面这两个参数来设置，当其中任意一个达到要求，都会执行删除。
使用Kafka如何实现点对点消息和发布订阅消息
Kafka的点对点消息和发布订阅消息是通过消费者组实现的 , 消费者组（Consumer Group）是由一个或多个消费者实例（Consumer Instance）组成的群组，具有可扩展性和可容错性的一种机制。
- 点对点模式 : 一个消费者对应一条消息
- 发布-订阅模式 : 让多个消费者处于不同的组 , 这样不同组中的消费者都能消费同一个分区的数据就是发布-订阅模式
kfk你知道怎么提高消费速度
- 并行消费： 如果消息队列支持并行消费，可以增加消费者实例的数量，并将负载均衡到多个消费者上，以加快消息处理速度。
- 批量处理： 将多个消息批量处理，而不是逐条处理。这可以减少网络开销和系统调用次数，提高处理效率。
- 异步处理： 将消费者与生产者解耦，采用异步处理方式。消费者可以将消息放入内存队列中，然后由异步处理器负责处理，从而提高整体吞吐量。
- 优化消费者代码： 优化消费者代码，避免不必要的计算、IO 操作或者同步阻塞。确保消费者代码的效率和性能。
- 增加分区： 如果消息队列支持分区，可以增加分区的数量，以分散消息的负载并提高并行处理能力。
- 调整配置： 根据系统负载和性能需求，调整消息队列和消费者的配置参数，如线程池大小、最大连接数等。
- 监控和优化： 使用监控工具监视系统性能，并根据监控结果进行优化，及时发现并解决潜在的性能瓶颈。
kfk为什么这么快
- 分布式架构： Kafka 是一个分布式系统，它可以水平扩展到多个节点上。这意味着可以通过增加更多的节点来增加整个系统的吞吐量和容量，从而实现高性能。
- 分区和副本： Kafka 的主题（topic）可以分为多个分区（partition），每个分区可以在不同的节点上进行读写操作，实现了数据的并行处理。此外，Kafka 还支持副本机制，可以将数据复制到多个节点上，提高了数据的可靠性和容错性。
- 零拷贝技术： Kafka 使用零拷贝（Zero-Copy）技术来优化数据的传输过程。在数据从生产者到消费者的传输过程中，避免了数据在内存中的多次复制，减少了CPU和内存的开销，提高了数据传输的效率。
- 顺序读写： Kafka 的设计着重于支持大规模数据的顺序读写。它通过顺序读写磁盘上的日志文件（log segment），并且允许消息在分区内保持有序，从而最大程度地利用了磁盘和缓存的性能优势。
- 零等待设计： Kafka 的设计目标之一是尽量减少对磁盘的等待时间。它采用了一种零等待的设计策略，将数据异步写入磁盘，并通过内存缓冲区和批处理机制来提高写入和读取的效率。
- 可配置性： Kafka 提供了丰富的配置选项，可以根据实际需求调整各种参数，如缓冲区大小、压缩算法、数据持久化方式等，从而优化系统的性能和稳定性。