Understanding of zookeeper's process lock, multithreading and load principle
The process lock of zk has nothing to do with reading and writing (it is only enabled when you realize that the same method is called (when sharing is involved))
Process locks are the control between processes, but on this basis, whether to synchronize blocks or read-write locks requires the application of multi-threading in a single process
Load balancing principle:
A service node is also created when each service registration is started (similar to a lock node)
The processing idea of load balancing is also similar to the processing idea of locks (that is to say, the node marking decision is the core idea of zk)
Using the strong consistency of ZooKeeper can ensure the global uniqueness of node creation in the case of distributed high concurrency, that is: if multiple clients request to create /currentMaster node at the same time, only one client request can be successfully created in the end
In a cluster environment, the process lock problem must be considered, not just load balancing, zk just handles the process lock while processing the load, so after kp+nigix, it has to be forwarded by zk once (ordinary text is mounted with dubbo) ,
Ask other software activemq and other natural integration entrances (zk implements communication between threads between processes)
With process locks, multi-threading between processes can be avoided, and multi-threading within a process still requires synchronization block/lock control, so that the pessimistic lock of the database can be avoided.
dubbo implements the injection service, zk implements the load