云服务器内容精选

  • producer使用建议 同步复制客户端需要配合使用:acks=all 配置发送失败重试:retries=3 发送优化:对于时延敏感的信息,设置linger.ms=0。对于时延不敏感的信息,设置linger.ms在100~1000之间。 生产端的JVM内存要足够,避免内存不足导致发送阻塞。 时间戳设置为与当地时间一致,避免时间戳为未来时间导致消息无法老化。 尽量复用producer,不要频繁创建producer。当producer开启幂等时(生产者客户端3.0及之后的版本默认开启幂等),生产消息会在服务端创建生产者状态对象,若频繁创建producer,会导致服务端创建大量生产者状态对象后无法及时回收,服务端内存占用飙升,进而导致服务端性能急剧下降。如果不需要使用幂等功能,请将“enable.idempotence”设置为“false”。
  • consumer使用建议 consumer的owner线程需确保不会异常退出,避免客户端无法发起消费请求,阻塞消费。 确保处理完消息后再做消息commit,避免业务消息处理失败,无法重新拉取处理失败的消息。 通常不建议对每条消息都进行commit,如果对每条消息都进行了commit,会导致OFFSET_COMMIT请求过多,进而导致CPU使用率过高。例如:如果一个消费请求拉取1000条消息,每条都commit,则commit请求TPS是消费的1000倍,消息体越小,这个比例越大。建议隔一定条数或时间,批量commit,或打开enable.auto.commit,这样设置会存在一个缺点,即在客户端故障时,可能丢失一部分缓存的消费进度,导致重复消费。请根据业务实际情况,设置批量commit。 consumer不能频繁加入和退出group,频繁加入和退出,会导致consumer频繁做rebalance,阻塞消费。 同一消费组内consumer数量不能超过该消费组订阅的分区总数,否则会有consumer拉取不到消息。 consumer需周期poll,维持和server的心跳,避免心跳超时,导致consumer频繁加入和退出,阻塞消费。 consumer拉取的消息本地缓存应有大小限制,避免OOM(Out of Memory)。 consumer session设置为30秒,session.timeout.ms=30000。 Kafka不能保证消费重复的消息,业务侧需保证消息处理的幂等性。 消费线程退出要调用consumer的close方法,避免同一个组的其他消费者阻塞session.timeout.ms的时间。 消费组名称开头不使用特殊字符(如#),使用特殊字符可能会导致 云监控 无法展示此消费组的监控数据。
  • Topic使用建议 配置要求:推荐3副本,同步复制,最小同步副本数为2,且同步副本数不能等于Topic副本数,否则宕机1个副本会导致无法生产消息。 创建方式:支持选择是否开启Kafka自动创建Topic的开关。选择开启后,表示向一个未创建的Topic生产或消费消息时,系统会自动创建此Topic,此Topic的默认参数值如下:分区数为3,副本数为3,老化时间为72小时,不开启同步复制和同步落盘,消息时间戳类型为CreateTime,批处理消息最大值为10485760字节。
  • Kafka客户端参数配置建议 Kafka客户端的配置参数很多,以下提供Producer和Consumer几个常用参数配置。不同版本的Kafka客户端参数名称可能不同,以下配置参数适用于1.1.0及以上版本。其他参数和版本配置,请参考Kafka配置。 表1 Producer参数 参数 默认值 推荐值 说明 acks 1 高可靠:all或者-1 高吞吐:1 收到Server端确认信号个数,表示producer需要收到多少个这样的确认信号,算消息发送成功。acks参数代表了数据备份的可用性。常用选项: acks=0:表示producer不需要等待任何确认收到的信息,副本将立即加到socket buffer并认为已经发送。没有任何保障可以保证此种情况下server已经成功接收数据,同时重试配置不会发生作用(因为客户端不知道是否失败)回馈的offset会总是设置为-1。 acks=1:这意味着至少要等待leader已经成功将数据写入本地log,但是并没有等待所有follower是否成功写入。如果follower没有成功备份数据,而此时leader又无法提供服务,则消息会丢失。 acks=all或者-1:这意味着leader需要等待ISR中所有备份都成功写入日志。只要任何一个备份存活,数据都不会丢失。min.insync.replicas指定必须确认写入才能被认为成功的副本的最小数量。 retries 0 结合实际业务调整 客户端发送消息的重试次数。值大于0时,这些数据发送失败后,客户端会重新发送。 注意,这些重试与客户端接收到发送错误时的重试没有什么不同。允许重试将潜在的改变数据的顺序,如果这两个消息记录都是发送到同一个partition,则第一个消息失败第二个发送成功,则第二条消息会比第一条消息出现要早。 针对网络闪断场景,生产者建议配置重试能力,推荐重试次数retries=3,重试间隔retry.backoff.ms=1000。 request.timeout.ms 30000 结合实际业务调整 设置一个请求最大等待时间(单位为ms),超过这个时间则会抛Timeout异常。 超时时间如果设置大一些,如127000(127秒),高并发的场景中,能减少发送失败的情况。 block.on.buffer.full TRUE TRUE TRUE表示当我们内存用尽时,停止接收新消息记录或者抛出错误。 默认情况下,这个设置为TRUE。然而某些阻塞可能不值得期待,因此立即抛出错误更好。如果设置为false,则producer抛出一个异常错误:BufferExhaustedException batch.size 16384 262144 默认的批量处理消息字节数上限。producer将试图批处理消息记录,以减少请求次数。这将改善client与server之间的性能。不会试图处理大于这个字节数的消息字节数。 发送到brokers的请求将包含多个批量处理,其中会包含对每个partition的一个请求。 较小的批量处理数值比较少用,并且可能降低吞吐量(0则会仅用批量处理)。较大的批量处理数值将会浪费更多内存空间,这样就需要分配特定批量处理数值的内存大小。 buffer.memory 33554432 67108864 producer可以用来缓存数据的内存大小。如果数据产生速度大于向broker发送的速度,producer会阻塞或者抛出异常,以“block.on.buffer.full”来表明。 这项设置将和producer能够使用的总内存相关,但并不是一个硬性的限制,因为不是producer使用的所有内存都是用于缓存。一些额外的内存会用于压缩(如果引入压缩机制),同样还有一些用于维护请求。 表2 Consumer参数 参数 默认值 推荐值 说明 auto.commit.enable TRUE FALSE 如果为真,consumer所fetch的消息的offset将会自动的同步到zookeeper。这项提交的offset将在进程无法提供服务时,由新的consumer使用。 约束: 设置为false后,需要先成功消费再提交,这样可以避免消息丢失。 auto.offset.reset latest earliest 没有初始化offset或者offset被删除时,可以设置以下值: earliest:自动复位offset为最早 latest:自动复位offset为最新 none:如果没有发现offset,则向消费者抛出异常 anything else:向消费者抛出异常。 说明: 如果将此配置设置为latest,新增分区时,生产者可能会在消费者重置初始偏移量之前开始向新增加的分区发送消息,从而导致部分消息丢失。 connections.max.idle.ms 600000 30000 空连接的超时时间(单位为ms),设置为30000可以在网络异常场景下减少请求卡顿的时间。 父主题: 配置Kafka客户端