|
1.fetch.min.bytes 该属性指定了消费者从服务器获取记录的最小字节数。broker在收到消费者的数据请求时，如果可用的数据量小于fetch.min. bytes指定的大小，那么它会等到有足够的可用数据时才把它返回给消费者。这样可以降低消费者和broker的工作负载，因为它们在主题不是很活跃的时候(或者一天里的低谷时段)就不需要来来回回地处理消息。如果没有很多可用数据，但消费者的CPU使用率却很高，那么就需要把该属性的值设得比默认值大。如果消费者的数量比较多，把该属性的值设置得大一点可以降低broker的工作负载。 2.fetch.max.wait.ms 我们通过fetch.min.bytes告诉Kafka,等到有足够的数据时才把它返回给消费者。而feth.max.wait.ns则用于指定broker的等待时间，默认是500ms。如果没有足够的数据流入Kafka,消费者获取最小数据量的要求就得不到满足，最终导致500ms的延迟。如果要降低潜在的延迟(为了满足SLA)，可以把该参数值设置得小-些。如果fetch.nax.wait.ms被设为100ms,并且fetch,min.bytes被设为1MB，那么Kafka在收到消费者的请求后，要么返回1MB数据，要么在100ms后返回所有可用的数据，就看哪个条件先得到满足。 3.max.partition.fetch.bytes 该属性指定了服务器从每个分区里返回给消费者的最大字节数。它的默认值是1MB，也就是说，KafkaConsumer.poll()方祛从每个分区里返回的记录最多不超过max.partition.fetch.bytes指定的字节。如果一个主题有20个分区和5个消费者，那么每个消费者需要至少4MB的可用内存来接收记录。在为消费者分配内存时，可以给它们多分配一些，因为如果群组里有消费者发生崩溃，剩下的消费者需要处理更多的分区。nax.partition.fetch. bytes的值必须比broker能够接收的最大消息的字节数(通过nax.nessage.size属性配置)大，否则消费者可能无法读取这些消息，导致消费者一直挂起重试。在设置该属属性来控制提交的频率。 7.partition.assignment.strategy 我们知道，分区会被分配给群组里的消费者。PartitionAssignor 根据给定的消费者和主题，决定哪些分区应该被分配给哪个消费者。Kafka有两个默认的分配策略。 Range 该策略会把主题的若干个连续的分区分配给消费者。假设消费者C1和消费者C2同时订阅了主题T1和主题T2，并且每个主题有3个分区。那么消费者C1有可能分配到这两个主题的分区0和分区1, 而消费者C2分配到这两个主题的分区2。因为每个主题拥有奇数个分区，而分配是在主题内独立完成的，第一个消费者最后分配到比第二个消费者更多的分区。只要使用了Range策略，而且分区数量无法被消费者数量整除，就会出现这种情况。 RoundRobin 该策略把主题的所有分区逐个分配给消费者。如果使用RoundRobin策略来给消费者C1和消费者C2分配分区，那么消费者C1将分到主题T1的分区0和分区2以及主题T2的分区1,消费者C2将分配到主题T1的分区1以及主题T2的分区0和分区2。一般来说，如果所有消费者都订阅相同的主题(这种情况很常见)，RoundRobin 策略会给所有消费者分配相同数量的分区(或最多就差-一个分区)。 可以通过设置partition.assignment.strategy来选择分区策略。默认使用的是org.apache.kafka.clients.consuner .RangeAssignor,这个类实现了Range策略，不过也可以把它改成org.apache.kafka.clients.consumer. RoundRobinAssignor。我们还可以使用自定义策略，在这种情况下，partition.assignment.strategy属性的值就是自定义类的名字。 8.client.id 该属性可以是任意字符串，broker 用它来标识从客户端发送过来的消息，通常被用在日志、度量指标和配额里。 9.max.poll.records 该属性用于控制单次调用call()方法能够返回的记录数量，可以帮你控制在轮询里需要处理的数据量。 10.receive.buffer.bytes和send.buffer.bytes socket在读写数据时用到的TCP缓冲区也可以设置大小。如果它们被设为-1，就使用操作系统的默认值。如果生产者或消费者与broker处于不同的数据中心内，可以适当增大这些值，因为跨数据中心的网络一般都有比较高的延迟和比较低的带宽。 |
|
|
