二、开源版本功能缺陷
RTMP协议主要的特点有：多路复用，分包和应用层协议。以下将对这些特点进行详细的描述。
2.1 副本迁移
无法实现增量迁移；【我们已经基于2.1.1版本源码改造，实现了增量迁移】无法实现并发迁移；【开源版本直到2.6.0才实现了并发迁移】无法实现终止迁移；【我们已经基于2.1.1版本源码改造，实现了终止副本迁移】【开源版本直到2.6.0才实现了暂停迁移，和终止迁移有些不一样，不会回滚元数据】当指定迁移数据目录时，迁移过程中，如果把topic保留时间改短，topic保留时间针对正在迁移topic分区不生效，topic分区过期数据无法删除；【开源版本bug，目前还没有修复】当指定迁移数据目录时，当迁移计划为以下场景时，整个迁移任务无法完成迁移，一直处于卡死状态；【开源版本bug，目前还没有修复】迁移过程中，如果有重启broker节点，那个broker节点上的所有leader分区无法切换回来，导致节点流量全部转移到其他节点，直到所有副本被迁移完毕后leader才会切换回来；【开源版本bug，目前还没有修复】。
在原生的Kafka版本中存在以下指定数据目录场景无法迁移完毕的情况，此版本我们也不决定修复次bug： 1.针对同一个topic分区，如果部分目标副本相比原副本是所属broker发生变化，部分目标副本相比原副本是broker内部所属数据目录发生变化； 那么副本所属broker发生变化的那个目标副本可以正常迁移完毕，目标副本是在broker内部数据目录发生变化的无法正常完成迁移； 但是旧副本依然可以正常提供生产、消费服务，并且不影响下一次迁移任务的提交，下一次迁移任务只需要把此topic分区的副本列表所属broker列表变更后提交依然可以正常完成迁移，并且可以清理掉之前未完成的目标副本； 这里假设topic yyj1的初始化副本分布情况如下： { "version":1, "partitions":[ {"topic":"yyj","partition":0,"replicas":[1000003,1000001],"log_dirs":["/kfk211data/data31","/kfk211data/data13"]} ] } //迁移场景1： { "version":1, "partitions":[ {"topic":"yyj","partition":0,"replicas":[1000003,1000002],"log_dirs":["/kfk211data/data32","/kfk211data/data23"]} ] } //迁移场景2： { "version":1, "partitions":[ {"topic":"yyj","partition":0,"replicas":[1000002,1000001],"log_dirs":["/kfk211data/data22","/kfk211data/data13"]} ] } 针对上述的topic yyj1的分布分布情况，此时如果我们的迁移计划为“迁移场景1”或迁移场景2“，那么都将出现有副本无法迁移完毕的情况。 但是这并不影响旧副本处理生产、消费请求，并且我们可以正常提交其他的迁移任务。 为了清理旧的未迁移完成的副本，我们只需要修改一次迁移计划【新的目标副本列表和当前分区已分配副本列表完全不同即可】，再次提交迁移即可。 这里，我们依然以上述的例子做迁移计划修改如下： { "version":1, "partitions":[ {"topic":"yyj","partition":0,"replicas":[1000004,1000005],"log_dirs":["/kfk211data/data42","/kfk211data/data53"]} ] } 这样我们就可以正常完成迁移。
2.2 流量协议
限流粒度较粗，不够灵活精准，不够智能。
当前限流维度组合
/config/users/<user>/clients/<client-id> /config/users/<user>/clients/<default> /config/users/<user> /config/users/<default>/clients/<client-id> /config/users/<default>/clients/<default> /config/users/<default> /config/clients/<client-id> /config/clients/<default>
存在问题当同一个broker上有多个用户同时进行大量的生产和消费时，想要让broker可以正常运行，那必须在做限流时让所有的用户流量阈值之和不超过broker的吞吐上限；如果超过broker上限，那么broker就存在被打挂的风险；然而，即使用户流量没有达到broker的流量上限，但是，如果所有用户流量集中到了某几块盘上，超过了磁盘的读写负载，也会导致所有生产、消费请求将被阻塞，broker可能处于假死状态。
解决方案
(1)改造源码，实现单个broker流量上限限制，只要流量达到broker上限立即进行限流处理，所有往这个broker写的用户都可以被限制住；或者对用户进行优先级处理，放过高优先级的，限制低优先级的；(2)改造源码，实现broker上单块磁盘流量上限限制（很多时候都是流量集中到某几块磁盘上，导致没有达到broker流量上限却超过了单磁盘读写能力上限），只要磁盘流量达到上限，立即进行限流处理，所有往这个磁盘写的用户都可以被限制住；或者对用户进行优先级处理，放过高优先级的，限制低优先级的；(3)改造源码，实现topic维度限流以及对topic分区的禁写功能；(4)改造源码，实现用户、broker、磁盘、topic等维度组合精准限流；
三、kafka发展趋势
3.1 Kafka社区迭代计划
3.2 逐步弃用ZooKeeper（KIP-500）
3.3 controller与broker分离，引入raft协议作为controller的仲裁机制（KIP-630）
3.4 分层存储（KIP-405）
3.5 可以减少topic分区（KIP-694）
3.6 MirrorMaker2精确一次（KIP-656）
3.7 下载与各版本特性说明
3.8 Kafka所有KIP地址
四、如何贡献社区
4.1 哪些点可以贡献http://kafka.apache.org/contributing
4.2 wiki贡献地址https://cwiki.apache.org/confluence/dashboard.action#all-updates
4.3 issues地址1）https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-10444?filter=allopenissues
2）https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all
4.4 主要committershttp://kafka.apache.org/committers
