A distributed framework design (IV.)

We design a distributed system that presents a mesh during normal operation. The service is hierarchical, and the customer's request is gradually processed by each layer of service, and the request is completed only once all services have been traversed. Each layer of service will have several machines, the upstream node of the machine can pass the output to any one of the downstream nodes of the machine.

When the data that the service depends on needs to be updated, we need to do a good job of synchronizing and ensure that the service is available during the data update process. Here are the two types of updates that need to be implemented using zookeeper.

The first type of update is limited to all machines of one service. We need to set a sequence for their updates to avoid all the machines in the service updating this extreme situation at the same time. Zookeeper encourages the use of asynchronous APIs for programming, and there are at least two ways to implement this distributed lock in the implementation process. The first is to try to create an established node, if success means that the lock has been received, can start updating, otherwise create the observer, wait for the other machine to complete the update after the release of the lock (of course, may still not be able to get), the second is to create a sequential node (sequence), Zookeeper can guarantee the uniqueness of the created node, and then the service only needs to monitor the order in which the node before itself has finished updating (releasing the lock). When the amount of data is small, the performance of the two implementations should not be very different, the data is large when the second method is recommended, because it can reduce the network traffic generated by the notification. The first way in the lock process, the network faster machines are more likely to grab, the second way is based on the queuing mechanism. Although the logic is simple, but the actual programming process will be more troublesome, need to consider network transmission and other issues.

The second type of update is the case where there is data dependency in multiple services. For example, services A and B, they all have two machines A1, A2, B1, B2. The initial data timestamp is the same, that is, service A's data is da_t1, and service B's data is db_t1. If we have new data da_t2 and DB_T2, we only allow one machine of a and B to be updated at the same time, such as A1, B1; This is the server that updates the data and only sends its own downstream data to the downstream servers that have updated the data. That is, the original A1 and A2 can be sent to the downstream data to B1 and B2 any one, now A1 can only give b1,a2. Until a2, B2 are updated to the new data, the original transfer mode can be restored. The specific implementation is first we need to know the entire data update of the overall server situation, the name of the data to name (index), as follows:/data/index/a/a1,/DATA/INDEX/A/A2,/data/index/b/b1,/data/ INDEX/B/B2, once the timestamp for T2 packets are ready, then the value of the modified node/data/index is T2 (can be updated at the first level, that is,/data/index/a,/data/index/b timestamp is modified to T2, and then modified/data /index), and select a number of machines for each type of service to start updating, i.e. increase/updating/index/a/a1,/updating/index/b/b1, and assign a value of T2. Each server will monitor its own node, that is, A1 will monitor the/UPDATING/INDEX/A/A1, and once the node is found, it will begin to update the data, and after the update is complete, it will delete its own nodes. Monitoring service Once the/UPDATING/INDEX/A/A1 is found,/UPDATING/INDEX/B/B1 is removed and the value/UPDATING/INDEX/A/A2,/UPDATING/INDEX/B/B2 is re-assigned. When all data with a timestamp of T2 is updated, the/updated/index is assigned a value of T2. But in the actual programming process, it is very troublesome to follow the above description completely, so we still simplify, but the logic is still guaranteed.

So far, the distributed framework System I designed has been introduced.

A distributed framework design (IV.)