python-kafka学习笔记（二）：kafka配置与传输大文件失败解决

引言

本篇主要想总结一下关于kafka的基本操作，以及当时遇到的一个问题，想要传超过1M以上的信息通过队列。

kafka的基本操作

-- 创建
bin/kafka-topics.sh --create --zookeeper 192.168.1.229:2181 --replication-factor 1 --partitions 1 --topic hello-topic-12
-- 查看
bin/kafka-topics.sh --list --zookeeper 192.168.1.229:2181
bin/kafka-topics.sh --describe --zookeeper 192.168.1.229:2181 --topic hello-topic-12

-- 查看topic列表
bin/kafka-console-producer.sh --broker-list 192.168.1.229:9092 --topic hello-topic-12
-- 消费者
bin/kafka-console-consumer.sh --bootstrap-server 192.168.1.229:9092 --topic hello-topic-12 --from-beginning
-- 删除
bin/kafka-topics.sh --delete --zookeeper 192.168.1.229:2181 --topic hello-topic-12

当然，如果看过kafkamanager的话可以直接在页面上进行操作。对kafka的所有配置进行更改。

kafka配置详解

producer config(生产者配置)

Property	Default	Description
metadata.broker.list		服务于bootstrapping。producer仅用来获取metadata（topics，partitions，replicas）。发送实际数据的socket连接将基于返回的metadata数据信息而建立。格式是： host1：port1，host2：port2 这个列表可以是brokers的子列表或者是一个指向brokers的VIP
request.required.acks	0	此配置是表明当一次produce请求被认为完成时的确认值。特别是，多少个其他brokers必须已经提交了数据到他们的log并且向他们的leader确认了这些信息。典型的值包括： 0： 表示producer从来不等待来自broker的确认信息（和0.7一样的行为）。这个选择提供了最小的时延但同时风险最大（因为当server宕机时，数据将会丢失）。 1：表示获得leader replica已经接收了数据的确认信息。这个选择时延较小同时确保了server确认接收成功。 -1：producer会获得所有同步replicas都收到数据的确认。同时时延最大，然而，这种方式并没有完全消除丢失消息的风险，因为同步replicas的数量可能是1.如果你想确保某些replicas接收到数据，那么你应该在topic-level设置中选项min.insync.replicas设置一下。请阅读一下设计文档，可以获得更深入的讨论。
request.timeout.ms	10000	broker尽力实现request.required.acks需求时的等待时间，否则会发送错误到客户端
producer.type	sync	此选项置顶了消息是否在后台线程中异步发送。正确的值： （1）  async： 异步发送 （2）  sync： 同步发送 通过将producer设置为异步，我们可以批量处理请求（有利于提高吞吐率）但是这也就造成了客户端机器丢掉未发送数据的可能性
serializer.class	kafka.serializer.DefaultEncoder	消息的序列化类别。默认编码器输入一个字节byte[]，然后返回相同的字节byte[]
key.serializer.class		关键字的序列化类。如果没给与这项，默认情况是和消息一致
partitioner.class	kafka.producer.DefaultPartitioner	partitioner 类，用于在subtopics之间划分消息。默认partitioner基于key的hash表
compression.codec	none	此项参数可以设置压缩数据的codec，可选codec为：“none”， “gzip”， “snappy”
compressed.topics	null	此项参数可以设置某些特定的topics是否进行压缩。如果压缩codec是NoCompressCodec之外的codec，则对指定的topics数据应用这些codec。如果压缩topics列表是空，则将特定的压缩codec应用于所有topics。如果压缩的codec是NoCompressionCodec，压缩对所有topics军不可用。
message.send.max.retries	3	此项参数将使producer自动重试失败的发送请求。此项参数将置顶重试的次数。注意：设定非0值将导致重复某些网络错误：引起一条发送并引起确认丢失
retry.backoff.ms	100	在每次重试之前，producer会更新相关topic的metadata，以此进行查看新的leader是否分配好了。因为leader的选择需要一点时间，此选项指定更新metadata之前producer需要等待的时间。
topic.metadata.refresh.interval.ms	600*1000	producer一般会在某些失败的情况下（partition missing，leader不可用等）更新topic的metadata。他将会规律的循环。如果你设置为负值，metadata只有在失败的情况下才更新。如果设置为0，metadata会在每次消息发送后就会更新（不建议这种选择，系统消耗太大）。重要提示： 更新是有在消息发送后才会发生，因此，如果producer从来不发送消息，则metadata从来也不会更新。
queue.buffering.max.ms	5000	当应用async模式时，用户缓存数据的最大时间间隔。例如，设置为100时，将会批量处理100ms之内消息。这将改善吞吐率，但是会增加由于缓存产生的延迟。
queue.buffering.max.messages	10000	当使用async模式时，在在producer必须被阻塞或者数据必须丢失之前，可以缓存到队列中的未发送的最大消息条数
batch.num.messages	200	使用async模式时，可以批量处理消息的最大条数。或者消息数目已到达这个上线或者是queue.buffer.max.ms到达，producer才会处理
send.buffer.bytes	100*1024	socket 写缓存尺寸
client.id	“”	这个client  id是用户特定的字符串，在每次请求中包含用来追踪调用，他应该逻辑上可以确认是那个应用发出了这个请求。

Consumer Config(消费者配置)

Property	Default	Description
group.id		用来唯一标识consumer进程所在组的字符串，如果设置同样的group  id，表示这些processes都是属于同一个consumer  group
zookeeper.connect		指定zookeeper的连接的字符串，格式是hostname：port，此处host和port都是zookeeper server的host和port，为避免某个zookeeper 机器宕机之后失联，你可以指定多个hostname：port，使用逗号作为分隔： hostname1：port1，hostname2：port2，hostname3：port3 可以在zookeeper连接字符串中加入zookeeper的chroot路径，此路径用于存放他自己的数据，方式： hostname1：port1，hostname2：port2，hostname3：port3/chroot/path
consumer.id	null	不需要设置，一般自动产生
socket.timeout.ms	30*100	网络请求的超时限制。真实的超时限制是   max.fetch.wait+socket.timeout.ms
socket.receive.buffer.bytes	64*1024	socket用于接收网络请求的缓存大小
fetch.message.max.bytes	1024*1024	每次fetch请求中，针对每次fetch消息的最大字节数。这些字节将会督导用于每个partition的内存中，因此，此设置将会控制consumer所使用的memory大小。这个fetch请求尺寸必须至少和server允许的最大消息尺寸相等，否则，producer可能发送的消息尺寸大于consumer所能消耗的尺寸。
num.consumer.fetchers	1	用于fetch数据的fetcher线程数
auto.commit.enable	true	如果为真，consumer所fetch的消息的offset将会自动的同步到zookeeper。这项提交的offset将在进程挂掉时，由新的consumer使用
auto.commit.interval.ms	60*1000	consumer向zookeeper提交offset的频率，单位是秒
queued.max.message.chunks	2	用于缓存消息的最大数目，以供consumption。每个chunk必须和fetch.message.max.bytes相同
rebalance.max.retries	4	当新的consumer加入到consumer  group时，consumers集合试图重新平衡分配到每个consumer的partitions数目。如果consumers集合改变了，当分配正在执行时，这个重新平衡会失败并重入
fetch.min.bytes	1	每次fetch请求时，server应该返回的最小字节数。如果没有足够的数据返回，请求会等待，直到足够的数据才会返回。
fetch.wait.max.ms	100	如果没有足够的数据能够满足fetch.min.bytes，则此项配置是指在应答fetch请求之前，server会阻塞的最大时间。
rebalance.backoff.ms	2000	在重试reblance之前backoff时间
refresh.leader.backoff.ms	200	在试图确定某个partition的leader是否失去他的leader地位之前，需要等待的backoff时间
auto.offset.reset	largest	zookeeper中没有初始化的offset时，如果offset是以下值的回应： smallest：自动复位offset为smallest的offset largest：自动复位offset为largest的offset anything  else：向consumer抛出异常
consumer.timeout.ms	-1	如果没有消息可用，即使等待特定的时间之后也没有，则抛出超时异常
exclude.internal.topics	true	是否将内部topics的消息暴露给consumer
paritition.assignment.strategy	range	选择向consumer 流分配partitions的策略，可选值：range，roundrobin
client.id	group id value	是用户特定的字符串，用来在每次请求中帮助跟踪调用。它应该可以逻辑上确认产生这个请求的应用
zookeeper.session.timeout.ms	6000	zookeeper 会话的超时限制。如果consumer在这段时间内没有向zookeeper发送心跳信息，则它会被认为挂掉了，并且reblance将会产生
zookeeper.connection.timeout.ms	6000	客户端在建立通zookeeper连接中的最大等待时间
zookeeper.sync.time.ms	2000	ZK follower可以落后ZK leader的最大时间
offsets.storage	zookeeper	用于存放offsets的地点： zookeeper或者kafka
offset.channel.backoff.ms	1000	重新连接offsets channel或者是重试失败的offset的fetch/commit请求的backoff时间
offsets.channel.socket.timeout.ms	10000	当读取offset的fetch/commit请求回应的socket 超时限制。此超时限制是被consumerMetadata请求用来请求offset管理
offsets.commit.max.retries	5	重试offset commit的次数。这个重试只应用于offset  commits在shut-down之间。他
dual.commit.enabled	true	如果使用“kafka”作为offsets.storage，你可以二次提交offset到zookeeper(还有一次是提交到kafka）。在zookeeper-based的offset  storage到kafka-based的offset storage迁移时，这是必须的。对任意给定的consumer  group来说，比较安全的建议是当完成迁移之后就关闭这个选项
partition.assignment.strategy	range	在“range”和“roundrobin”策略之间选择一种作为分配partitions给consumer 数据流的策略； 循环的partition分配器分配所有可用的partitions以及所有可用consumer  线程。它会将partition循环的分配到consumer线程上。如果所有consumer实例的订阅都是确定的，则partitions的划分是确定的分布。循环分配策略只有在以下条件满足时才可以：（1）每个topic在每个consumer实力上都有同样数量的数据流。（2）订阅的topic的集合对于consumer  group中每个consumer实例来说都是确定的。

引用自：kafka配置参数详解

kafka消息过大处理方式

问题的起因是我在想通过kafka传入大文件比如说图片这种类型，图片大小大概是200k到1M左右，即使是最简单的一个demo：

from confluent_kafka import Producer

##producer配置，dict格式
p = Producer({'bootstrap.servers': '192.168.56.101,192.168.56.103,192.168.56.102'})

##回调函数
def delivery_report(err, msg):
    if err is not None:
        print('Message delivery failed: {}'.format(err))
    else:
        print('Message delivered to {} [{}]'.format(msg.topic(), msg.partition()))

##发送
for data in glob(cv2.imread("....")):
    p.produce('mytopic', pickle.dumps(data), callback=delivery_report)

p.poll(10)  ##等待返回结果最大时常，单位秒
p.flush()

但这里却发现是有问题的。因为会报错为MessageSizeTooLarge，所以这里需要修改一些关于socket以及partition：

max.partition.fetch.bytes

指定了服务器从每个分区里返回给消费者的最大字节数，默认1MB。假设一个主题有20个分区和5个消费者，那么每个消费者至少要有4MB的可用内存来接收记录，而且一旦有消费者崩溃，这个内存还需更大。注意，这个参数要比服务器的message.max.bytes更大，否则消费者可能无法读取消息。

message.max.bytes

这个参数表示单条消息的最大长度。在使用kafka的时候，应该预估单条消息的最大长度，不然导致发送失败。

replica.fetch.max.bytes

broker可复制的消息的最大字节数。这个值应该比message.max.bytes大，否则broker会接收此消息，但无法将此消息复制出去，从而造成数据丢失。