Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Done
-
None
-
None
Description
For raft based data management systems, the client typically supports the ability for caching leaders to redirect. This eliminates the need to consume internal resources and additional Round-Trip time to forward these requests within the cluster.
For a write request, the coordinator can handle this request without any RPCs besides a raft broadcast if it finds that the data group's leader corresponding to the data is itself, otherwise, it can make a request to get the leader address of the data group and return the result to the client instead of forwarding it. The client then caches this new leader to re-establish the session, and subsequent requests can be sent directly to the correct node.
For cluster, we should change the forwarding logic to a return-new-leader-address logic for write requests if we finds that the data group's leader corresponding to the data isn't coordinator.
For client, we should wrap these change such as caching leader address in session and jdbc rather than exposing to the user to implement.
To some extent, this issue wants to reduce the resource consumption within the cluster and the delay of single request.
Any problems can be discussed below.
Attachments
Attachments
Issue Links
- is a child of
-
IOTDB-68 IoTDB supports distributed version
- Open
- links to