http://www.cnblogs.com/zgghb/p/6515062.html
Advantages of Eureka
1. In the Eureka platform, if a server goes down, Eureka will not have a process of electing a leader similar to ZooKeeper; client requests will automatically switch to the new Eureka node; when the downed server is restored, Eureka will Again, it is incorporated into the server cluster management; for it, all it has to do is synchronize some new service registration information. Therefore, there is no need to worry about the risk that the "left behind" server will be removed from the Eureka server cluster after recovery. Eureka is even designed to handle wider network segmentation failures and achieve "zero" downtime maintenance requirements. (There is a problem in the network between multiple zookeepers, resulting in multiple leaders and split-brain) When a network segmentation fault occurs, each Eureka node will continue to provide external services (Note: ZooKeeper will not): Receive new services The registrations also make them available to downstream service discovery requests. In this way, it can be implemented in the same subnet (same side of partition), and newly published services can still be discovered and accessed.
2. Under normal configuration, Eureka has a built-in heartbeat service to eliminate some "dying" servers; if the "heartbeat" of a service registered in Eureka becomes slow, Eureka will remove it from the management scope. (This is a bit like what ZooKeeper does). This is a nice feature, but it is also very dangerous when a network segmentation failure occurs; because the servers that are kicked out due to network problems (note: slow heartbeats are kicked out) are themselves "healthy", It is only because of the network segmentation fault that the Eureka cluster is divided into independent subnets and cannot access each other.
Fortunately, Netflix took this flaw into account. If the Eureka service node loses a large number of heartbeat connections in a short period of time (note: a network failure may have occurred), then the Eureka node will enter the "self-protection mode", while retaining those "heartbeat death" service registration information does not expire. At this point, the Eureka node can also provide registration services for new services, and still retains the "dead" ones, in case there are still clients requesting it. When the network failure is restored, the Eureka node will exit "self-protection mode". So Eureka's philosophy is that it's better to keep both "good data" and "bad data" than to throw away any "good data", so this pattern works very well in practice.
3. Eureka also has a client-side caching function (Note: Eureka is divided into two parts, the client-side program and the server-side program, the client program is responsible for providing registration and discovery service interfaces to the outside world). Therefore, even if all nodes in the Eureka cluster fail, or a network segmentation fault occurs, the client cannot access any Eureka server; the consumers of the Eureka service can still obtain the existing service registration information through the Eureka client cache. Even in the most extreme environment, when all normal Eureka nodes do not respond to requests, and there is no better server solution to solve this problem
; thanks to Eureka's client-side caching technology, consumer services can still pass through Eureka It is very important for the client to query and obtain the registration service information.
4. The architecture of Eureka ensures that it can become a Service discovery service. Compared with ZooKeeper, it eliminates the selection of the leader node or the transaction log mechanism, which is conducive to reducing the difficulty of user maintenance and ensuring the robustness of Eureka at runtime. Moreover, Eureka is designed for discovery services. It has an independent client library and provides functions such as heartbeat service, service health monitoring, automatic publishing service and automatic cache refresh. However, if using ZooKeeper you must implement these functions yourself. All Eureka libraries are open source, and everyone can see and use the source code, which is better than client libraries that only one or two people can see or maintain.
5. Maintaining the Eureka server is also very simple. For example, switching a node only needs to remove an existing node under the existing EIP and add a new one. Eureka provides a web-based graphical operation and maintenance interface, in which you can view the running status information of the registered services managed by Eureka: whether it is healthy, running logs, etc. Eureka even provides a Restful-API interface to facilitate third-party programs to integrate Eureka's functions.
Disadvantages of ZooKeeper
In the field of distributed systems, there is a well-known CAP theorem (C-data consistency; A-service availability; P-service fault tolerance to network partition failures. These three characteristics cannot be satisfied simultaneously in any distributed system, at most Meet two); ZooKeeper is a CP, that is, access requests to ZooKeeper at any time can obtain consistent data results, and the system is fault-tolerant for network segmentation; but it cannot guarantee the availability of each service request (Note: that is, in In extreme environments, ZooKeeper may drop some requests, and the consumer program needs to re-request to get results). But don't forget, ZooKeeper is a distributed coordination service, and its responsibility is to ensure that data (Note: configuration data, state data) is kept synchronized and consistent among all services under its jurisdiction; so it is not difficult to understand why ZooKeeper was designed It has become a CP instead of an AP feature. If it is an AP, it will bring terrible consequences (Note: ZooKeeper is like a signal light at an intersection, can you imagine a situation where the signal light suddenly fails at a traffic artery?). Moreover, as the core implementation algorithm of ZooKeeper, Zab solves the problem of how to maintain data synchronization between multiple services in a distributed system.
1. For the service discovery service, even if it returns a result containing false information, it is better than returning nothing; moreover, for the service discovery service, it is better to return which servers a service was on 5 minutes ago available information, nor can it not find an available server due to a temporary network failure without returning any results. Therefore, it is definitely wrong to use ZooKeeper as a service discovery service. If you use it like this, you will be miserable!
ZooKeeper itself does not handle network segmentation properly if it is used as a service discovery service; in the cloud, network segmentation problems do occur like other types of failures; so it is best to be 100% prepared for this problem in advance . As Jepsen said in a blog post on the ZooKeeper website: In ZooKeeper, if the number of nodes in the same network partition (partition) does not reach the "quorum" that ZooKeeper selects the leader node, they will It will be disconnected from ZooKeeper, and of course, it will not be able to provide Service discovery services.
2. It is impossible for all nodes under ZooKeeper to guarantee that all service registration information can be cached at any time. If all nodes under ZooKeeper are disconnected, or there is a network segmentation failure in the cluster (Note: The subnets under the switch cannot access each other due to the failure of the switch); then ZooKeeper will remove them from its own management scope. , the outside world cannot access these nodes, even if these nodes are "healthy" and can provide services normally; therefore, the service requests reaching these nodes are lost. (Note: This is also the reason why ZooKeeper does not satisfy A in CAP)
3. The deeper reason is that ZooKeeper is built according to the CP principle, which means that it can ensure that the data of each node is consistent, and the purpose of adding cache to ZooKeeper is to make ZooKeeper more reliable (available ); however, the original intention of ZooKeeper design is to keep the data of nodes consistent, that is, CP. So, in this way, you may get neither a data consistent (CP) nor a highly available (AP) service discovery service; because this is equivalent to forcing you on an existing CP system A system with an AP tethered, which essentially doesn't work! A service discovery service should be designed to be highly available from the start!
4. If the CAP principle is ignored, it is very difficult to correctly set up and maintain the ZooKeeper service; errors will often occur, resulting in many projects being built just to ease the difficulty of maintaining ZooKeeper. These errors exist not only with clients but also with the ZooKeeper server itself. Many failures of the Knewton platform are caused by the improper use of ZooKeeper. Seemingly simple operations such as correctly reestablishing the watcher, handling client sessions and exceptions, and managing memory in the ZK window can easily lead to ZooKeeper errors. At the same time, we did encounter some classic bugs of ZooKeeper: ZooKeeper-1159 and ZooKeeper-1576; we even encountered the failure of ZooKeeper to elect the leader node in the production environment. The reason why these problems occur is that ZooKeeper needs to manage and guarantee the session and network connection resources of the service group under its jurisdiction (Note: the management of these resources is extremely difficult in a distributed system environment); but it is not responsible for managing service discovery , so using ZooKeeper when Service discovers services outweighs the gains.
There are 3 machines in a cluster, what is the impact after hanging one? What about hanging up two?
Hang up one: After hanging up one, you will not receive votes from one of them, but there are two that can participate in voting. According to the above logic, they both voted for themselves at first, and later, according to the principle of election, both of them voted. Give one of them, then there is a node with votes equal to 2, 2 > (3/2)=1, more than half, and the leader can be elected at this time.
Hanging up two: After hanging up two, you can only get one ticket no matter what, 1 is not greater than (3/2)=1, so you cannot elect a leader.
The full name of ZAB (ZooKeeper Atomic Broadcast) is: atomic message broadcast protocol; ZAB can be said to be extended and transformed on the basis of Paxos algorithm. ZAB protocol is designed to support crash recovery. ZooKeeper uses a single main process Leader to process clients For all transaction requests, the ZAB protocol is used to broadcast the status of the number of servers to all Followers in the form of transactions; since there may be dependencies between transactions, the ZAB protocol ensures that the sequence of changes broadcast by the Leader is processed sequentially: a state is processed, then its The state of dependencies has also been processed in advance; the crash recovery supported by the ZAB protocol can ensure that when the leader process crashes, the leader can be re-elected and data integrity is guaranteed;
After more than half (>=N/2+1) of Followers feedback information, the Leader will broadcast Commit information to the Followers in the cluster again, and Commit is to submit the previous Proposal;