我们的开发人员发现数据库主要接收读取请求，因此我们决定开始使用Geo Percona XtraDB集群。我们在每个位置启动了一个实例，总共三个。
后来发现/cart端点主要向数据库写入数据。工作量是意料之外的，也是计划外的。我们决定将/cart逻辑移至Redis。这又引出了另一个问题——如何扩展 Redis 以避免服务器再次崩溃？它主要用于缓存/cart一个月和共享 PHP 会话。当然，它并不像数据库那么重要。它可以补偿一些对数据库的写入负载。
我们为每个位置引导一个 Redis 实例，它们之间没有任何共享状态。如果请求来自欧洲，那么它将使用欧洲的 Redis 实例。如果请求来自美国，那么它将使用美国的 Redis 实例，依此类推。
世界霸权之旅
好吧，这个解决方案并不像我们希望的那样面向未来。现在我们在顶部安装了 Cloudflare，并在多个位置安装了扩展的应用程序。但我们遇到了另一个问题。我们注意到我们的应用程序中有很多“SQLSTATE MySQL 消失”错误。我开始四处挖掘，发现 XtraDB 集群触发了形成法定人数的超时错误。像往常一样，没有时间进一步调查，因此我们应用了一些快速修复，例如增加集群的超时、重试和复制缓冲区的窗口大小。它工作得更好 5% 左右，但我们仍然有超时、连接断开和停机时间。然后我检查了 XtraDB 端点之间的延迟。亚洲和欧洲之间有很多数据包丢失。
我联系了数据中心工作人员，通过另一个上游重新路由 泰国电话格式 我们的前缀，服务又恢复了在线状态。亚洲和欧洲之间的延迟约为250 毫秒，因此我们每秒有 4 个写入请求，因为 XtraDB 集群只有在集群中的所有节点都确认后才会确认写入。
第二天，位置之间的数据包丢失再次发生。我们联系了数据中心人员，并设法再次暂时解决了该问题。最终，我们决定摆脱 XtraDB 集群。
下一个问题是，如果一个实例发生故障，如何保持数据库连接的高可用性。我们推出了基于ExaZK 的定制 MySQL 集群解决方案。情况发生了很大变化。
正常运行时间检查图表
我们监控了应用程序在新变化下的表现约一周，但仍然注 让每个与你共事的人都成为你的品牌大使 意到响应时间大幅增加。然后我们创建了一个NewRelic帐户并开始监控整个应用程序本身。
New Relic 交易时间图解
我们获得了一些与MySQL慢查询和外部资源相关我们 沙特阿拉伯电话号码 应该怎么做才能 的非常实用的指标。问题非常明显——我们通过接收特定语言的翻译，为 MySQL 实例配上了不必要的读取请求。我们决定以 JSON 格式生成翻译文件并快速加载它们，而不是每次请求时都查询数据库。