CAP theory
The CAP theory, a distributed system can not simultaneously satisfy the consistency (C: Consistency), availability (A: Available), fault tolerance partition (P: Partition Tolerance) the three basic requirements, which can only satisfy two items because P is necessary, it is often selected in the CP or the AP.
Consistency (C: Consistency)
in a distributed environment, data refers to consistency between multiple copies of the data is able to maintain consistent properties. In the consistency of demand, after a system update operation is performed in a consistent state data, the system should ensure that data remains in a consistent state . For example, a copy of the system data distributed on different nodes of a distributed it, if the data were first node update and the update is successful, the data on the other node should be updated, and all users can read to take its latest value, then such a system was considered to have strong consistency (or strict consistency, eventual consistency).
Availability (A: Available)
Availability refers to the service provided by the system must always be in a usable state, always returns results for each operation request user within a limited time . "Effective time" means that, for an operation request of the user, the system must be able to specify the time (i.e., response time) to return the processing result corresponding to the, if more than this time frame, then the system is considered unusable of.
"Return result" is another very important indicator of availability, which requires the system after the processing of the user request, it returns a normal response results. The result is usually a normal response to clearly reflect the results of the processing of the request, that is success or failure, rather than a confused allow users to return results.
Partition fault tolerance (P: Partition Tolerance)
partitions fault tolerance constraints of a distributed system must have the following characteristics: a distributed system in the face of any network partition fails, they still need to be able to provide external assurance to meet the consistency and availability of services, unless the entire network environment has failed .
Refers to a partition in a distributed network system, different nodes in different sub-network (foreign network room or the like) in some particular situation causes communication network does not occur between the sub-networks, each sub-network but the internal network is normal, causing the entire system to a network environment is segmented into a plurality of isolated regions. It should be noted that the composition of each node in a distributed system to join and exit can be seen as a special network partitions.
Due to a distributed system can not meet the above three requirements at the same time, but only two of them meet, so during the time of application of the CAP theorem, it is necessary to abandon one of them according to the requirements of the business.
CAP theory of ZooKeeper
In this ZooKeeper ensure that CP. Can not meet the availability (A: Available)
We can not guarantee the availability of each service request . ZooKeeper access at any time to request data to get consistent results, and the system for network segmentation fault tolerant; it can not guarantee the availability of each service request (Note: that is, in extreme circumstances, ZooKeeper may drop some requests, consumers need to re-program request to get results). So, ZooKeeper can not guarantee service availability.
Clusters are not available when leader election . When using ZooKeeper get the list of services, when the master node because the network lost contact with other nodes failure, the remaining nodes will be leader re-election. The problem is that the election leader too long, 30 ~ 120s, and the entire cluster zk are not available during the elections, which led to paralysis during the electoral registration service, although the service will eventually recover, but the long lead time of election registration long-term use can not be tolerated. So, ZooKeeper can not guarantee service availability.
Consistency of service provided by ZooKeeper
Consistency can be divided into:
strong consistency (strong consistency). Any time, any user can read the most recent successful update of data
monotonic consistency (monotonic consistency). Any time, any user once the value of a data after an update of the read, then it will not read the older value than this value. That is, the order of the data acquired must be monotonically increasing
session consistency (session consistency). Any user in a session, once the value of a data after an update of the reading, then this session will not read older than this value is the value of the session consistency in monotonous consistency to further relax the constraints on the basis of only guaranteed monotonic within a single user single session, there is no guarantee the same among different users or different user sessions
eventual consistency (eventual consistency). Users can only read a particular value updated, but the system to ensure that data will eventually reach exactly the same state, but can not guarantee the time required for
weak consistency (weak consistency). Users can not read the value of the latest updated within a certain time
ZooKeeper from the following points to ensure the consistency of the data:
- Sequential Consistency : from any particular client will update its transmission order is submitted consistent . To see if a value after a client updates the value of z is a znode, after the operation, which in turn updates the value of z b, the client is not able to see the value of z is b
- Atomicity : each update either succeed or fail . If an update fails, there will be no client will see the updated results
- Single System Image : a client no matter which server to connect to, it sees the system are the same view . If a client in the same session to connect to a new server, it sees the system state is not older than on the server before seen. When a server fails, resulting in its attempt to connect a client needs to aggregate other servers, all servers lags behind the failed server will not accept the connection request, unless these servers catch up the faulty server
- Persistence : an update if successful, the result will persist and will not be revoked . Updates will not be affected by server failure
- Real-time : within a certain period of time, the client can see the system needs to be guaranteed in real time. In this time period, any change in the system will be seen by the client, or the client to be detected
ZooKeeper ensure the partition Resilience:
when a single server in the cluster fails, the cluster as long as more than half of the machine is also able to work properly, the entire cluster will be able to provide services.
