The construction of the cluster will not be introduced in detail here. There are many tutorials on the Internet. The key is to find the one that suits you.
During cluster startup, a leader election is performed.
We often have a wrong perception: in order to successfully elect the leader, the services of the zookeeper cluster must be deployed as an odd number.
In fact, the zookeeper cluster has the principle that more than half of it survives and can be used. We deploy 5 servers and deploy 6 servers, but 2 of them can run normally, and the whole cluster cannot be used after 3 of them. In this case, 6 machines have no obvious advantage in disaster recovery, so zookeeper is usually designed to be an odd number.
Single point of question:
Refers to in a distributed system, if a certain component fails, it will cause the availability of the entire system to be greatly reduced or even paralyzed
But zookeeper has a design principle of more than half, which can prevent and solve single point problems very well.
Disaster recovery:
In ordinary applications, for disaster tolerance, we will choose to deploy on different machines to form a cluster. ----Solution to single point problems
But for some core applications, in order to prevent the entire cluster from being unavailable due to unexpected situations in the entire computer room, we will deploy a cluster in different computer rooms.
In order to prevent the cluster from being unavailable due to an accident in the computer room, we will deploy it in different computer rooms, but most companies can only provide two computer rooms at most, and three computer rooms are very extravagant. Therefore, we will deploy more machines in the two computer rooms, the ones with better security, to prevent.
Expansion:
As a distributed system, horizontal scalability can be said to be the basic requirement for high availability.
Horizontal expansion is: it can help the system to quickly improve the external service support capability of the system without any or very little improvement work.
But for zookeeper to support horizontal expansion, the cluster must be restarted - which is very insecure for the online system.
There are two ways to restart the cluster:
1. Overall restart: Stop the cluster, update the zookeeper configuration, and restart again. -----You must know that when the cluster stops, the client's request will not stop. You can imagine the consequences of doing so.
2、逐台重启：每次重启一台机器，保证整个集群在修改配置的时候是可用的。
磁盘管理
在zookeeper中，但凡是对zookeeper数据状态的变更，都会以事务日志的形式写入磁盘。（跟MySQL集群和redis集群有点像）并且只有当集群中过半的服务器已经记录了该事务日志后，服务端才会给予客户端相应。
另一方面，zookeeper还会定时将内存数据库中的所有数据和所有客户端的会话消息记录进行快照，保存到磁盘。
这两种操作，都会影响zookeeper的处理速度。
所以我们在选择磁盘的时候，尽量使用单独磁盘作为事务日志的输出目录。
参考书籍《zookeeper分布式一致性原理与实践》