forked from TrueCloudLab/frostfs-sdk-go
27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
|
# Node connection pool
|
||
|
|
|
||
|
|
* Distributes requests between fixed number of nodes
|
||
|
|
* Wraps
|
||
|
|
|
||
|
|
The distribution between nodes in connection pool is based on priority and weight parameters from
|
||
|
|
NodeParam struct. The distribution model is presented below. On this scheme nodes with the same
|
||
|
|
priority have the same color.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
## Priority
|
||
|
|
|
||
|
|
Pool component forwards request to the nodes with the highest priority (the lower the value -
|
||
|
|
the higher the priority). The `node 1` from the image's scenario (I) is healthy
|
||
|
|
and has the highest priority (1), that's why the pool forwards requests from it. There are no other
|
||
|
|
nodes with priority 1, so `node 1` receives all requests. In the second scenario (II) `node 1`
|
||
|
|
becomes unhealthy. In that case pool tries to connect nodes with next in priority nodes e.g.
|
||
|
|
`Node 4` and `node 2`. If all of them become unhealthy too, the pool sends requests to nodes with
|
||
|
|
priority 3 in scenario (III) and so on.
|
||
|
|
|
||
|
|
## Weights
|
||
|
|
|
||
|
|
If there are several nodes with the same priority, then requests are distributed randomly between
|
||
|
|
these nodes based on their weights. To do that the proportion of weights is calculated.
|
||
|
|
For example, for `node 2` and `node 4` with weights 2 and 8 the distribution would be 20 and 80 percent
|
||
|
|
respectively.
|