Aerospike：节点上的连接数不平衡

Question

在添加两个新的附加节点之前，我们在集群中有两个节点。该群集的状态为OK。但是节点的连接数不平衡。两个旧节点1,2之间的连接数保持平衡。新节点3，4之间也具有平衡。但是1-2与3-4之间的许多连接是不平衡的。

[硬件和配置在这四个节点上相同。

有人可以提示，请添加新节点时我错过了什么吗，它如何解决？

谢谢

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information (2020-04-23 15:28:01 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Node   Node                   Ip       Build   Cluster   Migrations        Cluster     Cluster   Principal   Client       Uptime   
     .     Id                    .           .      Size            .            Key   Integrity           .    Conns            .   
ny-as-1:3000   2C     192.168.11.17:3000   C-4.7.0.2         4      0.000     E97140B6302A   True        EE            2637   3219:11:28   
ny-as-2:3000   *EE    192.168.11.18:3000   C-4.7.0.2         4      0.000     E97140B6302A   True        EE            2525   3219:19:13   
ny-as-3:3000   2E     192.168.11.19:3000   C-4.7.0.2         4      0.000     E97140B6302A   True        EE             356   195:46:21    
ny-as-4:3000   3E     192.168.11.20:3000   C-4.7.0.2         4      0.000     E97140B6302A   True        EE             371   195:39:53    
Number of rows: 4

数据大小/总记录跨度

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Usage Information (2020-04-23 15:28:01 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace           Node       Total   Expirations,Evictions     Stop         Disk    Disk     HWM   Avail%         Mem     Mem    HWM      Stop          PI         PI      PI     PI   
        .              .     Records                       .   Writes         Used   Used%   Disk%        .        Used   Used%   Mem%   Writes%        Type       Used   Used%   HWM%   
dsp         ny-as-1:3000   167.326 M   (99.234 B, 0.000)       false     54.458 GB   7       85      89        9.973 GB   18      85     90        undefined   9.973 GB   0       N/E    
dsp         ny-as-2:3000   160.925 M   (95.320 B, 0.000)       false     52.376 GB   7       85      90        9.592 GB   18      85     90        undefined   9.592 GB   0       N/E    
dsp         ny-as-3:3000   156.493 M   (10.839 B, 0.000)       false     50.918 GB   7       85      90        9.328 GB   17      85     90        undefined   9.328 GB   0       N/E    
dsp         ny-as-4:3000   158.321 M   (10.985 B, 0.000)       false     51.503 GB   7       85      90        9.437 GB   17      85     90        undefined   9.437 GB   0       N/E    
dsp                               643.066 M   (216.379 B, 0.000)               209.254 GB                            38.330 GB                                        0.000 B                   
Number of rows: 5

Answer 1

这不一定是问题。只要工作负载减慢或突然爆发，就会创建更多连接...如果在此临时爆发之后，工作负载能够使连接仍然足够频繁地使用，或速度变慢，这些连接只会保持活动状态，这不会引起任何关注。让我给你一个简单的例子来说明这一点：

假设您的交易在10毫秒内完成，而您的初始工作量为每秒100笔交易。您可以通过一个连接（1秒内100次往返，每次10ms）来维持此状态。现在，如果由于某种原因，介于两者之间的服务器或客户端或网络变慢，导致事务花费100ms而不是10ms的时间，您将需要10个连接来维持100tps的吞吐量，因此您将打开9个新连接，每个连接现在以10 tps的速度完成所有10个tps的总和。

当延迟降低到每个事务10ms时，您最终将每秒使用10个连接中的每个连接10次，而不是每秒使用100个连接。只要每55秒使用一次每个连接（客户端上的默认空闲时间），这10个连接将保持活动和使用状态。在事务处理10ms内部署并加入一个新节点时，只需1个连接较旧的节点仍将使用10倍。

如果有意义，您可以将其视为某种滞后...

希望这会有所帮助！