Kafka概念入门

相关概念术语

• Broker：Kafka 集群包含一个或多个服务器，这种服务器被称为 broker。
• Topic：每条发布到 Kafka 集群的消息都有一个类别，称为Topic。
• Partition：物理上的概念，每个 Topic 包含一个或多个 Partition。
• Producer：负责发布消息到 Kafka broker。
• Consumer：向 Kafka broker 读取消息的客户端。
• Consumer Group：每个 Consumer 属于一个特定的 Consumer Group（可为每个 Consumer 指定 group name，若不指定 group name 则属于默认的 group）。

说明(基于新版)：

• 在集群环境下，其中的一个broker会作为集群的controller，通过集群中处于活跃状态的brokers选举产生，类似管理者的角色，给brokers分配partions,监视brokers等；
• 在集群环境下，一个partition属于一个单独的broker，对于这个partition而言，这个broker是leader。这个partition可能会被分配给其他的borkers作为备份(replicate)。这样当一个partition的leader(broker) faliure，其他的拥有这个partition的broker会接管它作为leader；
• 消费者和生产者对一个partition的操作都是通过它的leader进行；
• 可以配置brokers保存topic或messages的期限，如一段时间或者topic的容量达到一个值，满足这些条件后，messages就会被删除；也可以对具体的topic配置有效期。

Standalone模式

适合本地开发或者一些概念的验证；

安装JAVA

在安装zookeeper或kafka之前，先确定系统是否已经有java环境，详情略。如下图：

安装zookeeper

Zookeeper存储broker和topic的元数据信息或消费者客户端的细节(old version)。可以运行kafka包含的zookeeper脚本启动zookeeper server。这里从阿里云开源镜像站下载安装包zookeeper-3.4.6.tar.gz (所在网络访问不了apache)，如下图：

dataDir配置数据存储的目录， clientPort默认的2181；如下：

为了确认是否正确运行，可以向2181端口发送4 letter words commands检验一下(更多请查看zookeeper文档)：

安装kafka

从阿里云开源镜像站下载安装包kafka_2.11-0.10.1.0.tgz(0.10.1版本运行在scala的2.11版本环境下)，如下图：

现在可以创建一个测试示例检验一下，如下：

Cluster模式

• 集群规模
  集群规模的影响因素很多。需要存储的信息有多少以及单个broker能够存储多少(如集群需要存储20T的数据，单个broker能够存2T,那么最少需要10台broker。此外，设置了备份(副本)，那么集群还要相应的扩大)；网络带宽（如一个消费者使一个broker的网络峰值接近最大，现在有两个消费者需要数据(消费者将无法跟上高峰流量)，可以考虑扩展(添加)一个broker）等等。

• 配置
  在搭建集群的时候，需要注意的是所有节点的zookeeper.connect要相 同，broker.id要不同，更多信息可参考官方说明。

• 操作系统调优
  对linux系统熟悉的人员可以通过Sysctl接口来添加调整一些参数来优化系统进而提高kafka的性能。配置文件在/etc/sysctl.conf。打开如下图：
  

• 虚拟内存
  首先，kafka大量使用系统页缓存，如果VM正在交换到磁盘，很难保证有足够的内存分配给页面缓存，因此可以调整交换空间的配置，尽量使用内存（swap不是系统必须的，可以不配置交换空间，swap可以防止操作系统由于内存不足而突然杀死进程），配置vm.swappiness为一个较小的值。
  其次，可以考虑调整优化内核刷新脏页到磁盘。kafka依赖磁盘I/O性能为生产者提供良好的响应时间，这也是日志段通常放在快盘的原因。如果使用的磁盘I/O性能高，减小文件系统缓存的脏页，及时刷新到磁盘中，释放出内存是不错的选择，设置vm.dirty_background_ratio为一个较小的值，设置vm.dirty_ratio为一个较大的值。
  对上述这些参数进行优化调整后，有必要在运行的时候查看虚拟内存的统计信息,以确认调整优化是否合适，从内核导出的虚拟内存的统计信息可以查看文件/proc/vmstat如下图：
  
  nr_dirty 3 #脏页数，nr_writeback 0 #回写页数(其他的含义查看相关文档)。

说明：
swappiness=1(老版本内核0,可以具体去看资料)的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。
vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时就会触发后台回写进程运行，将一定缓存的脏页异步地刷入外存；
vm.dirty_ratio:这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时系统不得不开始处理缓存脏页（此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存），在60和80之间是一个合理的数字，修改这个设置会有一定风险，建议kafka配置replication。
达到vm.dirty_background_ratio的条件然后触发flush进程进行异步的回写操作，但是这一过程中应用进程仍然可以进行写操作，如果多个应用进程写入的量大于flush进程刷出的量那就会达到vm.dirty_ratio这个参数所设定的值，此时操作系统会转入同步地处理脏页阻塞应用进程。

• 磁盘
  除了硬件选择外，文件系统也有不小的影响。有许多不同的文件系统，使用较多的是ext4。可以优化参数来使ext4表现的更好，可是有些优化调整被认为是不安全的，如延迟分配等。这里推荐XFS文件系统，它的一些特性更适合kafka的运行，而不需要过多的优化调整(ext4)。可查看XFS的文档。
  文件元数据中有三种时间atime,ctime,mtime，对kafka这种大吞吐量的系统而言，关闭atime更新可以明显的降低延迟时间和提高吞吐量，而且kafka没有使用atime。可以在挂载的时候设置noatime(mount –o noatime)来不更新atime(用touch命令可以强制刷新文件的atime)。

说明：
atime 是在读取文件或者执行文件时更改的任何对inode的访问都会使此处改变；
mtime 是在写入文件时随文件内容的更改而更改；
ctime 是在写入文件、更改所有者、权限或链接设置时随 Inode 的内容更改而更改；

• 网络
  kafka的推荐优化和大多数的web服务器或网络应用系统的建议优化相同。修改/etc/sysctl.conf来更改内核参数，例如：
  net.ipv4.tcp_rmem = 4096 65536 2048000：这个参数定义了TCP接受缓存的最小值、默认值、最大值(值仅供参考)。
  net.ipv4.tcp_wmem = 4096 65536 2048000：这个参数定义了TCP发送缓存的最小值、默认值、最大值(值仅供参考)。
  net.ipv4.tcp_max_syn_backlog：这个参数标示TCP三次握手建立阶段接受SYN请求队列的最大长度，默认为1024，将其设置得大一些可以在繁忙来不及accept新连接的情况时，Linux不至于丢失客户端发起的连接请求。
  net.ipv4.tcp_window_scaling：设置tcp/ip会话的滑动窗口大小是否可变。参数值为布尔值，为1时表示可变，为0时表示不可变。tcp/ip通常使用的窗口最大可达到 65535 字节，对于高速网络，该值可能太小，这时候如果启用了该功能，可以使tcp/ip滑动窗口大小增大数个数量级，从而提高数据传输的能力。
  net.core.netdev_max_backlog：当网卡接受数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。这个参数表示该队列的最大值。
  net.core.rmem_default：这个参数表示内核套接字接受缓存区默认的大小。
  net.core.wmem_default：这个参数表示内核套接字发送缓存区默认的大小。
  net.core.rmem_max：这个参数表示内核套接字接受缓存区的最大大小。
  net.core.wmem_max：这个参数表示内核套接字发送缓存区的最大大小。
  等等(还有更多可调整的参数)。
  对网络的调优并不仅仅这些参数设个值就可以了，要针对自己的具体环境实际调整测试得出最优解。

• 其他

• Garbage-First收集器 (G1)
  推荐使用 G1 的场景(Recommended Use Cases)， G1的首要目标是为需要大量内存的系统提供一个保证GC低延迟的解决方案。如果应用程序具有如下的一个或多个特征,那么将垃圾收集器从CMS或ParallelOldGC切换到G1将会大大提升性能：

• Full GC 次数太频繁或者消耗时间太长。

• 对象分配的频率或代数提升(promotion)显著变化。
• 受够了太长的垃圾回收或内存整理时间(超过0.5~1秒)。

注意： 如果正在使用CMS或ParallelOldGC，而应用程序的垃圾收集停顿时间并不长，那么继续使用现在的垃圾收集器是个好主意。 使用最新的JDK时并不要求切换到G1收集器。

• Zookeeper
  kafka的元数据通过zookeeper来管理，而hadoop生态圈里很多应用也用的是zookeeper，大家同时使用同一个ensemble，会让zookeeper的压力过大，进而影响到kafka。可以考虑kafka单独使用自己的zookeeper。且broker与zookeeper的连接不畅可能会造成预想不到的一些问题。

  附录

• 性能相关

• 磁盘
  消息提交本地(broker)存储，越快的写入消息等待的时间越少，为生产者提供良好的响应时间。如：使用固态硬盘(SSD)，使用磁盘阵列技术(RAID)等。

• 内存
  除了磁盘性能外，broker的可用内存是影响客户端性能的主要因素。如上文所述，磁盘性能影响到生产者，这里主要影响的是消费者。较常见的消费模式是从最新的(latest)offset读取，提交offset(latest offset)这种方式。在这种情况下，消费者从系统页面缓存(system page cache)读取是最佳的方式，比broker从磁盘重读信息快。
  Kafka本身并不需要太多的堆内存。剩余的内存kafka会用于页面缓存(page cache)。所以建议kafka单独装，不要和其他重要应用装在一起，这会影响到page cache，进而降低性能。

• 网络
  消息的传输，balance,replication,mirroring等都需要良好的网络环境。

• CPU
  相对磁盘和内存而言，cpu的比重要小不少。如：为了存储和网络考量，客户端对消息压缩处理，这样broker要为每批消息解压缩分配偏移量，然后再次压缩存储到磁盘上。

• 常用配置说明
  broker.id
  每个broker都需要一个正整数的的数字标志，在一个集群中互相之间不能重复；
  port
  kafka启动TCP的监听端口，已经过期啦， 用listeners替代，如果listeners未配置，则使用port的值；
  zookeeper.connect
  zookeeper存储broker的元数据的位置host:port/path，如有多个以逗号分隔。如果path省略了，则使用根目录存储。如果指定的path不存在， broker启动后会创建；指定多个zk 服务，在其中一个失败的时候，kafka broker可以去连接其他的服务；
  log.dirs
  kafka持久化信息到磁盘的位置，如果有多个以逗号分隔。配置了多个位置broker以”least used”的方式存储partition;
  num.recovery.threads.per.data.dir
  每个数据目录用来日志恢复的线程数目，为了更好的并行操作的时候可以调大这个值。需要注意的是，如果这个值配置的是2，log.dirs也配置了两个路径，则有2*2=4个线程；
  auto.create.topics.enable
  如果主题不存在的时候，允许服务自动创建主题。如消费者或生产者向一个不存在的主题中抓取或者推送消息的时候，会自动创建这个topic。Kafka集群之间的镜像备份时候，这个是true就很有必要了。
  log.retention.ms(log.retention.hour, log.retention.minutes)
  message的有效期,如果配置了多个，最小的值生效；此配置控制我们保留日志的最大时间，在使用“删除”保留策略之前，我们将丢弃旧的日志段以腾出空间。
  log.retention.bytes
  如果我们使用“删除”保留策略，这个配置将控制日志的最大大小，然后我们将丢弃旧的日志段以腾出空间。默认情况下，没有大小限制，只有时间限制。注意的是，这个是针对单个partition而言，如果partition在增加，topic的总大小相应增加；
  说明：如果时间和容量都配置了，则只要其中一个条件满足了，我们就会丢弃旧的日志以腾出空间。
  log.segment.bytes
  此配置控制日志的段文件大小。消息进来添加到当前的日志段中，当日志段的大小达到了配置的容量，则关闭日志段(current log segment)并打开一个新的。这时候可以认为这个日志段坐等回收(expiration)。如果设置过小的话，太多的关闭打开会浪费磁盘的IO。但是一味的设置过大也不合适，如：topic每天接受100M的消息，log.segment.bytes设置为1G,则一个日志段可以接受10天的消息，同时配置消息的有效期(log.retention.ms)7天，则这段日志要17天后才到期(日志未被移动或其他操作执行)。
  message.max.bytes
  kafka允许添加的消息大小。请注意，如果您增加此大小，您还必须增加您的消费者的取大小(fetch.message.max.bytes)。消息不是越大越好，要考虑到消息越大对网络以及磁盘的要求越高。
  更多配置请查看Configuration。

• 删除topic:
  
  说明：kafka启动的server.properties文件中配置delete.topic.enable=true，则直接上述的命令就会删除指定的topic,否则执行后topic不会删除，如下：
  
  此时需要手动删除如下内容：
  1，删除kafka存储目录（server.properties文件log.dirs配置）相关topic目录;
  2，登录zookeeper客户端(zookeeper.connect使用默认的根目录)，删除/brokers/topics/【topic name】;
  如果执行了kafka的delete操作，则zookeeper的/admin/delete_topics里面有标记的删除topic，如果你删除了此处的topic，那么marked for deletion 标记消失。