kafka实战案例分析总结

前言

1. 介绍kafka的基本特征及概念。
2. 结合应用需求设计场景，介绍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 当前已消费的条数 总条数 未消费的条数

在生产环境，应用能够稳定的消费，比第一种方案更稳定，客户体验也更加及时。