[IOTDB-1182] [Distributed] read and write in leader node

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Fix Version/s: 0.13.0
• Component/s: Core/Cluster
• Labels: pull-request-available
• Assignee: Chao Wang
• Reporter: Chao Wang
• Created: 04/Mar/21 06:50
• Updated: 11/Sep/21 06:56

Description

In the raft algorithm, because the leader always has the latest data, the query requests sent by the client should be executed at the leader. However, this will cause the read and write requests to go to the leader, which makes the single point pressure too large, thus affecting the overall throughput of the system. Therefore, in order to reduce hot issues, we can use follower linear read to support follower reading. The cost is that when the follower needs to execute a read request, it needs to ensure that the local applyindex is greater than or equal to the leader's commitindex before reading the state. Therefore, you need to send an RPC to the leader, and judge according to the returned result. If the applyindex of the follower is greater than or equal to the commitindex of the leader, you can query directly. Otherwise, you should passively wait until the local applyindex is greater than or equal to the commitindex of the leader. Considering that there may be temporary inconsistency between the follower and the leader when reading and writing concurrent, it is easy to enter the passive waiting for catchup detection phase when the query is routed to the follower. At this time, the batch of data that is different between the follower and the leader is likely to be in the network, so the best way is for the follower to wait passively and not do any operation. In case of RPC loss or partition, the leader needs to actively detect the inconsistency of the follower data and initiate catchup,            Because the cycle of leader detecting follower is heartbeat interval, which is 1 s by default, and in order to reduce traffic abuse, catchup will be initiated only after 5 times of detection. Once entering this stage, the expected time of waiting for inconsistency to be detected is 2500 MS, which may greatly increase the latency of system read request. Fortunately, this extreme condition should be rare.

Issue Links

• Blocked: IOTDB-68 IoTDB supports distributed version