2.kafka使用规范

kafka功能描述：

kafka功能	kafka功能解释
Producer API	生产者API允许应用程序将数据流发送到Kafka集群中的主题
Consumer API	消费者API允许应用程序从Kafka集群中的主题读取数据流
Streams API	kafka流式计算相关功能
Connector API	连接器不断地从某些源数据系统拉入Kafka或从Kafka推入某些接收器数据系统
Admin API	权限控制相关

Broker设置规范
delete.topic.enable设置规范
             【建议】建议设置delete.topic.enable=true 默认值false
                  场景描述：有时候为解决问题需要删除topic，但是默认delete.topic.enable=false，topic删除只是标记删除，不能测试删除，设置delete.topic.enable=true可以删除topic。
log.dirs设置规范
             【建议】建议设置log.dirs 设置合理的目录
log.retention.hours设置规范
             【建议】建议设置log.retention.hours 默认值168小时
                   场景描述：这个值不应该改动，如果需要设置最好单独对topic的日志保存时间设置（需要根据业务特点决定）
num.io.threads设置规范
             【建议】建议设置num.io.threads默认值8
                   场景描述：num.io.threads数目设置为cpu核数2倍，防止iowait的时候并发不够。
num.replica.fetchers设置规范
              【建议】建议num.replica.fetchers设置不变
                   场景描述：如果broker之间数据同步经常延时，应该先考虑网络和磁盘瓶颈，后续可以考虑加大此线程数。
num.partitions设置规范
              【建议】建议num.partitions默认分区大于2
                      场景描述：如果使用kafka的消费者大部分都是2个节点可以设置默认值为2个分区，如果某个topic有很多消费者，需要扩容分区数目。
broker.id设置规范
              【建议】全局唯一ID
log.retention.hours设置规范
              【建议】要大于topic的retention.ms设置时间
【建议】如果动态改动配置且参数是全局参数，须写入对应配置文件
【建议】broker参考表 列举所有关于broker参数配置

Topic使用规范
delete.retention.ms设置规范
         【建议】建议设置值在业务有效期内  默认值86400000ms
              场景描述：
                 压缩日志删除时间，当业务有效时间已过，就可以考虑清楚掉压缩日志，具体值看业务有效期，比如订单30分钟关闭，这个有效期可以设置大于等于30分钟。
max.message.bytes设置规范   
          【建议】如果kafka单条消息size过大，建议关注此指标   默认值1,000,000 byte   
                 场景描述：Kafka允许的最大记录批次大小，如果kafka单条消息size过大，导致拉取的数目过下，消费效率低，可以调整此值。
retention.bytes设置规范
          【建议】根据业务有效时间内预估日志尺寸  默认值 无
                 场景描述： 删除日志之前，日志所能达到的最大尺寸。
retention.ms设置规范  
          【建议】根据 预估业务有效时间合理设置 默认值7days
                  场景描述：删除日志之前，日志所保存最大时间。
segment.bytes设置规范
           【建议】log文件强拆参数不变化  默认值1G
                  场景描述：如果kafka集群经常有已消费的垃圾消息，可以考虑降低此值
topic副本数修改规范
           【建议】不同业务对消息可靠性和并发性要求不一致，topic副本数建议不低于1，加大副本数可以增强系统的可靠性，但是降低系统的并发。
                     副本扩容流程：副本扩容方案
topic分区修改规范       
          【建议】topic分区数建议高于未来3年业务最大并发消费者数量
                  场景描述：比如未来可能需要5台消费者，topic分区数应该设置为5
                  分区扩容流程：分区扩容方案
如何查看当前topic配置
          【查询方法】
                静态配置：conf目录下文件参数
                动态配置：通过kafka-configs.sh查看topic配置参数，如果是are代表和系统文件配置一致，否则就是动态配置
topic参考表 列举所有关于topic参数配置

     
Producer使用规范
acks设置规范
         【建议】在性能和可靠性之间做权衡  默认值1
              场景描述：
                 容许消息丢弃：   日志类消息可以容许丢弃的且比较关注性能的场景、程序有重发补偿机制的应用的场景 acks可以设置为0。
                 半容忍消息丢弃：对消息丢失能容忍且不希望消息丢弃且关注性能的场景、程序无重发补偿机制的应用场景  acks可以设置为1。
                 零容忍消息丢弃：对消息丢失零容忍、程序无重发补偿机制的应用  acks可以设置为all。
buffer.memory设置规范   
          【建议】根据每个业务需求及未来规划压测得出适合项目场景的值 默认值33554432k   
                 场景描述：如果项目是日志采集类的应用，buffer.memory要设置大点，这样就不会导致因为Sender未来及发消息导致，缓存被沾满导致发送消息被阻塞。
linger.ms 发送延时设置规范
           【建议】根据每个业务延迟及集群负载综合考虑  默认值0
                  场景描述：当超时batch.size不足也会提交，对batch.size在时间上做个兜底。
max.request.size设置规范
            【建议】根据最大单条消息大小设置  默认值1028576k
                  场景描述：如果单条待发送消息比较大，要同步调大batch.size、buffer.memory、max.request.size 需要关注JVM情况
partitioner.class使用规范
           【建议】如果客户端发送消息需要到指定规则的分区需实现Partitioner.class  默认值org.apache.kafka.clients.producer.internals.DefaultPartitioner
                  场景描述： 比如kafka想实现有序消息可以重写Partitioner.class指定到某一个分区，这样就实现了有序消息，但是牺牲并发。
【建议】程序JVM保证够防止因为内存不足导致发送阻塞       
【建议】producer参考表 列举所有关于生产者参数配置
         

Consumer使用规范
group.id命名规范
          【建议】命名最好贴近业务域范围命名
                 场景描述：比如针对订单toipc消费，有的消费维度为支付组ID，有的消费维度为配送组ID
enable.auto.commit设置规范   可选值：true、false
          【建议】如果对消息精确控制建议手动提交  默认值：true
                 场景描述：比如金融场景每笔扣款是否执行是很关键，因此需要精确控制每笔扣款是否已经被执行。
auto.commit.interval.ms设置规范   
          【建议】在zk提交offset频率  默认60*1000ms
                 场景描述：参数设置过大当分区rebalance加大重复消费概率影响，因为kafka一个消费者独占一个分区，当分区rebalance，offset未提交。如果，设置过小，对zk造成一定压力，kafka系统速率会变大。
session.timeout.ms设置规范
          【建议】在zk提交offset频率  默认60*1000ms
                 场景描述：参数设置过大当分区rebalance加大重复消费概率影响，因为kafka一个消费者独占一个分区，当分区rebalance，offset未提交。如果，设置过小，对zk造成一定压力，kafka系统速率会变大。
key.deserializer、value.deserializer序列化设规范
         【建议】建议使用kafka默认配置选项   默认选择：StringDeserializer、 StringSerializer
                 场景描述：如果公司定制自己的序列化规则，kafka支持数据格式定义。
heartbeat.interval.ms 客户端心跳设置规范  
        【建议】使用默认值，如果需要定制，用试验数据测试为准  默认值：30000ms
auto.offset.reset  可选值：latest、earliest、none
         【建议】earliest可能重复消费，largest可能丢消息  默认值：latest
max.poll.records  最大拉取记录数   可选值范围：0-int.max 
         【建议】建议改动，综合考虑jvm与拉取效率，通过实验获取最优值
消费线程退出规范
           【建议】
                  正常消费退出：确保consumer拉取消费线程被阻塞，防止第一次拉取消息后，消费线程退出
                  异常消费退出：确保consumer消费过程中，不会应为消费异常，导致拉取kafka消息线程退出
消费过程中防止消息丢失
            【建议】
                   串行消费：消息消费完毕在commit，防止消息处理失败，无法拉取消息
                   并行消费：此处需要有消息重发机制保证，消息在kafka端丢失无需理会
保证consumer不会频繁的进出group，会导致consumer频繁做rebalance阻塞消费
             【影响点】
                    1.0 数据重复消费: 消费过的数据由于提交offset任务也会失败，在partition被分配给其他消费者的时候，会造成重复消费，数据重复且增加集群压力
                    2.0 Rebalance扩散到整个ConsumerGroup的所有消费者，因为一个消费者的退出，导致整个Group进行了Rebalance，并在一个比较慢的时间内达到稳定状态，影响面较大
                    3.0 频繁的Rebalance反而降低了消息的消费速度，大部分时间都在重复消费和Rebalance
                    4.0 数据不能及时消费，会累积lag，在Kafka的TTL之后会丢弃数据
              【导致rebalance原因】
                    心跳及session： session.timeout.ms（设置过小）、heartbeat.interval.ms（设置过大）
                    客户端消费超时：max.poll.interval.ms（拉取时间间隔默认5分钟，设置过大导致拉取慢，过小导致rebalace，kafka版本0.10.0.0开始支撑）、max.poll.records（最大拉取条数）
保证合理的分区数
          【影响点】
                 1.0 分区数过小： 分区数小于consumer导致kafka部分consumer无法同时消费
                 2.0 分区数过大：可能导致Map failed（虚拟内存不足）问题
consumer拉取消息应该控制拉取消息的大小，时间间隔，及缓存大小
              【影响点】
                    1.0  消息大小：  max.poll.records拉取消息太大导致程序OOM
                    2.0  时间间隔： max.poll.interval.ms导致消费者被集群踢掉 
【建议】kafka无法保证重复消费消息，业务如果有杜绝重复消费的需求需要处理
【建议】Consumer参考表  列举所有关于消费者参数配置

 参考文档