Shard Proxy and Global Routing
A distributed system consists of multiple servers. A lot of complicated traffic and coordination mechanisms are implemented to make the data stored in all servers balanced and the service equally scaled. But users usually don't care and have little intention to understand the distributed detail. Therefore, we designed a
Shard Proxy to get a simple user experience just like working with a standalone database.The
Shard Proxy is a central module to accept all user read/write requests.
For example, when a user is quering for a certain table from a database. For a distributed database system, this request is actually looking for a
Shard in a ceratin
A user can send this request to any
Store of the system. The
Shard Proxy of the
Store will take that request, it will look up for the
Global Routing table to find the correct
As we have explained in the
Raft Group and Leader,
Leader is the representative of a
Raft Group, all read and write requests are handled only by the leader.
Therefore, when a request for certain rows are executed.
* Firstly, we need to locate the
Shard where these rows are stored.
* Secondly, locate the
Leader Replica of this
* Thirdly, route the request to the
Store where the
Leader Replica is located.
Leader Replica executes the request and returns response.
We have a cluster of 3
Stores, and their status are as below:
A user sends requests on key1, key10 and key20, the following diagram illustrates how the requests gets through
Shard Proxy and being routed.