#############kafka
分布式消息系统，使用scala编写，是活动流和运营数据处理管道的基础
1.使用背景
分析用户行为，搜索关键词进行统计等
支持协议-仿AMQP
不支持事务，为追求高性能，牺牲对事务的支持
####AMQP协议
消费者（consumer）:从消息队列中请求消息的客户端应用程序
生产者（producer）:向broker发布消息的客户端应用程序
AMQP服务器端（broker）：用来接收生产者发送的消息冰箱这些消息路由给服务器中的队列
可以使用大部分主流语言与kafka进行通信，也就是编写自己的consumer和producer
#########kafka架构
主题（topic）
分区（partition）:一个topic中的消息数据按照多个分区组织，分区是kafka消息队列组织的最小单位
一个分区可以看做是一个FIFO的队列
备份（replicatioon）：为了保证分布式可靠性，kafka0.8开始对每个分区的数据进行备份（不同Broker上），防止其中一个Broker宕机造成分区数据不可用
zookeeper：一个提供分布式状态管理，分布式配置管理，分布式锁服务等的集群。
kafka性能不高可增加分区
#########集群搭建
config/server.properties 文件配置
##########kafka消息处理和集群维护
1.消息组织
1.磁盘重认识
读取数据时，需要确定磁道和扇区：
首先必须找到煮面，即磁头需要移动对准相应的磁道-寻道时间
然后目标扇区旋转到磁头下-旋转时间
一次访盘请求（读/写）完成有三过程：
寻道（时间）：磁头移动定位到指定磁道
旋转（延时）：等待指定扇区从磁头下经过
数据传输（时间）：数据在磁盘，内存与网络之间传输
2.kafka消息写入原理（数据写入和读出的零字节拷贝，数据顺序写而不是随机写）
生产：网络->pagecache->磁盘
消费：磁盘->网络
3.kafka消息删除原理
从最久的日志段（.log文件）开始删除（按日志段为单位进行删除），然后逐步向前推进，直到某个日志段不满足条件为止。
删除条件：
1.满足给定条件predicate（配置项log.retention.{ms,minutes,hours}和log.retention.bytes指定）
2.不是当前激活的日志段，即当前正在操作的日志段
3.大小不能小于日志段的最小大小（配置项log.segment.bytes ）
4.要删除的是否是所有日志段，如果是的话直接调用roll方法进行切分，因为kafka至少要保留一个日志段
删除机制：
1.删除：log.retention.check.interval.ms指定间隔
2.刷盘：log.flash.scheduler.interval.ms 指定时间间隔
3.记录checkpoint：log.flush.offset.checkpoint.interval.ms 指定时间间隔
4.压缩（如果有）：一直运行（由log.cleaner.enable指定是否开启）
2.消息检索（partition file由.index文件和.log文件构成）
1.segment file（.log ）组成和物理结构
2.index file（.index ）组成和物理结构
3.检索过程
第一步：查找segmentfile,根据offset（偏移量）二分查找文件列表，可以快速定位文件
第二部：通过segment查找message
3.集群维护
1.集群基本信息实时查看和修改(topic工具)
1.列出集群当前所有可用的topic:
bin/kafka-topics.sh --list -zookeeper zookeeper_address
2.查看集群特定topic信息：
bin/kafka-topics.sh --describe --zookeeper zookeeper_address --topic topic_name
3.创建topic
bin/kafka-topics.sh --create --zookeeper zookeeper_address -replication-factor 1 --partitions 1 --topic topic_name
4.增加（不能减少）partition(最后的4是增加后的值)
bin/kafka-topics.sh --zookeeper zookeeper_address --alter --topic topic_name --patitions 4
2.集群leader平衡机制(机器出现频繁上下线的时候使用)
每个partition的所有replicas叫做“assigned replicas”,"assigned replicas"中的第一个replicas叫“preferred replicas ”
刚创建的topic一般“preferred replicas ”是leader.
集群leader平衡：
bin/kafka-preferred-replica-election.sh -zookeeper zookeeper_address
可以在配置文件中配置好自动执行auto.leader.rebalance.enable=true
3.分区日志迁移(向新集群迁移数据)
迁移topic数据到其他broker:
1.写json文件，文件格式如下：
cat topics-to-mobe.json
{
"topic":[{"topic":"foo1"},{"topic":"foo2"}],
"version":1
}
2.使用-generate生成迁移计划（下面操作是将topic:foo1和foo2移动到broker5,6）
bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topic-to-move-json-file topics-to-move.json --broker-list "5,6" -generate
这一步只是生成计划，并没有执行数据迁移，将执行结果放到expend-cluster-reassignment.json文件中
3.使用-execute执行计划：
bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expend-cluster-reassignment.json -execute
执行前最好保存当前的分配情况，以防止出错回滚
4.使用-verify验证是否已经迁移完成
bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expend-cluster-reassignment.json -verify
迁移某个topic的某些特定的partition数据到其他的broker,步骤一样，json文件变化而已
注意：
kafka-reassign-partitions.sh 工具会复制磁盘上的日志文件，只有当完全复制完成才会删除迁移前磁盘上的日志文件。执行分区日志迁移需要注意：
1.kafka-reassign-partitions.sh工具的粒度只能到broker，不能到broker的目录（如果broker上面配置了多个目录，是按照磁盘上面已经驻留的分区数来均匀分配的），
所以，如果topic之间的数据，或者topic的partition之间的数据本身就不均匀，很有可能造成磁盘数据的不均匀
2.对于分区数据较多的分区迁移数据会花大量的时间，所以建议在topic数量较少或磁盘有效数据较少的情况下执行数据迁移操作
3.进行分区迁移的时候，最好先保留一个分区在原来的磁盘，这样不会影响正常的消费和生产
4.集群监控
1.kafka Offset Moniter(可监控一个集群)
1.当前存活的broker集合
2.集群当前活动的topic列表
3.消费者列表
4.集群当前consumer按组消费的offset lag数
即当前topic当前分区目前有多少消息积压而没有及时消费
2.kafka Manager（可监控多个集群）不只可以观测还可以修改
1.管理多个集群
2.检查集群状态（topic,brokers,副本的分布，分区的分布）
3.选择副本查看
4.重新分配分区