前言
   
- 介绍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 | 当前已消费的条数 | 总条数 | 未消费的条数 | 
在生产环境,应用能够稳定的消费,比第一种方案更稳定,客户体验也更加及时。
 
