Kafka生产端实际项目中的使用分析 - 编程一生
内容提要
文章介绍Kafka生产端实践：先概述架构与存储原理，分区为文件夹，由稀疏索引与日志文件组成。重点讲两个问题：一是加代理后因元数据返回真实broker地址，导致约1/3消息发送失败，需代理用多IP或改服务端配置；二是切换SASL+SSL加密集群时采用灰度方案，先测测试topic，再双写观察，最后切换，并需压测评估性能下降。
延伸解读
代理通信故障的根源与解决思路
文章指出，加代理后约1/3消息发送失败，是因为Kafka客户端先获取元数据，服务端返回真实broker地址，客户端再直连broker，而代理只映射了端口，导致部分连接被防火墙拦截。解决方案是代理服务器增加虚拟网卡，用三个IP分别代理三个broker。若不改造代理，则需调整服务端配置，使一个topic只有一个partition，且客户端只连接该partition所在服务器。
加密集群灰度上线的关键步骤
切换SASL+SSL加密集群时，文章建议采用灰度方案：先保留原始集群，新建加密集群并设置正式和测试两个topic；先手工发测试数据到测试topic验证连通性；然后开启双写，将数据同时发送到原始集群和加密集群正式topic；并行观察一段时间无问题后，再完全切换到加密集群。这种渐进方式能降低切换风险。
加密带来的性能影响与应对
文章提到，加密Kafka相比普通Kafka性能有明显下降，业界统计SSL认证会增加20%到30%的链路耗时。因此上线前需要压测评估性能，并对数据做抓包比对，检查每个阶段的延迟是否符合预期。这提醒读者在引入加密时，必须将性能损耗纳入容量规划和监控。
Q&A
Kafka生产端发送消息时，物理层是如何找到目标broker的？
生产者先找到相应的集群和对应的leader partition，然后与leader partition所在的broker建立连接并发送消息。
Kafka的partition在物理存储上是什么形式？
每个partition物理上是一个文件夹，相当于将一个巨型文件分成多个大小相等的segment文件。每个segment文件由一个index文件（稀疏索引）和一个数据文件（日志文件）组成。
为什么在Kafka集群前加代理后，会出现约1/3的消息发送失败？
因为客户端与Kafka集群建立连接时，第一步获取元数据信息，服务端返回的是broker的真实地址（node、partition、controller等）。客户端随后用这些真实地址直接连接broker，而不是通过代理。由于代理只映射了端口，客户端连接真实broker时可能被防火墙drop，导致约1/3的消息发送失败。
如何解决Kafka加代理后消息发送失败的问题？
有两种方案：1. 在代理服务器上增加虚拟网卡，使用三个IP来代理，使客户端连接代理IP时能正确转发；2. 如果不改造代理层，可以修改服务端配置，让一个topic只有一个partition，并且客户端只和这个partition所在服务器建立连接。
切换Kafka集群到SASL+SSL加密时，灰度上线方案的具体步骤是什么？
步骤：1. 生产环境保留原始集群，新建加密集群，加密集群包含正式topic和测试topic（测试topic数据丢弃）；2. 先保持发送数据到原始集群不变，手工发测试数据到加密集群的测试topic，验证通信正常；3. 打开开关，将数据同时发送到原始集群和加密集群的正式topic，并行观察一段时间；4. 确认无问题后，切换到只发送到加密集群的正式topic。
Kafka启用SSL加密后对性能有什么影响？需要做什么评估？
加密Kafka和普通Kafka性能上有明显下降，业界统计SSL认证会增加20%到30%的链路耗时。因此需要压测，并对数据做抓包比对，看每一个阶段的延迟是否符合预期。
