调节kafka消费信息的⼤⼩
Kafka设计的初衷是迅速处理短⼩的消息，⼀般10K⼤⼩的消息吞吐性能最好（可参见LinkedIn的kafka性能测试）。但有时候，我们需要处理更⼤的消息，⽐如XML⽂档或JSON内容，⼀个消息差不多有10-100M，这种情况下，Kakfa应该如何处理？
针对这个问题，有以下⼏个建议：
1. 最好的⽅法是不直接传送这些⼤的数据。如果有共享存储，如NAS, HDFS, S3等，可以把这些⼤的⽂件存放到共享存储，然后使⽤
Kafka来传送⽂件的位置信息。
2. 第⼆个⽅法是，将⼤的消息数据切⽚或切块，在⽣产端将数据切⽚为10K⼤⼩，使⽤分区主键确保⼀个⼤消息的所有部分会被发送到
同⼀个kafka分区（这样每⼀部分的拆分顺序得以保留），如此以来，当消费端使⽤时会将这些部分重新还原为原始的消息。
3. 第三，Kafka的⽣产端可以压缩消息，如果原始消息是XML，当通过压缩之后，消息可能会变得不那么⼤。在⽣产端的配置参数中使
⽤dec和pics可以开启压缩功能，压缩算法可以使⽤GZip或Snappy。
不过如果上述⽅法都不是你需要的，⽽你最终还是希望传送⼤的消息，那么，则可以在kafka中设置下⾯⼀些参数：
broker 配置:
message.max.bytes (默认:1000000) – broker能接收消息的最⼤字节数，这个值应该⽐消费端的ssage.max.bytes更⼩才对，否则broker就会因为消费端⽆法使⽤这个消息⽽挂起。
log.segment.bytes (默认: 1GB) – kafka数据⽂件的⼤⼩，确保这个数值⼤于⼀个消息的长度。⼀般说来使⽤默认值即可（⼀般⼀个消息很难⼤于1G，因为这是⼀个消息系统，⽽不是⽂件系统）。
replica.fetch.max.bytes (默认: 1MB) – broker可复制的消息的最⼤字节数。这个值应该⽐message.max.bytes⼤，否则broker会接收此消息，但⽆法将此消息复制出去，从⽽造成数据丢失。
Consumer 配置:
所以，如果你⼀定要选择kafka来传送⼤的消息，还有些事项需要考虑。要传送⼤的消息，不是当出现问题之后再来考虑如何解决，⽽是在⼀开始设计的时候，就要考虑到⼤消息对集和主题的影响。
性能: 根据前⾯提到的性能测试，kafka在消息为10K时吞吐量达到最⼤，更⼤的消息会降低吞吐量，在设计集的容量时，尤其要考虑这点。
kafka为什么那么快可⽤的内存和分区数：Brokers会为每个分区分配replica.fetch.max.bytes参数指定的内存空间，假设replica.fetch.max.bytes=1M，且有1000个分区，则需要差不多1G的内存，确保分区数*最⼤的消息不会超过服务器的内存，否则会报OOM错误。同样地，消费端的ssage.max.bytes指定了最⼤消息需要的内存空间，同样，分区数*最⼤需要内存空间不能超过服务器的内存。所以，如果你有⼤的消息要传送，则在内存⼀定的情况下，只能使⽤较少的分区数或者使⽤更⼤内存的服务器。
垃圾回收：到现在为⽌，我在kafka的使⽤中还没发现过此问题，但这应该是⼀个需要考虑的潜在问题。更⼤的消息会让GC的时间更长（因为broker需要分配更⼤的块），随时关注GC的⽇志和服务器的⽇志信息。如果长时间的GC导致kafka丢失了zookeeper的会话，则需要配置zookeeper.session.timeout.ms参数为更⼤的超时时间。
⼀切的⼀切，都需要在权衡利弊之后，再决定选⽤哪个最合适的⽅案。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。