如果使用远程 MySQL 数据库服务器，可接受的最大延迟是多少？

Question

除了单服务器优化之外，我还对将现有 Web 应用程序拆分为单独的 WEB 和 DB 服务器进行评估。

我知道网络延迟是使用远程数据库服务器时的一个重要因素。

理想情况下，我会将专用数据库服务器放置在与 WEB 服务器相同的 DC 中，甚至使用专用网络。

但是，如果我确实需要将其放在不同的 DC 上，为了获得响应式连接，可接受的最大网络延迟是多少？

更新：

最后，我想问一下，如果我确实需要部署远程数据库，那么在选择数据中心和基础设施时，最佳实践和需要考虑的事项是什么？

Answer 1

这个问题没有单一的正确答案。MySQL 客户端/服务器协议对往返时间的容忍度没有限制，但应用程序的响应能力可能会受到极大影响。

但从根本上来说，如果不熟悉您的应用程序，您就无法看到任何数字并直观地知道它会起作用。

最近，我不得不将遗留应用程序从本地迁移到云端——首先是数据库，然后是应用程序层。两个站点之间的往返时间为23ms。“蛋糕，”我想……“23 毫秒没问题。”

不幸的是，这是一个问题，因为最初的开发人员已经屈服于分布式计算的谬误之一：“延迟为零”。

这是一个 3 层应用程序，对多秒页面加载的调查显示，网站每个页面上对应用程序层的每个方法调用都会触发至少13次数据库往返。GetUserAttributes、GetAccountBalance、GetProductListings...您明白了...所以这是一个简单的页面，它发出了 39 个基本上不必要的数据库请求，并且仅需要约 750 毫秒的传输时间，而不是仅仅几个。（为什么这么多？他们历史上使用了两种不同的 ORM，并且仍然为每种方法设置这两种方法，冗余地调用 USE 数据库和 SET 自动提交等）这是一个极端的例子，但在 LAN 上，这是你需要做的事情。侥幸逃脱，但这会导致您的性能随着 RTT 的增加而受到指数级影响。

在 LAN 上每秒可以实现数百次往返的情况下，加上 23 毫秒，该数字会下降到大约 40 次。这很容易成为 10 倍或更多，即使根据人类的计算，23 毫秒似乎很快。即使是个位数的往返也会对性能产生与直觉相反的重大影响。

幸运的是，有一种相当简单的方法可以以绝对有意义的方式模拟 MySQL 服务器的延迟——不是模拟它，而是实际注入物理延迟：在远程数据中心配置透明的 TCP 代理。例如，HAProxy。简单的示例配置：

listen mysql
  mode tcp
  bind *:3306
  server mysql-server 203.0.113.1:3306
  timeout tunnel 28800s

这忽略了您想要在永久部署中使用的功能，例如运行状况检查和 ACL，但如果您在远程数据中心的测试计算机上设置它，并在端口 3306 上连接到它，它会将连接发回到 MySQL 服务器（203.0.113.1）。HAProxy 在 TCP 模式下与有效负载无关，它只是转发数据包有效负载（splice在可用的情况下使用，以避免在用户空间中花费大量时间），因此它本身不会造成任何有意义的延迟（并且可以在小型计算机上处​​理令人惊讶的流量）。如果您的应用程序和数据库是本地的，并且此代理是远程的，这将完美地模拟您的应用程序行为，两个数据中心之间的往返时间加倍（因为应用程序到数据库、数据库到应用程序会遍历整个路径两次，一次都没有）...模拟比最坏的情况还要糟糕。

如果此性能证明可以接受，那么您建议的往返时间就没有问题。如果不是，那么您就发现了问题，但为时已晚。