Kafka 0.10.1.1 特点

1.Consumer优化：心跳线程可作为后台线程，提交offset，剥离出poll函数

问题:0.10新设计的consumer是单线程的，提交offset是在poll中。本次的poll调用，提交上次poll的心跳和offset值。

The options for the user at the moment to handle this problem are the following:

  • Increase the session timeout to give more time for record processing.
  • Reduce the number of records handled on each iteration with max.poll.records.

0.10.1.1 推荐的配置

session.timeout.ms: 10s
max.poll.interval.ms: 5min
max.poll.records: 500

2.log retention 日志保留

粒度更细

  • old：根据segment的创建时间来删除
  • new：根据message的timestamp来删除

3.Offset和Time Index索引

由于引进了基于Time的索引策略，多了1.5x的存储空间，所以请增大索引文件的大小，防治频繁的rolling。log.index.size.max.bytes

由于加载的东西变多了，broker的启动时间变长了，设置num.recovery.threads.per.data.dir=1 ，可以减少启动时间。

4.重要的改变：0.10.1.0

  • The new Java Consumer now allows users to search offsets by timestamp on partitions.
  • The new Java Consumer now supports heartbeating from a background thread.

5.New Protocol Versions

  1. ListOffsetRequest v1 supports accurate offset search based on timestamps.
  2. MetadataResponse v2 introduces a new field: "cluster_id".
  3. FetchRequest v3 supports limiting the response size (in addition to the existing per partition limit), it returns messages bigger than the limits if required to make progress and the order of partitions in the request is now significant.
  4. JoinGroup v1 introduces a new field: "rebalance_timeout".

6. Kafka Server主要的特性

  1. Time-based Search（基于timeStamp的搜索）：可以根据timestamp来消费topic
  2. Replication Quotas（副本带宽限制）：可以限制replica拉取的带宽，减少对消费者、生产者的影响。
  3. Improved Log Compaction（提升日志压缩）：以前，consumer无法分辨哪些日志是压缩的、还是不压缩的。

对这个详细看看：
对一个consumer而言，如果它lag在一定范围内，那么它能够获得每一条压缩的消息。

对于我的理解，第三条是为了基于精确的时间清理日志而用的。那个关于 database replication 的用法-没有看懂

两个参数的含义：

  • log.cleaner.min.compaction.lag.ms :The minimum time a message will remain uncompacted in the log. Only applicable for logs that are being compacted. 默认值是0. 日志中保留未压缩的message的最小时间。（超过这个时间的日志都是压缩的）
  • min.compaction.lag.ms : topic级别的配置属性（上面那个是Server级别的配置。topic的配置可以覆盖server 的配置。）

7.Kafka Client APIs 主要的特性

  1. Interactive Queries（交互式查询）: Kafka Streaming的特性
  2. Consumer Stabilization（稳定性）：支持background 心跳，让poll之后，message的处理时间更加宽裕

对这个详细看看，

old参数：

  • max.partition.fetch.bytes 用来限制每次consumer fetch数据的大小限制，只是限制partition的，无法限制到一次拉取的总量，有潜在的一次拉取几个GB的可能。

new参数：

  • fetch.max.bytes = 50MB: 限制整个consumer client 一次拉取的总量
  • replica.fetch.response.max.bytes = 10MB : 限制replica拉取线程的 一次拉取量。

new参数能否限制多线程拉取的总量，需要测试测试。即：如果我启动2个consumer 能否把fetch的量达到100MB。

  1. Improved memory management（提升内存管理）：关于Kafka Stream的
  2. Secure Quotas（安全提升）：以前有权限认证管理，现在可以限制Producer和Consuemr的流量了。
    目前是静态配置文件，动态加载的正在讨论中~~~
// Default bytes-out per consumer.
quota.consumer.default=2M
quota.producer.default=2M
 
// Overrides
quota.producer.override="clientA:4M,clientB:10M"
quota.consumer.override="clientC:3M,clientD:5M"

posted on 2017-02-23 10:12  BYRHuangQiang  阅读(859)  评论(0)  编辑  收藏  举报

导航