学习kafka的基本信息总结

Kafka初窥

Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标以下：

• 以时间复杂度为O(1)的方式提供消息持久化能力，即便对TB级以上数据也能保证常数时间的访问性能
• 高吞吐率。即便在很是廉价的商用机器上也能作到单机支持每秒100K条消息的传输
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每一个partition内的消息顺序传输
• 同时支持离线数据处理和实时数据处理

消息系统特色

解耦

在项目启动之初来预测未来项目会碰到什么需求，是极其困难的。 消息队列在处理过程当中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。 这容许你独立的扩展或修改两边的处理过程，只要确保它们遵照一样的接口约束。

冗余

有些状况下，处理数据的过程会失败。除非数据被持久化，不然将形成丢失。消息队列把数据进行持久化直到它们已经被彻底处理，经过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除以前，须要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。

扩展性

由于消息队列解耦了你的处理过程，因此增大消息入队和处理的频率是很容易的；只要另外增长处理过程便可。不须要改变代码、不须要调节参数。扩展就像调大电力按钮同样简单。

灵活性 & 峰值处理能力

在访问量剧增的状况下，应用仍然须要继续发挥做用，可是这样的突发流量并不常见；若是为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列可以使关键组件顶住突发的访问压力，而不会由于突发的超负荷的请求而彻底崩溃。

可恢复性

当体系的一部分组件失效，不会影响到整个系统。消息队列下降了进程间的耦合度，因此即便一个处理消息的进程挂掉，加入队列中的消息仍然能够在系统恢复后被处理。而这种容许重试或者延后处理请求的能力一般是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。

送达保证

消息队列提供的冗余机制保证了消息能被实际的处理，只要一个进程读取了该队列便可。在此基础上，IronMQ提供了一个”只送达一次”保证。不管有多少进程在从队列中领取数据，每个消息只能被处理一次。这之因此成为可能，是由于获取一个消息只是”预约”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，不然这个消息会被放回队列中去，在一段可配置的时间以后可再次被处理。

顺序保证

在大多使用场景下，数据处理的顺序都很重要。消息队列原本就是排序的，而且能保证数据会按照特定的顺序来处理。IronMO保证消息经过FIFO（先进先出）的顺序来处理，所以消息在队列中的位置就是从队列中检索他们的位置。

缓冲

在任何重要的系统中，都会有须要不一样的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列经过一个缓冲层来帮助任务最高效率的执行–写入队列的处理会尽量的快速，而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流通过系统的速度。

理解数据流

在一个分布式系统里，要获得一个关于用户操做会用多长时间及其缘由的整体印象，是个巨大的挑战。消息队列经过消息被处理的频率，来方便的辅助肯定那些表现不佳的处理过程或领域，这些地方的数据流都不够优化。

异步通讯

不少时候，你不想也不须要当即处理消息。消息队列提供了异步处理机制，容许你把一个消息放入队列，但并不当即处理它。你想向队列中放入多少消息就放多少，而后在你乐意的时候再去处理它们。

经常使用消息系统一览

名称	一览
RabbitMQ	RabbitMQ是使用Erlang编写的一个开源的消息队列，自己支持不少的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它很是重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
ZeroMQ	ZeroMQ号称最快的消息队列系统，尤为针对大吞吐量的需求场景。ZMQ可以实现RabbitMQ不擅长的高级/复杂的队列，可是开发人员须要本身组合多种技术框架，技术上的复杂度是对这MQ可以应用成功的挑战。ZeroMQ具备一个独特的非中间件的模式，你不须要安装和运行一个消息服务器或中间件，由于你的应用程序将扮演了这个服务角色。你只须要简单的引用ZeroMQ程序库，可使用NuGet安装，而后你就能够愉快的在应用程序之间发送消息了。可是ZeroMQ仅提供非持久性的队列，也就是说若是宕机，数据将会丢失。其中，Twitter的Storm 0.9.0之前的版本中默认使用ZeroMQ做为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty做为传输模块）。
ActiveMQ	ActiveMQ是Apache下的一个子项目。 相似于ZeroMQ，它可以以代理人和点对点的技术实现队列。同时相似于RabbitMQ，它少许代码就能够高效地实现高级应用场景。
Kafka	Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统。具备如下特性：快速持久化，能够在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既能够达到10W/s的吞吐速率；彻底的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的同样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka经过Hadoop的并行加载机制来统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个很是轻量级的消息系统，除了性能很是好以外，仍是一个工做良好的分布式系统。

为何选择Kafka

• Apache子项目，轻量级的消息系统，版本稳定并持续更新
• 快速持久化，能够在O(1)的系统开销下进行消息持久化
• 高吞吐，在一台普通的服务器上既能够达到10W/s的吞吐速率
• 彻底的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡
• 支持离线数据处理和实时数据处理

Kafka使用场景

• 消息系统： 应用程度使用Kafka做为传统的消息系统实现标准的队列和消息的发布—订阅，例如搜索和内容提要（Content Feed）。
• 监控：主机经过Kafka发送与系统和应用程序健康相关的指标，而后这些信息会被收集和处理从而建立监控仪表盘并发送警告。除此以外，LinkedIn还利用Apache Samza实现了一个可以实时处理事件的富调用图分析系统。
• 分析: 为了更好地理解用户行为，改善用户体验，LinkedIn公司将用户查看了哪一个页面、点击了哪些内容等信息发送到每一个数据中心的Kafka集群上，并经过Hadoop进行分析、生成平常报告。
• 做为分布式应用程序或平台的构件（日志）：大数据仓库解决方案Pinot等产品将Kafka做为核心构件（分布式日志），分布式数据库Espresso将其做为内部副本并改变传播层。
• 日志聚合： kafka的特性决定它很是适合做为“日志收集中心”；application能够将操做日志“批量”“异步”的发送到kafka集群中,而不是保存在本地或者DB中；kafka能够批量提交消息/压缩消息等,这对producer端而言,几乎感受不到性能的开支.此时consumer端可使hadoop等其余系统化的存储和分析系统。

Kafka深刻

基本术语

• topic：将Kafka中的消息分类，一类消息能够称为topic，topic也能够看做消息队列
• produce：将消息发布到Kafka对应topic中的进程
• consumer：订阅Kafka的某个topic，并从该topic中消费消息
• broker：Kafka由一个或多个服务器构成的分布式系统，每一个服务器称做broker。一台物理机器可能有多个broker。 

图从上层结构反映：producers经过网络向Kafka集群发送消息，Kafka又将消息发送给consumers。Produce和Kafka集群，以及Kafka集群和consumer之间是经过TCP协议通讯的。

Topic和日志

Topic是属于同一类消息的集合，Kafka采用分区的方法维护每一个topic，格式以下： 每一个分区都是一个有序的，不变的消息队列。分区中的消息在本分区中都有一个惟一序列id，该序列id称为offset。新的消息直接添加到分区的末尾。 Kafka会保留设置时间范围内的全部消息记录，尽管某些记录已经被consumer消费过。每一个consumer会保存其在日志中的位置信息，该位置信息称为offset，offset由consumer管 

理。Consumer增长offset的值，依次读取队列中新的消息。可是，consumer控制offset，使其可以读取任意offset的消息。 Consumer这种读取消息的机制，使得consumer很是灵活，能够随时读取topic中任意位置的消息，consumer的运行和Kafka集群以及其余consumer没有影响。 Partition是物理上的分区，每一个partition有若干segment组成。具体参考以下：

• 单broker分布状况
• 多broker分布状况

分布式

日志的partitions分布在Kafka集群的每一个server上，每一个服务器负责一部分partitions的数据处理和请求。每一个partition均可以设置若干备份分布在Kafka集群的其余server上，而且每一个partition都有一个server做为leader，0个或多个server做为辅助的follows。Leader处理其负责的partition全部的读写请求，follows对leader上全部的读写请求等元数据进行备份，以便leader宕机以后follow充当leader的角色。扮演leader的服务器处理部分partitions，其余的follows处理其余的partitions，这样Kafka集群就实现了负载均衡的功能。

Producers

Produce将消息发布到它选择的topic中，并负责将消息分发到其对应topic的partition中。

Consumers

传统消息有排队和发布-订阅两种模型。在排队模型中，consumer池中的consumer从一个server读取消息，每条消息只能被一个consumer取到。在分发-订阅模型中，每条消息被广播到全部的consumers。Kafka用consumer group整合了这两种模型的特色。 每一个consumer都属于一个consumer group。Kafka集群和consumer group之间的消息分发采用了发布-订阅模型，consumer group中的consumer经过consumer group和Kafka集群采用了排队模型。

alt text

上图所示：每一个server中的partition都广播到各个consumer group，每一个consumer group中的consumer都从group中获取消息。 两种极端的状况： 1. 若全部的consumer都属于同一个consumer group，每一个consumer都从Kafka集群以队列模型获取消息 2. 若全部的consumer属于不一样的consumer group，kafka集群至关于将消息广播到每一个consumer Kafka经过将topic分红partitions的方式维持并行性，并经过consumer线程池确保消息的有序性和负载均衡。具体作法为：将topic分红若干partitions，在consumer group中建立若干consumers，每一个partition对应一个consumer，这样每一个consumer都有序的读取其对应partition上的消息。从整个topic来看，若干consumers并行读取topic中的消息。

安装和使用

Centos安装Zookeeper

• 解压zookeeper包
  ##以版本号zookeeper-3.4.8.tar.gz为例，将zookeeper-3.4.8.tar.gz解压到/home/kafka目录下

  sudo tar xvf zookeeper-3.4.8.tar.gz  -C    /home/kafka
  mv zookeeper-3.4.8 zookeeper

• 配置/etc/profile文件

  sudo vi /etc/profile
  export ZOOKEEPER_HOME=/home/kafka/zookeeper
  export PATH=$ZOOKEEPER_HOME/bin:$PATH
  CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$ZOOKEEPER_HOME/libs
  export PATH
  source /etc/profile   ##使得配置文件生效

• 配置zookeeper

  mkdir  -p /home/kafka/zookeeper/data
  cd   /home/kafka/zookeeper/bin
  cp zoo.sample.cfg  zoo.cfg
  vi zoo.cfg
  dataDir=/home/kafka/zookeeper/data  ##修改 

• 启动和关闭zookeeper

  bin/zkServer.sh start   ##启动zookeeper
  bin/zkServer.sh stop    ##关闭zookeeper

Centos安装Kafka

• 解压和安装kafka
  ##以版本号kafka_2.11-0.9.0.1.tgz为例，将kafka_2.11-0.9.0.1.tgz解压到/home/kafka目录下

  sudo tar xvf kafka_2.11-0.9.0.1.tgz  -C    /home/kafka
  mv kafka_2.11-0.9.0.1.tgz kafka

• 配置kafka

  cd ~/kafka/config
  vi server.properties ##打开server.properties配置文件
  log.dirs=/tmp/kafka-logs ##修改log路径
  zookeeper.connect=localhost:2181 ##配置zookeeper

使用kafka

cd ~/kafka/bin 
bin/kafka-server-start.sh config/server.properties &  ##启动kafka
bin/kafka-server-stop.sh config/server.properties    ##关闭kafka
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test &  ##建立topic
bin/kafka-console-producer.sh --broker-list localhost:9092 --sync --topic test ##建立生产者
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test ##建立消费者

• 总结可能不完善，若有更详细的，但愿能够留言，互相学习