Kafka 0.8.2.1版本之后Release Note重点

1 1.0.0

1.0.0引入了一些网络协议变化。升级前需要注意下1.0.0的重大变化。

升级步骤：

1.更新所有broker的server.properties，修改下列两个属性。CURRENT_KAFKA_VERSION指的是升级前的kafka集群版本。CURRENT_KAFKA_VERSION指当前在使用的消息格式的版本。如果你是从0.11.0.x之前升级过来的，CURRENT_KAFKA_VERSION应该和CURRENT_KAFKA_VERSION保持匹配。

inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 0.8.2 or 0.9.0or 0.10.0 or 0.10.2， 0.11.0).
log.message.format.version=CURRENT_KAFKA_VERSION（此参数与升级影响性能有关）

如果你从0.11.0.x系列升级而来并且没有覆盖过消息格式，你只需要修改inter.broker.protocol.version的值。

2.一台一台的升级broker，等一台启动完成后再重启另一台

3.等所有broker完成代码升级后，将所有broker 的inter.broker.protocol.version= 1.0。

4.依次重启所有broker，以使新的协议生效

5.如果像上面说的你之前覆盖过消息格式版本的值，你需要做更多的滚动升级将消息格式升级到最新版本。一旦所有（或大部分）consumers升级到了0.11.0或之后版本，将log.message.format.version设为1.0，然后依次重启。需要注意，老的scala consuemr不支持0.11引入的新的消息格式，为避免做降版本消息转换（或者使用有且仅有一次的特性），必须使用新的java consumer。

附加升级注意事项：

1.如果你接受停机升级，那么可以将所有broker停掉，更新代码，然后重启。那么就会以新的协议重启。

2.在brokers升级后，升级协议的版本和重启随时可以做，不需要立刻做。消息格式的版本也是类似的。

重大变化：

删除topic默认是启用的，因为现在删除的方法是稳定的。需要注意删除是不可逆的。
对于支持按时间戳搜索的topic，如果某个分区找不到offset，搜索结果会返回null值。之前这个分区结果将不会包含在结果map里。这个变动使得不支持按时间戳搜索的topic的搜索行为保持一致。
如果inter.broker.protocol.version 版本是1.0或之后，broker仍然会为log目录下的分区提供online服务，即使有一些下线的log目录。一个log目录可能会因为硬件的IO异常变为下线。用户需要监控每个broker的metrics offlineLogDirectoryCount 来检查是否有已下线的log目录。
增加了 KafkaStorageException异常，这是个可重试的异常。如果client端的fetchrequest或者producerrequest不支持KafkaStorageException ，那么这个异常会被转换为 NotLeaderForPartitionException。
默认JVM设置中， -XX:+ExplicitGCInvokesConcurrent代替了原来的-XX:+DisableExplicitGC。这可以帮助在某些情况下分配原生的直接内存时避免内存溢出。
重写的handleError 方法从下面这些kafka.api 包下弃用的类中被移除，包括：FetchRequest, GroupCoordinatorRequest,OffsetCommitRequest, OffsetFetchRequest, OffsetRequest, ProducerRequest, 和 TopicMetadataRequest。这些最初是为了broker端设计，但现在不再使用，实现也不再保留。紧紧为了二进制的兼容保留了一个基本实现。
Java client和工具现在可以接受任何string类型的作为client id。
弃用的工具kafka-consumer-offset-checker.sh 被移除。使用kafka-consumer-groups.sh 获取consumer group的详细信息。
SimpleAclAuthorizer 现在默认会记录被拒绝的访问请求。
认证失败时会返回给客户端AuthenticationException异常。认证失败时，client 连接也不会重试。
认证失败时传统的SaslServer 实现可能会扔出SaslAuthenticationException 异常返回给客户端。用户自己实现时尽量避免在异常中泄露隐私信息。
JMX注册的app-info 的提供版本和commit id的mbean被弃用。取而代之的是metrics提供这些属性。
Kafka metrics现在可能包含非数字的值。org.apache.kafka.common.Metric#value() 已被弃用，这种情况下将会返回0.0，以避免给用户代理异常。org.apache.kafka.common.Metric#metricValue() 可以被用来获取数字和非数字的值。
每个kafka的速率metric现在都有一个相关的累加量，通过后缀 -total 简化下游的处理。比如，records-consumed-rate 有一个先关的records-consumed-total值。
org.apache.kafka.common.security.auth 在client包中被修改为public,并增加到javadoc中。内部类中之前引用这个包的地方都已经被移动了。
使用授权时，用户对某个topic没有权限时，broker会返回TOPIC_AUTHORIZATION_FAILED 错误，不管该topic实际存不存在。如果用户有权限，而topic不存在，返回的是另外一个 UNKNOWN_TOPIC_OR_PARTITION错误码。
config/consumer.properties文件使用新的consumer的配置属性。

新的通信协议：

LeaderAndIsrRequest v1 引入一个分区级别的新的字段is_new。
UpdateMetadataRequest v4 引入一个分区级别的新的字段offline_replicas 。
MetadataResponse v5引入一个分区级别的新的字段offline_replicas 。
ProduceResponse v4 引入一个KafkaStorageException的一个错误码。
FetchResponse v6 引入一个KafkaStorageException的一个错误码。
ProduceRequest v3在消息协议中引入了一个数组header ，包含了key 字段和value 字段。
引入SaslAuthenticate request支持认证失败。SaslHandshake request版本大于0的话，就会使用此request。

升级1.0.0 的kafka stream：

升级Streams 应用从0.11.0 到1.0.0 不需要broker端升级. 1.0.0 Streams 应用可以连接到0.11.0, 0.10.2 和 0.10.1 brokers (不能与 0.10.0 brokers 通信)。
如果你在监控stream的metric，你需要对metric名字做一些改变，因此metrics响应发生了变化。
一些公共的APIs 包括 ProcessorContext#schedule(), Processor#punctuate() 和 KStreamBuilder, TopologyBuilder 在新的APIS中被弃用。推荐做相关的代码修改，修改不会太大，因为新的API看起来很相似。
更多可参考Streams API changes in 1.0.0。

2. 0.11.0.0

0.11.0.0引入了一个新的消息格式，同时网络协议也发生了一些变化。升级之前需要注意下0.11.0.0带来的重大变化。

0.11.0的client端可以跟0.10.0及之后版本的brokers通信。如果你的broker比0.10.0还老，在升级client之前必须要升级kafka集群。 0.11.0版本的brokers支持0.8.x系列和更新的client端。

升级步骤：

同0.10.2.0的升级步骤。

附加升级注意事项：

可以通过bin/kafka-topics.sh为单独的topic指定消息格式，这样会覆盖broker端设置的全局消息格式。
如果你从0.10.0之前的版本升级到0.11.0，没有必要在将消息格式转换为0.11.0之前先升级到0.11.0。

升级0.10.2 的kafka stream：

Streams 应用由0.10.1升级到0.10.2，broker可以不用升级。因为0.10.2的stream可以跟0.10.1或0.10.2通信（但是不能与0.10.0的broker升级）。
key.serde, value.serde 和 timestamp.extractor已弃用，推荐使用代替的配置值。
更多细节参考Streams API changes in 0.11.0

重大变化：

Unclean election(当ISR中没有副本时，选取第一个启动的副本作为leader 的选举算法)现在默认是禁用的。新的配置比起可用性更倾向于稳定性。因此如果还想使用这种算法，需要显示的指定unclean.leader.election.enable 为true。
Producer的配置block.on.buffer.full, metadata.fetch.timeout.ms 和 timeout.ms 现在被移除。这些属性最早在0.9.0.0已被弃用了。
broker的配置offsets.topic.replication.factor 现在在创建topic的时候必须要指定。内部自动创建topic会失败并出现 GROUP_COORDINATOR_NOT_AVAILABLE的错误，直到集群的大小（节点数满足副本的要求）达到这个参数的要求。
为提高压缩比，使用snappy压缩数据时，producer和broker会使用压缩方案的默认block大小（2*32kb）代替1kb。有报告显示，采用较小的这个block size压缩后的数据会比采用较大的block size压缩的数据大50%。使用snappy的情况下，对于一个有5000个分区的producer, 现在需要额外的315MB的JVM堆。
类似的，使用gzip压缩时，producer和broker的buffer size采用8KB代替1kb。默认值太低了（512字节）。
broker的max.message.bytes 现在适用于批量的消息的总值。之前只适用于批量压缩消息的总量或者单独的每条非压缩的消息。每次批量batch的消息也可能只包含一条消息，所以大多数情况下，单条消息的大小限制只会在bacth的头部上占去一部分大小。但是，如果存在消息格式转换的情况下，可能会有一些影响（详细细节见下面）。同样需要注意到，之前broker可以保证每次fetch请求至少可以返回一条消息（不管总的或者分区水平上的fetch大小是多少），现在也同样适用于batch的请求。
GC 日志支持自动滚动。
RecordMetadata, MetricName和Cluster类中弃用的构造方法已被移除。
增加的user headers支持通过一个新的Header接口提供user header读和写头部。
ProducerRecord 和 ConsumerRecord暴漏了一个新的Header api 调用。
引入ExtendedSerializer 和ExtendedDeserializer接口去序列化和反序列化头部信息，如果配置的不是上面两个类，那么头部序列化会被忽略。
引入了一个新的配置， group.initial.rebalance.delay.ms，这个配置指定了 GroupCoordinator延迟最开始的consumer的时间，单位是ms。默认值是3秒。在开发和测试时，可以把这个设置为0，以避免延长测试使劲。
当请求的topic不存在时，现在org.apache.kafka.common.Cluster#partitionsForTopic, partitionsForNode 和 availablePartitionsForTopic 方法会返回一个空list，而不是null(被认为是比较差的体验)。
Streams API的配置timestamp.extractor, key.serde, 和 value.serde 被弃用，分别被 default.timestamp.extractor, default.key.serde, 和default.value.serde代替。
Java consumer的commitAsync 的API在处理commit offsets失败时，如果RetriableCommitFailedException 异常被传递给commit的回调线程，我们不再暴漏出潜在的原因。更多细节见 KAFKA-5052。

新的通信协议：

FetchRequest v5 引入一个分区级别的新的字段log_start_offset。
FetchResponse v5引入一个分区级别的新的字段log_start_offset。
ProduceRequest v3在消息协议中引入了一个数组header ，包含了key 字段和value 字段。
FetchResponse v5在消息协议中引入了一个数组header ，包含了key 字段和value 字段。

有且只有一次语义：

kafka0.11.0 在producer端引入了幂等和事务能力。幂等传输保证了在producer生命周期里，消息能且仅被传输一次到特定的topic分区。事务性使得需要传输数据到多个分区的producer能成功的将所有消息传输到kafka,或者全部都传输失败。这些特性保证了kafkade exactly once semantics。更多这个特性的细节可以参考用户指导。下面我们只描述特定的能使他们在升级的集群中生效的一些重点。注意保证Eos并不是必须的，如果不用EoS的话，也不对kafka的行为产生影响。

只有新版本Java producer和consumer 支持exactly once semantics。
这些特性严重依赖于0.11.0的消息格式。如果在老的消息格式上使用这些特性会报版本不支持的错误。
事务状态被存储在一个内部topic __transaction_state上。直到第一个试图使用事务请求api调用时才会去创建这个topic。与consumer offsets topic类似，有一些配置是用来控制这个topic的。比如，transaction.state.log.min.isr 指定了这个topic的最小的ISR。全部的配置可以参阅用户指导里的配置部分。
对于一个安全（开启了认证）的集群，事务的APIS需要新的ACLS，这个可以通过bin/kafka-acls.sh.开启。
Kafka里的EoS引入了新的APIS，修改了原有的一些接口。参考KIP-98。

0.11.0的新的消息格式：

为了更好的支持producer的语义有且仅有一次特性以及提高备份的容灾能力，0.11.0的消息格式做了一些较大的增强。尽管新的消息格式包含了更多的消息，我们使batch 的消息格式效率更高。只要batch的消息个数大于2，你就可以预期到更低的头部开销。较小的批量消息获取，性能表现也会较差。我们对新的消息格式性能分析参考这里here。

新的消息格式一个大的不同在于，即使是非压缩的消息也会在一个batch中被存储在一起。这会涉及到broker的配置max.message.bytes, 这限制了单次batch的大小。首先，如果一个老版本的producer发送了老版本消息到topic分区上，并且这些消息每个都比max.message.bytes小，在消息格式转换成新版本消息过程中，在这些消息被合并到一个batch中时，broker仍然会有可能拒绝这些消息。这一般发生在聚合的单条消息的个数导致总大小大于了max.message.bytes。同样在老consumer读取从新版本消息格式转换过来的消息时也可能会有意义的问题：如果fetch大小并没有被设置成至少比max.message.bytes大，那么即使单条消息可能比配置的fetch size 小，consumer依然可能会出报错。这个问题不会出现在0.10.1.0 之后的版本，因此它们都采用了新的fecth协议，可以保证至少一条消息可以被返回，即使超过了fecth size。为解决此问题，你应该确保， producer的bacth size不要大于max.message.bytes, consumerde fetch size至少要比max.message.bytes大。

大部分关于升级到0.10.0的消息格式带来的性能影响同样在升级到0.11.0时也适用。这主要影响到那些并没有参与TLS保证安全的集群，因为这些集群中零拷贝转换是不可能的。为避免降版本转换带来的开销，你应该保证所有consumer被升级到0.11.0版本。特别注意，由于老版本consumer在0.11.0.0被弃用了，它也不支持新版本的消息格式。必须要升级使用新consumer来消费新版本的消息，来避免降版本转换。需要注意0.11.0的consumer兼容0.10.0的broker, 因此支持先将client升级再升broker。

3. 0.10.2.0

0.10.2.0网络协议发生了一些变化。需要注意下0.10.2.0带来的重大变化。

0.10.2.0版本启动的客户端（producer和consuemr）现在可以跟老版本的broker通信。0.10.2的客户端可以跟0.10.0之后的broker通信。如果你的broker比0.10.0还老，在升级client之前必须要升级kafka集群。 0.10.2版本的brokers支持0.8.x系列和更新的client端。

升级步骤：

1.更新所有broker的server.properties，修改下列两个属性

inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 0.8.2 or 0.9.0or 0.10.0 or 0.10.1).
log.message.format.version=CURRENT_KAFKA_VERSION（此参数与升级影响性能有关）

2.一台一台的升级broker，等一台启动完成后再重启另一台

3.等所有broker完成代码升级后，将所有broker 的inter.broker.protocol.version= 0.10.2。

4.如果之前消息的格式是0.10.0，将log.message.format.version设置为0.10.2（实际上0.10.2 0.10.1 0.10.0的消息格式是一样的）。如果之前的消息格式低于0.10.0，等所有consumer升级到0.10.0.0或之后版本完成之前不要修改此值。

5.依次重启所有broker，以使新的协议生效

6.一旦所有consumer都升级到0.10.0.0，修改log.message.format.version为0.10.0.0，然后依次升级。

升级0.10.1 的kafka stream：

Streams 应用由0.10.1升级到0.10.2，broker可以不用升级。因为0.10.2的stream可以跟0.10.1或0.10.2通信（但是不能与0.10.0的broker升级）。
需要重新编译代码，紧紧替换jar包是不行的。
如果你是要了传统的timestamp抽取器（用户自己实现的），你需要升级下代码，因为 TimestampExtractor接口已经升级了。
如果你注册了custom metrics，你需要升级下代码，因为 StreamsMetric 接口已经升级了。
更多变化参考http://kafka.apache.org/10/documentation/streams/upgrade-guide#streams_api_changes_0102

0.10.2.1的重大变化：

为提高kafka stream应用的弹性，streamsconfig类的两个配置默认值进行了修改。内部kafka stream producer的 retries默认值从0修改为10。内部的kakfa stream consumers max.poll.interval.ms 默认值从3000修改为 Integer.MAX_VALUE。

0.10.2.0的重大变化：

0.10.2.0版本启动的客户端（producer和consuemr）现在可以跟老版本的broker通信。0.10.2的客户端可以跟0.10.0之后的broker通信。需要注意的是，当使用老的broker时某些特性可能不能用或者受限制。
java consumer的某些方法在调用被中断时会抛出中断异常。更多细节请参阅KafkaConsumer的javadoc。
java consumer现在是gracefully的关闭。默认的，consumer会等待30秒完成缓冲中的请求。 KafkaConsumer中增加了一个带有超时时间的新的差不多的API，指定最大的等待时间。
使用新consumer的MirrorMake现在可以使用逗号分隔的多个正则表达式来指定withelist选项。这与使用老scala consumer的MirrorMake行为保持了一致。
stream api现在不再依赖zookeeper。现在stream使用kafka管理内部的topic, 而不是直接修改zookeeper。StreamsConfig.ZOOKEEPER_CONFIG 也不再需要设置。如果kafka集群是安全的，stream app必须有必要的权限新建topic。
"security.protocol", "connections.max.idle.ms", "retry.backoff.ms", "reconnect.backoff.ms" 和 "request.timeout.ms"等新字段被增加到stream config类里。用户需要研究下默认值，决定是否需要。更多细节参考http://kafka.apache.org/10/documentation/#streamsconfigs。

新的通信协议：

如果topic array设置为null，OffsetFetchRequest v2支持检索所有topics 的offset。
OffsetFetchResponse v2引入了一个最高级别的错误码 error_code字段。
UpdateMetadataRequest v3在end_points array中引入了一个字段listener_name 。
CreateTopicsRequest v1引入了一个字段 validate_only。
CreateTopicsResponse v1在topic_errors array中引入了一个字段error_message。

4. 0.10.1.0

0.10.1.0网络协议发生了一些变化。需要注意下升级可能带来的不兼容的变化。

升级步骤：

同升级到0.10.0.0的方法。

不兼容变化：

log的rentention time 不再基于log segment文件的最后修改时间，而是基于log segment文件中的消息里的最大的时间戳。
log的rolling滚动时间不再基于log segment文件的创建时间，而是基于messgae的时间戳。具体来说，如果某个segment文件的第一条消息的时间戳为T，那么当接收到一条新消息，并且时间戳大于T+ log.roll.ms时，才会发生roll。
0.10.0的open file handlers将会增加33%，因此要为每个segment文件维护一个time index的文件。
time index文件和普通index共用index size的配置，由于time index 的大小是普通index的1.5左右，所以为避免频繁roll文件，可能需要调整 log.index.size.max.bytes 。
由于新增加了时间time index文件，因此某些broker上在启动时可能会由于load过程而启动时间变长，根据我们的经验，将num.recovery.threads.per.data.dir设置为1可能减少log数据文件load时间。

kafka stream从0.10.0升级到0.10.1：

0.10.1 版本的kafka stream应用只支持0.10.1的broker。并且stream api做了一些不支持0.10.0的变化，所以需要重新编译代码，而不是仅仅将stream的jar替换下版本。

重大变化：

新版本的java consumer不再是beta测试，推荐开发使用此consumer。老的scala consumer仍然支持，但未来版本将被弃用。
在console consumer或MirrorMake使用中，无需通过 --new-consumer/--new.consumer来制定使用新consumer，只需要通过kafka broker连接kafka，代替之前使用zookeeper连接即可。
kafka集群现在可用过唯一标识id标识。当broker升为0.10.1.0之后，就会自动生成这个id。这个id可以通过kafka.server:type=KafkaServer,name=ClusterId 获取，他是源数据的一部分。客户端拦截器和度量记录器可通过实现ClusterResourceListener接口来接收集群ID。
BrokerState "RunningAsController" (值为 4) 已被移除。由于一个bug，brpker仅在转换出来之前处于这种状态，因此移除影响应该是最小的。推荐通过 controller:type=KafkaController,name=ActiveControllerCount获取metrics检查给定的broker是否是controller。
新的consumer允许通过timestamp获取每个分区的offset。
新的consumer支持通过后台线程做心跳检测。新增了一个配置， max.poll.interval.ms ，此配置决定了一个consumer 进行心跳poll的最大时间间隔（默认5分钟），这也决定了consumer离开group的时间。因此 request.timeout.ms 必须总是大于max.poll.interval.ms ，因为在consumer rebalancing 之时，joingroup的请求必须要一直在server端block住，session.timeout.ms 应该被调整到10秒，默认的max.poll.records 被调整为500秒。
在使用了 Authorizer，但用户并未对某个topic描述授权时，为防止泄露topic的名称，broker不会返回TOPIC_AUTHORIZATION_FAILED错误，而是返回一个UNKNOWN_TOPIC_OR_PARTITION错误。这可能会导致procuer或consumer产生一些意外超时或延迟，因为kafka 客户端在遇到未知topic错误时会自动尝试。如果你怀疑发生了这张情况的话，需要查阅client的日志。
Fetch responses会有默认的一个大小限制（cosumer进程是50MB，replication是10MB）。现有的每个分区的限制也会生效（consumer和replication都是1MB）。注意这些限制都不是绝对的最大值。
如果一个消息大于reponse或者分区大小限制，consumer和replication仍可以使用他。具体来讲，如果在第一个非空的分区中的第一条消息大于这些限制时，消息仍可以被返回。
kafka.api.FetchRequest 和 kafka.javaapi.FetchRequest中增加了重构的构造函数，调用时可以指定分区的顺序（v3中顺序很重要）。之前存在的构造函数会被弃用，为避免发生饥饿，在request发送之前，分区会被洗牌。

新的通信协议：

ListOffsetRequest v1支持基于时间戳的精确offset查找。
MetadataResponse v2 引入了一个新的字段"cluster_id"。
（除了已有的每个分区限制之外）FetchRequest v3 还支持限制response的大小。如果增大此值，将会返回的比之前限制大的消息，并且限制request中分区的顺序很重要。
JoinGroup v1 引入了新的字段 rebalance_timeout。

5. 0.10.0.0

升级0.10也会带来一些不兼容和性能影响。采用推荐的rolling update方案，可以确保不停机，并不对性能造成影响。

注：由于通信协议采用新协议，因此要在升级新版本client之前升级kafka的集群。

注：由于0.9.0.0引入的一个bug，因此这个版本依赖于zookeeper的consumer(老版本的scala high-lever consumer和采用old consumer的MirrorMaker) 将与0.10.0.x版本的broker不兼容，因此升级kafka集群之前，要将client端的consumer升至0.9.0.1.(0.8.0.x版本和 0.9.0.1版本的consumer是兼容的)。

升级步骤：

rolling upgrade

1.更新所有broker的server.properties，修改下列两个属性

inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 0.8.2 or 0.9.0.0).
log.message.format.version=CURRENT_KAFKA_VERSION（此参数与升级影响性能有关）

2.一台一台的升级broker，等一台启动完成后再重启另一台

3.等所有broker完成代码升级后，将所有broker 的inter.broker.protocol.version= 0.10.0.0。

注意： log.message.format.version 只能在所有consumer都升级到0.10.0.0版本后才能修改为0.10.0.0。

4.依次重启所有broker，以使新的协议生效

5.一旦所有consumer都升级到0.10.0.0，修改log.message.format.version为0.10.0.0，然后依次升级。

升级0.10.0.0 可能带来的性能影响：

0.10.0版本的消息格式增加了一个新的timestamp的字段，并且压缩消息采用相对offset。存放在磁盘上的消息格式可以通过log.message.format.version指定。默认值为0.10.0。0.10.0.0之前版本的consumer只能识别之前版本的格式的消息。这种情况下，broker能将0.10.0的消息转为较早版本的格式。但这种情况下broker无法使用zero-copy技术传输数据。kafka官方的性能影响报告中显示升级后CPU的使用率从20%升级到100%，为了恢复正常性能，只能将所有client端跟着进行升级。在consumer升级到0.10.0.0，可以通过设置参数log.message.format.version为 0.8.2 或 0.9.0 避免这种转换。这样，broker依旧可以使用zero-copy技术传输数据到老的consumer。在consumer升级完成后，broker就可以log.message.format.version设为 0.10.0了，这样就可以使用带有新的timestamp格式和优化的压缩方式的消息了。

broker所做的这个转换，是为了兼容那些少部分的未升级的consumer,但却不适用与支持所有consumer,即使此集群资源充足，因此要尽量避免升级中用到这个转换特性。

注意：设置log.message.format.version时后，要确保所有已存在的消息或低于此版本或高于此版本。否则的话，0.10.0.0之前版本的consumer可能无法正常工作。尤其需要注意，在将消息版本设置为0.10.0之后，不要试图再改为旧版本，这样做会是0.10.0.0之前的consumer无法正常工作。

注意：由于增加了timestamp的字段，producer端可能会由于额外的这个负荷增加而发生性能下降。类似的，备份时每条消息也会多传输8字节。如果集群运行接近了网络容量极限时，网卡可能会承受不了，出现一些失败的情况。

注意：如果你在producer端开启了压缩的话，可能会观察到某些情况下吞吐量下降和压缩比下降。0.10.0的broker在接收到压缩消息时，会避免再次压缩，这样一般会降低延迟和提高吞吐量。然而，某些场景下，这样会降低producer端的batch size，从而到底吞吐量下降。如果发生这种情况，用户可以通过调整procuer的inger.ms 和batch.size 来提升吞吐量。另外，snappy格式下producer端使用的压缩缓存比broker端的缓存小，这样会对磁盘上消息的压缩比造成降低。kafka未来版本会尝试解决此问题。

不兼容变化：

从Kafka 0.10.0.0， kafka的版本代表了所支持的最高版本的消息格式。默认值为0.10.0。新增了一个timestamp的字段，并且压缩的消息里增加了一个相对的offset。
新增ProduceRequest/Response v2 、FetchRequest/Response v2 支持0.10.0的消息格式
ProduceRequest/Response v2 has been introduced and it is used by default to support message format 0.10.0
MessageFormatter 接口由def writeTo(key: Array[Byte], value: Array[Byte], output: PrintStream) 改为 def writeTo(consumerRecord: ConsumerRecord[Array[Byte], Array[Byte]], output: PrintStream)
MessageReader 接口由def readMessage(): KeyedMessage[Array[Byte], Array[Byte]] to def readMessage(): ProducerRecord[Array[Byte], Array[Byte]]
MessageFormatter、MessageReader 的包名由kafka.tools 改为kafka.common
MirrorMakerMessageHandler不再将方法 handle(record: MessageAndMetadata[Array[Byte], Array[Byte]]) 暴漏出去，实际上也不会被调用
0.7 的 KafkaMigrationTool工具并没有跟kafka一起打包发布，如果需要从0.7迁移集群到0.10.0，请先升级到0.8，再按照升级步骤从0.8升级到0.10
新的consumer接口API接收java.util.Collection作为标准参数，因此为了能在0.10.0下工作，原有consumer代码可能需要进行改动。
LZ4格式的压缩消息现在采用了LZ4f v1.5.1版本。为了兼容老版本，这一变化只应用于0.10.0的消息上。采用v0/v1版本协议的client端使用LZ4压缩格式消息时（v0/v1版本，消息格式为0.9.0）应该继续使用0.9.0的框架实现。使用v2及之后Produce/Fetch协议的需要使用LZ4f v1.5.1。

重大变化：

从0.10.0.0开始，kafka stream client可用于流式处理kafka topic上的消息。由于消息格式的变化，因此此client只能在0.10.x系列以上版本的broker上生效。
新consumerreceive.buffer.bytes 默认值现在为64K
新consumer暴漏了参数exclude.internal.topics系防止一些内部topics（比如consumer offsets topic)会在使用正则表达式订阅topic时偶然得被订阅到。默认值是enable，开启此功能的。
不再建议使用老的scala producer。用户应该尽快迁移到kafka-clients jar中提供的Java producer上。
新的consumer api被认为可稳定使用。

6. 0.9.0.0

0.9x系列版本是一个变动较大的版本。同时带来一些不能兼容老版本的变化。如broker之间的通信协议采用了全新的设计，不再支持jdk1.6等等。

升级步骤：

平滑升级

1.更新所有broker的server.properties，添加一个属性inter.broker.protocol.version=0.8.2.X

2.一台一台的升级broker，等一台启动完成后再重启另一台

3.等所有broker完成代码升级后，将所有broker 的inter.broker.protocol.version=0.9.0.0

4.依次重启所有broker

如果容忍集群完全停机升级，则可全部杀掉，更新配合和代码，再重启集群

升级带来的不兼容

1.不再支持java1.6 scale2.9

2.brokerid 现在1000以上的都是默认的保留id,留给分配给不设置id的broker。可通过设置reserved.broker.max.id属性修改保留id的下限值

3.移除replica.lag.max.messages配置，现在leader在决策follower是否处于同步时，不再依据落后的消息数

4.现在leader在决策follower是否处于同步时，replica.lag.time.max.ms 不仅仅作用于replica fetch leader的时间，还将考虑replica catch up leader的时间，这些时间差都要满足小于replica.lag.time.max.ms，才被认为处于同步状态

5. 0.9 compact的topic不再接受没有key的消息，并抛出异常（0.8只是后台压缩线程提示）

6.MirrorMaker不再支持从source集群镜像数据到多个目标集群，如果要复制多个soure集群，那么至少为每个source指定一个MirrorMaker实例

7.默认的kafka JVM 选项KAFKA_JVM_PERFORMANCE_OPTS在kafka-run-class.sh脚本发生了变化

8.kafka-console-producer.sh默认不再使用scala的producer，而是使用java producer.除非指定‘old-producer’

重大变化

1.可使用broker.id.generation.enable=false禁用新的broker id生成功能

2.log.cleaner.enable默认为true

3.new consumer的fetch.min.bytes默认为1

废弃特性

1.不再使用kafka-topics.sh alter一个topic，而是换成了kafka-configs.sh

2.移除使用kafka-consumer-offset-checker.sh查看consumer的offset，请使用kafka-consumer-groups.sh

3.org.apache.kafka.tools.ProducerPerformance代替kafka.tools.ProducerPerformance

Kafka 0.8.2.1版本之后Release Note重点

猜你喜欢