kafka问题总结与优化

​​​​​​​​​​​​​​

总结：kafka
第一，怎么解决kafka日志文件占磁盘空间过大的问题
    1）配置文件：producer.properties
        参数：
            compression.codec：//是否压缩,0代表不压缩,1代表用gzip压缩,2代表用snappy压缩  
            compressed.topics：//如果要压缩消息，这里指定哪些topic要压缩消息，默认是empty，表示不压缩   
    2）配置文件：server.properties
            message.max.bytes 大小，同时保证这个值小于  replica.fetch.max.bytes 这个参数值
    3）配置文件：consumer.properties  
            fetch.message.max.bytes 大小，保证它大于message.max.bytes.
    4）可以缩短日志存活时间，可以把默认的7天改成三天
        log.retention.hours=72 ///定义日志保留时间
        log.cleaner.enable=false//开启日志压缩        
第二，怎么解决kafka消息过大，Message Size Too Large Exception，造成的堵塞问题。
        1)message.max.bytes    //服务器可以接收到的最大的消息大小。
            注意:此参数要和consumer的maximum.message.size大小一致，否则会因为生产者生产的消息太大导致消费者无法消费。
        2)fetch.message.max.bytes // 查询topic-partition时允许的最大消息大小。
            consumer会为每个partition缓存此大小的消息到内存，因此，
            这个参数可以控制consumer的内存使用量。这个值应该至少比server允许的最大消息大小大，
            以免producer发送的消息大于consumer允许的消息.
        3)    producer 主要参数设置
            (1)设置：buffer.memory
                该参数用于指定Producer端用于缓存消息的缓冲区大小，单位为字节，默认值为：33554432合计为32M。
                kafka采用的是异步发送的消息架构，prducer启动时会首先创建一块内存缓冲区用于保存待发送的消息
                ，然后由一个专属线程负责从缓冲区读取消息进行真正的发送。

            推荐：
                消息持续发送过程中，当缓冲区被填满后，producer立即进入阻塞状态直到空闲内存被释放出来，
                这段时间不能超过max.blocks.ms设置的值，一旦超过，producer则会抛出TimeoutException 异常，
                因为Producer是线程安全的，若一直报TimeoutException，需要考虑调高buffer.memory 了。
                用户在使用多个线程共享kafka producer时，很容易把 buffer.memory 打满

            (2)batch.size  //batch 越小，producer的吞吐量越低，越大，吞吐量越大
                producer都是按照batch进行发送的，因此batch大小的选择对于producer性能至关重要。
                producer会把发往同一分区的多条消息封装进一个batch中，当batch满了后，producer才会把消息发送出去。
                但是也不一定等到满了，这和另外一个参数linger.ms有关。默认值为16K，合计为16384.
            (3)linger.ms   //为了减少了网络IO，提升了整体的TPS。假设设置linger.ms=5，表示producer请求
                            可能会延时5ms才会被发送。
                producer是按照batch进行发送的，但是还要看linger.ms的值，默认是0，表示不做停留。
                这种情况下，可能有的batch中没有包含足够多的produce请求就被发送出去了，造成了大量的小batch，
                给网络IO带来的极大的压力。
        4) 生产者在发送消息时使用：Exactly once semantics（精确一次语义）
        5) 根据实际情况更改分区数，最好是根据服务器核数建分区的数据量，这样可以达到高吞吐量
三，如果发现kafka运行中发生数据丢失，如何定位是哪个环节发生的丢失？如何解决？怎样配置参数能够尽量避免数据丢失的问题
        1)定位数据丢失环节：
            定位数据是否在kafka之前就已经丢失还事消费端丢失数据的
            kafka支持数据的重新回放功能(换个消费group)，清空目的端所有数据，重新消费。
            如果是在消费端丢失数据，那么多次消费结果完全一模一样的几率很低。
            如果是在写入端丢失数据，那么每次结果应该完全一样(在写入端没有问题的前提下)
        2)解决办法：
            （1）如果是网络负载很高或者磁盘很忙写入失败的情况下，没有自动重试重发消息。
                 没有做限速处理，超出了网络带宽限速。kafka一定要配置上消息重试的机制，
                 并且重试的时间间隔一定要长一些，默认1秒钟并不符合生产环境（网络中断时间有可能超过1秒）
            （2）将大的消息数据切片或切块，在生产端将数据切片为10K大小，
                 使用分区主键确保一个大消息的所有部分会被发送到同一个kafka分区（这样每一部分的拆分顺序得以保留），
                 如此以来，当消费端使用时会将这些部分重新还原为原始的消息
        3）    设置acks参数值：最好是设置为all，等所有副本数据备份到日志中，再ack确认。
            （1）并且引入ISR机制，同步进行的则与leader一组，当leader挂掉后从ISR里选举leader。
                 1.1需要配置min.insync.replicas最少大于1，可以指定ISR机制正常执行
                 1.2如果当所有副本挂掉，选择第一个活过来的副本成为leader
                    unclean.leader.election.enable=true//指明了是否能够使不在ISR中replicas设置用来作为leader
                 1.3replica.lag.time.max.ms   默认值：10000
                    如果一个follower在这个时间内没有发送fetch请求，leader将从ISR中移除这个follower

---