Kafka

kafka：

高吞吐的分布式消息系统
kafka

• 可以将数据直接写入磁盘，保证消息不丢失，
• 吞吐量高因为它是零拷贝，
• 可以持久化保存数据（默认7天），可以重复使用数据（rabbitmq数据使用后就消失了）
  sparkStreaming + Kafka有什么好处：
• 解耦
• 缓冲 可以提供数据高峰时缓冲，低谷时持续向后续传递消息

消息队列常见的场景

• 系统之间解耦合
• 峰值压力缓冲
• 异步通信
  
  消息队列的特点：
• 生产则消费者模式 可靠性保证
  • 自己不丢数据（可以缓存数据到磁盘，默认七天），
  • 消费者不丢数据（至少一次，严格一次）

kafka架构

producer： 消息生产者
consumer： 消息消费者
broker： kakfa集群的server,负责处理消息读。写请求，存储消息（没有主从，依赖于zookeeper来协调）
topic： 消息队列，分类（一类消息的总称，不同类别不同topic）

topic

一个topic可以分为 多个 partition
partition直接接触磁盘

topic写入消息的方式有两种：

• 轮询,将消息轮流写入partition，（先随机一个partition，然后写入消息10分钟，然后在随机一个partition）
• hash:对key求hash然后求余写入partition
• 消息都有key,默认是null,如果是 null,就采用轮询的方式，如果是key有值，就会采用hash的方式写入

每个partition内部消息强有序，其中的每个消息都有一个序号叫offset
一个partition只对应一个broker，一个broker可以管理多个partition （读取消息时是随机一个partiton一次读，然后再读下一个，所以如果是需要有顺序的消息，需要将这部分消息存入一个partiton中）
消息直接写入文件中，并不是存储在内存中
根据时间策略（默认一周）删除，而不是消费完就删除
producer自己决定往哪个partition写消息，可以是轮询的负载均衡，或者是基于hash的partition策略（看消息的key的值）

kafka里面的消息是有topic来组织的，简单的我们可以想象为一个队列，一个队列就是一个topic，然后它把每个topic又分为很多个partition，这个是为了做并行的，在每个partition里面是有序的，相当于有序的队列，其中每个消息都有个序号，比如0到12，从前面读往后面写。
一个partition对应一个broker，一个broker可以管多个partition，比如说，topic有6个partition，有两个broker，那每个broker就管3个partition。
这个partition可以很简单想象为一个文件，当数据发过来的时候它就往这个partition上面append，追加就行，kafka和很多消息系统不一样，很多消息系统是消费完了我就把它删掉，而kafka是根据时间策略删除，而不是消费完就删除，在kafka里面没有一个消费完这么个概念，只有过期这样一个概念

consumer

上图中，我们可以将server1和 server2合起来称为以topic,里面有4个partition，6个消费者（分为两个消费者组，同一消费者组里的消费者只能消费topic上消息一次，不同组之间的消费互不影响）
consumer 自己维护消费到哪个offset（0.8x版本是将offset记录在zookeeper中，0.9以后的版本由kafka集群去维护消费者offset）
每个consumer都有对应的group（如果c1在读p0时读到offset50挂了，c2在读p0时会继续从50开始读，而不是从头，因为会有保存的offset）
qroup内是queue消费者模型：

• 每个consumer消费不同的partition
• 一个消息在group内只消费一次
  各个group各自独立消费，互不影响（上图分为两个消费者组，同一消费者组里的消费者只能消费topic上消息一次，不同组之间的消费互不影响）
  最好同一组内的consumer和集群的partition数一致是最好的，消费者少了可以一个消费者对应多个partition，但是如果consumer多于partition，那么就需要无法接入partition，会空闲下来

Kafka有哪些特点：

• 消息系统的特点：生产者消费者模型，FIFO(内部的partition)
  • partition内部是FIFO的，partition之间不是FIFO，当然我们可以把topic设为一个partition，这样就是严格的FIFO,但是就没有并行了
• 高性能：单节点支持上千个客户端，百兆每秒吞吐、
• 持久性：消息直接持久化在普通磁盘上且性能好
  • 直接写到磁盘里面去，就是直接append到磁盘里面去，这样的好处是直接持久话，数据不会丢，第二个好处是顺序写，然后消费数据也是顺序的读，所以持久化的同时还能保证顺序读写
• 分布式：数据副本冗余、流量负载均衡、可扩展
  • topic由多个partition组成，但是每个partition还可以有副本（可以在创建topic是指定副本数）
  • 分布式，数据副本，也就是同一份数据可以到不同的broker上面去，也就是当一份数据，磁盘坏掉的时候，数据不会丢失，比如3个副本，就是在3个机器磁盘都坏掉的情况下数据才会丢。
• 很灵活：消息长时间持久化+Client维护消费状态
  • 消费方式非常灵活，第一原因是消息持久化时间跨度比较长，一天或者一星期等，第二消费状态自己维护消费到哪个地方了，可以自定义消费偏移量

kafka与其他消息队列的对比（总结就3点，1分布式，2不丢失消息 3重复多次消费）

•RabbitMQ:分布式，支持多种MQ协议，重量级
•ActiveMQ：与RabbitMQ类似
•ZeroMQ：以库的形式提供，使用复杂，无持久化
•redis：单机、纯内存性好，持久化较差
•kafka：分布式，较长时间持久化，高性能，轻量灵活
•RabbitMQ也是常见的消息对列，它支持多种MQ的协议，jms啊，等多种协议等等，它的缺点比较重
•ActiveMQ也和RabbitMQ类似，支持的协议比较多
•ZeroMQ是一个socket的通信库，它是以库的形式提供的，所以说你需要写程序来实现消息系统，它只管内存和通信那一块，持久化也得自己写，还是那句话它是用来实现消息队列的一个库，其实在storm里面呢，storm0.9之前，那些spout和bolt，bolt和bolt之间那些底层的通信就是由ZeroMQ来通信的，它并不是一个消息队列，就是一个通信库，在0.9之后呢，因为license的原因，ZeroMQ就由Netty取代了，Netty本身就是一个网络通信库嘛，所以说更合适是在通信库这一层，不应该是MessageQueue这一层
•Redis，本身是一个内存的KV系统，但是它也有队列的一些数据结构，能够实现一些消息队列的功能，当然它在单机纯内存的情况下，性能会比较好，持久化做的稍差，当持久化的时候性能下降的会比较厉害
•Kafka的亮点，天生是分布式的，不需要你在上层做分布式的工作，另外有较长时间持久化，前面的几个MQ基本消费就干掉了，另外在长时间持久化下性能还比较高，顺序读和顺序写，另外还通过sendFile这样0拷贝的技术直接从文件拷贝到网络，减少内存的拷贝，还有批量读批量写来提高网络读取文件的性能。

零拷贝

从WIKI的定义中，我们看到“零拷贝”是指计算机操作的过程中，CPU不需要为数据在内存之间的拷贝消耗资源。而它通常是指计算机在网络上发送文件时，不需要将文件内容拷贝到用户空间（User Space）而直接在内核空间（Kernel Space）中传输到网络的方式。

零拷贝

leader 均衡机制

replicas：表示副本所在的节点
lsr: 启动时进行数据完整性校验的节点
按照副本优先的顺序就行处理。安装罩replicas的顺序，如果一个2号节点挂了。那么就对0节点上的 partition0进行读写
当一个broker停止或者crashes时，所有本来将它作为leader的分区将会把leader转移到其他broker上去，极端情况下，会导致同一个leader管理多个分区，导致负载不均衡，同时当这个broker重启时，如果这个broker不再是任何分区的leader,kafka的client也不会从这个broker来读取消息，从而导致资源的浪费。
kafka中有一个被称为优先副本（preferred replicas）的概念。如果一个分区有3个副本，且这3个副本的优先级别分别为0,1,2，根据优先副本的概念，0会作为leader 。当0节点的broker挂掉时，会启动1这个节点broker当做leader。当0节点的broker再次启动后，会自动恢复为此partition的leader。不会导致负载不均衡和资源浪费，这就是leader的均衡机制。
在配置文件conf/ server.properties中配置开启（默认就是开启）
auto.leader.rebalance.enable true

搭建集群

1. 上传kafka_2.10-0.8.2.2.tgz包到三个不同节点上，解压。
2. 配置…/ kafka_2.10-0.8.2.2/config/server.properties文件
   节点编号：（不同节点按0,1,2,3整数来配置）
   
   真实数据存储位置：
   
   zookeeper的节点：
   
3. 启动zookeeper集群。
4. 三个节点上，启动kafka: bin/kafka-server-start.sh config/server.properties
   最好使用自己写的脚本启动，将启动命令写入到一个文件：放在与bin同一级别下，注意创建后要修改权限：chmod 755 startkafka.sh

nohup bin/kafka-server-start.sh   config/server.properties > kafka.log 2>&1 &

5. 相关命令：
   创建topic：
   ./kafka-topics.sh --zookeeper node3:2181,node4:2181,node5:2181 --create --topic topic2017 --partitions 3 --replication-factor 3
   用一台节点控制台来当kafka的生产者：
   ./kafka-console-producer.sh --topic topic2017
   –broker-list node1:9092,node2:9092,node3:9092
   用另一台节点控制台来当kafka的消费者：
   ./kafka-console-consumer.sh --zookeeper node3:2181,node4:2181,node5:2181 --topic topic2017
   查看kafka中topic列表:
   ./kafka-topics.sh --list --zookeeper node3:2181,node4:2181,node5:2181
   查看kafka中topic的描述：
   ./kafka-topics.sh --describe --zookeeper node3:2181,node4:2181,node5:2181 --topic topic2017
   
   注意：ISR是检查数据的完整性有哪些个节点。
   查看zookeeper中topic相关信息：
   启动zookeeper客户端：
   ./zkCli.sh
   查看topic相关信息：
   ls /brokers/topics/
   查看消费者相关信息：
   ls /consumers
6. 删除kafka中的数据。
   ① ：在kafka集群中删除topic，当前topic被标记成删除。
   ./kafka-topics.sh --zookeeper node3:2181,node4:2181,node5:2181 --delete --topic t1205
   在每台broker节点上删除当前这个topic对应的真实数据。
   ② ：进入zookeeper客户端，删除topic信息
   rmr /brokers/topics/t1205
   ③ ：删除zookeeper中被标记为删除的topic信息
   rmr /admin/delete_topics/t1205
   
   一周后会被删除，如果被标记删除后，还可以读写数据，如果不用了，一周后会自动删除
   如果想立马彻底删除，直接从 servers.properties配置的log.dirs中直接删除 rm -rf ./cmccdr-0,然后去zookeeper中删除数据数包括 brokers/topics中 和 config还有admin/delete_topics删除cmccdr