前言
- 介绍kafka的基本特征及概念。
- 结合应用需求设计场景,介绍MQ的选型,及kafka实际应用与生产监控技巧。
kafka主要特征介绍
Kafka is a distributed,partitioned,replicated commit logservice。它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类,发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)成为broker。无论是kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。
1. Producers
Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition。
2. Consumers
本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费.
如果所有的consumer都具有相同的group,这种情况和queue模式很像;消息将会在consumers之间负载均衡.
如果所有的consumer都具有不同的group,那这就是"发布-订阅";消息将会广播给所有的消费者.
3. topic
一个Topic可以认为是一类消息,每个topic将被分成多个partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部,每条消息在文件中的位置称为offset(偏移量),offset为一个long型数字,它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset,因为在kafka中几乎不允许对消息进行随机读写。offset是存放在zookeeper中。
kafka-topics.bat –create –zookeeper localhost:2181 –replication-factor 1 –partitions 3 –topic page_visits
replication-factor 节点 目录下执行如下命令(replication-factor设置为 kafka 节点数):
partitions –指的分片的数量
上面这条建立topic的命令,创建一个3个partition,只放在一个replication节点下的topic。
3. partition
4. Distribution
关于kafka特征介绍可以更多参考:
http://www.cnblogs.com/likehua/p/3999538.html
订单快照日志分析
1. 需求
希望从网关获取订单信息的快照,采用异步的形式发送到后端,来比较获取客户端每次订单操作后,关键要素的前后变化对照。形成订单生命周期内的完整日志信息。展示在订单详情中。
2. 第一版设计
结合kafka的有序性,高可用性,没重复消息特征,我们采用kafka来做异步缓冲。把订单快照先保存到mongodb中,然后再采用quartz定时分析。采用这个方案随着数据量越来越大,quartz每次批量分析数据容易失败。二,业务即时展示快照结果的需求越强烈。
3. 第二版设计
在kafka的cunsumer时,直接做快照分析。因为kafka的有序性让我们快照比较得以实施。当获取消息时,在从mongodb中获取它前一步快照,再进行比较分析。这个方案担心cunsumer的消费速度,broker是否会有大量消息积压。
./kafka-consumer-groups.sh –zookeeper localhost:2181/kafka –describe –group group-1
通过上面命令指定自己的分组,topic的消息记录结果如下:
GROUP | TOPIC | PID | OFFSET | LOGSIZE | LAG |
---|---|---|---|---|---|
消费者组 | 话题id | 分区id | 当前已消费的条数 | 总条数 | 未消费的条数 |
在生产环境,应用能够稳定的消费,比第一种方案更稳定,客户体验也更加及时。