Kafka消息系统学习摘要

最新推荐文章于 2025-07-01 02:08:02 发布

geszjava1

最新推荐文章于 2025-07-01 02:08:02 发布

阅读量211

点赞数 1

CC 4.0 BY-SA版权

分类专栏：消息系统

本文链接：https://blog.youkuaiyun.com/geszjava1/article/details/78835199

消息系统专栏收录该内容

1 篇文章

订阅专栏

参考资料
http://blog.youkuaiyun.com/suifeng3051/article/details/48053965
http://blog.youkuaiyun.com/z69183787/article/details/68485825
http://debugo.com/kafka-params/
https://www.cnblogs.com/dongxiao-yang/p/5262860.html
http://rdcqii.hundsun.com/portal/article/709.html
http://blog.youkuaiyun.com/hzrandd/article/details/51025341

Kafka系统特点

Kafka是Linked-in开源的一个分布式消息系统，主要特点是：

高吞吐量，低响应时间
- 每秒几十万的消息量
- 最低至几毫秒的响应时间
可扩展性高
- 集群的热扩展（这点对弹性计算来说比较友好）
持久性，高可靠性
- 消息备持久化到本地
- 支持数据备份和读入
容错性
- N个Broker中可以失效N-1个Broker，集群还能正常运作
高并发
- 支持数千个节点同时读写

Kafka特性摘要

ConsumerGroup 通过ConsumerGroup，可以保证某个消息只被ConsumerGroup中的一个Consumer消费，不过由于Broker中只存储消息的Offset，而且客户端可以更改和重置Offset，所以如果Consumer处理不当的话，会导致Broker的同一条消息可能会被消费多次
消息状态 在Broker中只存储消息的Offset（指向partition中下一个要被消费的消息位置），并且offset是可以被consumer主动改变的，所以Consumer需要对消息的处理做幂等处理，这意味着需要一个分布式锁。分布式方案可以采用下列方式：
- Redis的SETNX/GETSET方案这个方案如果写的不当的话，不能保证分布式锁
- Zookeeper的Curator提供的锁功能，如果要做的更靠谱一点，还可以加上数据库的唯一键索引，这个方案唯一的问题是zookeeper集群需要另外部署，不要和kafka或者dubbo等中间件的zk集群共用，否则会引起中间件的可用性降低
消息持久性 Kafka中会把消息持久化到本地文件系统中，并且保持极高的效率。
- Kafka使用追加的形式来添加消息，且不能更改信息，是一种典型的日志处理方式，因此读写效率极高。不过由于本地文件系统的吞吐量一般，所以有可能会导致性能瓶颈，可以使用带有并行读写的Raid磁盘整列或者SSD硬盘。目前也有使用SSD+Raid的混合方式
- MMAP技术（零拷贝技术的一种）这种技术可以避免将内核态和用户态之间拷贝数据，他是使用系统中断的方式直接将硬盘数据对应到用户态的内存。因此只有io操作，没有内存复制操作，效率极高。
- 批量操作由于消息系统本质上是一个异步的系统，因此可以通过各种策略进行批量操作处理，减少调用次数，极大的提高硬盘io利用率。
消息有效期 Kafka会长久保留其中的消息，以便consumer可以多次消费，当然其中很多细节是可配置的。另外Kafka可以配置两种方式来处理过期消息：
- 按照时间消息的存活时间来处理
  log.roll.hours=1 //一小时建立一个segment log.retention.hours=2 //超过的消息进行两小时清理 log.segment.delete.delay.ms=0 //删除等待时间
- 按照时间消息的存活时间来处理
  log.retention.bytes=1000000000
批量发送 Kafka支持以消息集合为单位进行批量发送，以提高push效率
- 可以设置属性
  props.put("batch.size", 16384);//16M props.put("linger.ms", 10);//每隔10ms打包，以便client能触发批量发送这两个参数某一个生效就会执行
push-and-pull Producer——-(Push)——>Broker<—–(Pull)—–Consumer
Broker对等的集群 因为对等的集群，所以可以动态的加入Broker。不过由于加入的节点不能自动负载均衡，因此需要调用脚本kafka-reassign-partitions.sh来进行刷新。 [ Kafka扩容 ]
负载均衡 Kafka的负载均衡可以通过分区的方式来实现，这样做的好处是并行处理，坏处是消息的顺序性处理不好就会被破坏。因此在分区的时候按照一定的策略来对Producer做处理，不过Consumer这端暂时没有发现可以多线程的方式来保证消息的顺序性，这也是RocketMQ的卖点，，Kafka只能做到分区内的消息的顺序性发送。
分区机制 Kafka支持消息分区，这可以保证高并发的时候消息可以负载到给定的分区数目上。由此可以做到Broker的水平扩展。Kafka支持动态扩容，需要调用kafka-reassign-partitions.sh来进行分区的重新分配。
离线数据装载 Kafka由于对可拓展的数据持久化的支持，它也非常适合向Hadoop或者数据仓库中进行数据装载。
插件机制 现在不少活跃的社区已经开发出不少插件来拓展Kafka的功能，如用来配合Storm、Hadoop、flume相关的插件。

待修改