Question

我们正在使用AWS Aurora作为数据库运行基于REST API的春季启动应用程序。我们的应用程序连接到只读的Aurora MySQL RDS实例。我们正在对其进行负载测试。最初，我们只有一个数据库，并且具有自动缩放功能，这是在CPU较高的情况下触发的。现在，我们期望，如果通过一个数据库实例获得一些X吞吐量，那么在自动缩放发生时，我们应该获得大约1.8倍的吞吐量，并且连接应与新创建的数据库实例平均分配。但这没有发生，相反，两个数据库实例上的数据库连接都不稳定。因此，我们的负载无法平均分配，并且无法获得理想的吞吐量。有时一个数据库正在100％CPU上运行，而另一个数据库仍在20％CPU上运行，几分钟后将其反转。下面是数据库连接配置：-

Driver - com.mysql.jdbc.driver
Maximum active connections=100
Max age = 300000
Initial pool size = 10

Tomcat jdbc池用于连接池

注意： 1）我们还禁用了jvm网络DNS缓存。 2）我们还尝试每5分钟刷新一次数据库连接，即使是活跃的。 3）我们尝试了AWS提出的所有建议，但没有任何效果。 4）我们甚至编写了一个lambda代码来在新数据库实例出现时更新Route 53，以避免集群端点缓存，但仍然是同样的问题。任何人都可以请帮忙的最佳实践是什么，因为目前我们无法将其投入生产。

Answer 1

这不是一个很好的答案，但是由于您还没有得到任何答复，所以有些想法。

1）您看到的行为复制了负载均衡器的错误路由逻辑
这不足为奇，但这在小型Web服务器部署中尤其常见，尤其是长时间运行的查询。使用连接池，您可以反映这种情况。

2）继续这一假设，我们需要猜测Amazon如何选择平衡流量以仅读取副本。
即使在白皮书中，他们也没有提到路由的执行方式：https://www.allthingsdistributed.com/files/p1041-verbitski.pdf

可能的选择是route53或NLB。我最好的猜测是他们正在使用NLB。 NLB仅在2017年第3季度才向我们提供，而Aurora在2年前才发布，但这仍然是合理的猜测。 NLB可以让我们基于最少的连接进行平衡（远胜于轮询）。

3）验证假设
如果使用route53，那么我们将能够使用DNS进行查找。我对route53端点进行了挖掘，发现它给了我一个答案

dig +nocmd +noall +answer zzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com
zzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com. 1 IN CNAME zzz-0.yyy.us-east-1.rds.amazonaws.com.
zzz-0.yyy.us-east-1.rds.amazonaws.com. 5 IN A 10.32.8.33

我又做了一次，得到了不同的答案。

dig +nocmd +noall +answer zzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com
zzz-databasecluster-xxx.cluster-ro-yyy.us-east-1.rds.amazonaws.com. 1 IN CNAME zzz-2.yyy.us-east-1.rds.amazonaws.com.
zzz-2.yyy.us-east-1.rds.amazonaws.com. 5 IN A 10.32.7.97

您会看到，只读端点将CNAME结果提供给

Zzz是我的集群的名称，yyy来自我的cloudformation堆栈结构，yyy来自亚马逊。

注意：zzz-0和zzz-2是两个只读副本。

在这里我们可以看到，我们有route53用于负载均衡。

4）Route53负载平衡
他们可能会在所有正常的只读副本上设置带有循环的Route53。
TTL可能为5秒。健康的节点将被删除，但是没有基于

的平衡

5）分枝
A）使用只读端点只能平衡不正常实例的流量
B）数据库池将保持很长时间的连接，这意味着新的只读副本将不会被触及

如果我们的服务器数量很少，我们将处于不平衡状态–我们无法采取很多措施。

6）关于您可以做什么的想法
A）通过挖掘来验证自己是否获得了正确的DNS解析度，该解析度每隔5s在副本之间循环一次。
如果不这样做，则需要解决此问题

B）定期回收数据库客户端
新的副本将被使用，并且在您不平衡的情况下，这将有助于不断进行更改。至关重要的是，您必须不要同时回收所有客户。否则，您将冒着所有人都获得同一时间的风险。我建议对每个客户随机进行一次ttl（在最小/最大范围内）。

C）自行管理

摘要：连接时，直接连接到连接数最少/ CPU最低的只读副本。

您的操作方式并不简单。我建议使用lambda函数，以将该连接字符串保留在可查询的位置。让它以某种频率更新。我会说更新首选数据库的频率是您回收数据库连接的频率的1/10。如果DB的运行方式类似，则可以添加逻辑，您可以给出只读的端点。仅当存在明显的不平等时才给出明确的端点。
我会提醒您，当一个新实例出现时，您要小心浮动。

D）增加客户数量或只读副本数量

这两种方法都会减少两个盒子出现明显差异的机会。

Aurora自动缩放的实例中没有发生相等的连接分配

1 个答案: