Zookeeper一般挂掉的原因
归根到底一句话：要同步的数据太大！多大？500M
zookeeper集群中leader和follower同步数据的极限值是500M，这500M的数据，加载到内存中，大约占用3个G的内存。数据过大，在每次选举之后，需要从leader同步到follower，容易造成下面2个问题：
1、网络传输超时，因为文件过大，传输超过最大超时时间，造成TimeoutException，从而引起重新选举。
2、如果调大这个超时值，则很可能达到磁盘读写的上限，目前，每像精卫、tbschedule3等，都有大量的zk写入，这些会触发频繁的磁盘写操作，一旦达到io上限值，就会导致超时，进而触发重新选举或直接导致系统崩溃。
所以，上面两个问题，都可能导致zookeeper集群一直在选举和数据同步之间陷入死循环。
上面的问题在阿里是普遍的，下面看两个例子：
去年tbschedule 3有个bug，是ACL list只会增加不会减少，导致存储的ACL数据过大，进而导致选举后数据同步失败，又重新选举的死循环。导致zk服务器一直起不来，进而导致物流宝调度任务不执行，系统挂掉的时间超过1个小时。
事实上，tbschedule 3还存在写入过于频繁的问题，如果写入频繁，就会频繁触发zookeeper保存快照，进而导致IO压力大。
今年近期，汇金平台所在的公共zk集群因为精卫数据过多而挂掉。像精卫这种应用，在zookeeper集群上
归根到底一句话：要同步的数据太大！多大？500M zookeeper集群中leader和follower同步数据的极限值是500M，这500M的数据，加载到内存中，大约占用3个G的内存。数据过大，在每次选举之后，需要从leader同步到follower，容易造成下面2个问题： 1、网络传输超时，因为文件过大，传输超过最大超时时间，造成TimeoutException，从而引起重新选举。 2、如果调大这个超时值，则很可能达到磁盘读写的上限，目前，每像精卫、tbschedule3等，都有大量的zk写入，这些会触发频繁的磁盘写操作，一旦达到io上限值，就会导致超时，进而触发重新选举或直接导致系统崩溃。 所以，上面两个问题，都可能导致zookeeper集群一直在选举和数据同步之间陷入死循环。 上面的问题在阿里是普遍的，下面看两个例子： 去年tbschedule 3有个bug，是ACL list只会增加不会减少，导致存储的ACL数据过大，进而导致选举后数据同步失败，又重新选举的死循环。导致zk服务器一直起不来，进而导致物流宝调度任务不执行，系统挂掉的时间超过1个小时。 事实上，tbschedule 3还存在写入过于频繁的问题，如果写入频繁，就会频繁触发zookeeper保存快照，进而导致IO压力大。 今年近期，汇金平台所在的公共zk集群因为精卫数据过多而挂掉。像精卫这种应用，在zookeeper集群上
上一篇：
JS实现多线程数据分片下载
下一篇：
教你接入GPT4，不用梯子也能玩