1、kafka集群分裂

问题现象：

Kafka集群部署完成启动或重启后出现集群分裂（即一个集群分裂成两个，如三节点集群其中两节点为一组，另一个单节点为一组），也可理解成多个leader

问题原因：

该问题可能是由于zookeeper在选择leader时，其中两个节点优先建立关系后，另一节点无法找寻到正确的leader节点，或另一节点中记录了原有的leader信息而未更新，可能会造成多个leader的出现

还有一种可能是部分节点为原有的leader，集群宕掉切换后，原有leader并未启动，但是新的leader已经产生，那么也可能出现多个leader的情况

解决方式：

解决该问题的方法需要配置zookeeper的配置文件，在文件中配置同步信息的时间，同时也需注明每个zookeeper server的顺序，并在配置文件中指明存储zookeeper日志的存储路径

重点：需要在zookeeper的日志路径中创建myid文件，文件内容根据节点数量进行编写，如三节点集群即分别为1，2，3，该顺序需与zookeeper配置文件中的server顺序一致

zookeeper参考配置如下：

initLimit=10
syncLimit=10
dataDir=/data/zookeeper
clientPort=2181
maxClientCnxns=0
admin.enableServer=false
server.1=xx.xx.xx.xx:2888:3888
server.2=xx.xx.xx.xx:2888:3888
server.3=xx.xx.xx.xx:2888:3888

2、kafka挂了，日志显示java:设备上没有空间

问题现象：

kafka持续运行很久并且且业务频繁写入，突然出现了broker0节点的kafka挂了，查看日志发现提示设备上没有空间，此时立即查看磁盘空间使用情况，发现磁盘并没有占满，由此怀疑是频繁的io导致的磁盘inode数被占满，从而无法写入文件

问题原因：

inode是索引节点，每个存储设备（例如硬盘）或存储设备的分区被格式化为文件系统后，应该有两部份，一部份是inode，另一部份是Block。Block是用来存储数据用的，而inode就是用来存储数据的信息，这些信息包括文件大小、属主、归属的用户组、读写权限等。如果Linux系统的inode数被占满将会导致文件无法正常写入，由于kafka频繁io导致的日志数量及索引文件过多，就会发生这种情况

解决方式：

1、优先考虑的肯定是删除无用的日志文件以及字节为0的文件，命令如下：find /home -type f -size 0 -exec rm {}  \

2、修改磁盘的inode数量

前者可用于测试环境，后者更加适合生产环境，且需要再生产环境正式使用之前优先设置好，但是如果不存在好的清理策略，依旧有可能会被占满，所以后者加上脚本去清除日志文件的方式可能更为靠谱

修改inode数量方法：

1、卸载磁盘：umount  /dev/sdb1

2、查看磁盘当前的inode数量：dumpe2fs -h /dev/sdb1 |grep node

3、修改磁盘的inode数量：mkfs.ext4 /dev/sdb1 -N 9830400

3、关于kafka定时清理日志不生效的问题

问题现象：

Kafka设置了log.retention.hour参数，该参数默认是保留7天的数据，但是经过实际的测试使用发现日志并未清除

问题原因：

该问题是由于kafka默认只会回收上个分片的数据，配置没有生效的原因是因为数据并没有分片

解决方式：

在配置中加⼊ log.roll.hours=12既可以解决问题 12⼩时切⼀次⽚

4、kafka写阻塞的问题

问题现象：

某程序持续向Kafka中写入数据，但是写入几分钟后程序就变得缓慢，通过日志查看到好像是写阻塞了

问题原因：

首先kafka作为消息中间件他本身很少出现写阻塞的情况，况且当前的业务场景和kafka的配置是不可能产生阻塞的，那么基本之后一种可能造成阻塞了，这里的思路是参考数据库的锁想的，是不是像数据库一样相当于把表锁住了，那么什么情况会锁住表呢，答案肯定是这个表正在被用呢，因为一直是单个应用写Kafka，其他的都是消费，这是不可能出现问题的，那么还有一种可能就是Kafka自身在用，Kafka自身用的唯一一种可能就是自身在清理这个主题的数据，或者是对这个主题的日志进行拆分，感觉是这里可能会造成写阻塞的问题，然后立刻查看Kafka的配置，发现Kafka的清理策略出现了问题，之前配置文件更改后没有重启测试，这次重启才出现这个问题，一看清理策略，原来是设置了Kafka的日志清理大小和延迟处理这几个参数，这个可以百度查一下，我的理解就是Kafka在日志到达了一定量的时候他把这个日志独立出来，然后过了延迟时间再删除，这个方式看似很平滑，但是确实会出现阻塞的情况（有待进一步考究），先不管了，先把参数改成定时清理，日志也调大，再次测试，发现问题解决，这个是典型的参数理解不到位导致的，从而看出在提高性能节省空间的同时，要考虑是否符合当前的场景，否则容易搞出问题。