我们有一个包含微服务的应用程序，所有微服务都连接到相同的Percona数据库实例。当前，它只是一个实例，具有16核/ 32 GB内存，没有复制。我们的问题之一是，有时我们的一种微服务会导致数据库上如此高的负载（甚至只是读取），这会使所有微服务无法使用。
我们正在考虑创建一个由三个节点组成的Percona集群，并为每个微服务选择节点。大部分“写入”的服务将连接到一个实例，其余的将连接到其他两个实例。这样，如果某些微服务导致读取的高负载，则不应完全淹没我们的基础架构。
我的问题：
注意：我们可能会在GCE中使用Percona XtraDB点击部署：https://console.cloud.google.com/marketplace/details/click-to-deploy-images/percona?project=goout-cloud&folder&organizationId=74390800864
答案 0 :(得分：3)
是的，这是个好主意。将ProxySQL与PXC一起使用也是一个好主意。通过使用ProxySQL，您可以：A）通过将两个节点放入同一个主机组中来实现“ writer” HA，一个节点的权重超高（10000000），另一个节点的权重低（10）。如果高权重节点脱机，则ProxySQL将无缝开始向其他节点发送流量。 B）将所有节点放入具有相同权重的单独“读取器”主机组中，从而实现负载平衡写流量。 C）如果需要，创建一个仅包含1个节点的第3个主机组，并创建一个查询规则以对“高负载”查询的模式，用户或查询模式进行模式匹配，并将其直接执行到该特定节点。 ProxySQL还可以让您缓存其中一些繁琐的查询。
就个人而言，除非您知道您的网络坚如磐石，否则我会选择较少的实例并使用更高的CPU。在PXC中，所有节点必须同步ACK所有事务。您拥有的节点越多，这些操作所花费的等待时间就越长。您可以提交的最快速度是两个最慢节点之间的时间。请确保您总是有奇数个节点，除非您使用pc.weight设置进行了高级设置（但是要正确设置非常棘手）。
通常，对于MySQL，所有节点都应具有相同的配置。一般来说，如果您的主服务器比从服务器更强大，则从服务器将无法跟上音量。使用PXC，这意味着您将更频繁地体验流控制事件，这些事件可能会导致应用程序停顿。如果node2无法像快速的node1一样写，则node2发出流控制消息（要求帮助），要求其他节点在追赶时放慢速度。
是的，如＃1所述，使用ProxySQL。
请注意，查询优化是“加快速度”的第一方法。不要总是把硬件扔在问题上。值得花时间检查缓慢的查询日志并尝试改善查询。有时，一个索引可以使夜晚/白天变得不同。
免责声明：我是Percona的高级讲师，并提供了许多全日的PXC和ProxySQL密集型教程课程。
答案 1 :(得分：0)
您的秒杀似乎是问题所在。而且，由于用户希望获得这些热单，因此您需要尽快处理洪水。
添加队列仅会增加复杂度，并且在执行快速操作时会降低处理速度。因此，“不要排队，就去做。”进一步注意，该队列将被过渡复制到其他节点，从而使入队/出队可能比仅对请求执行操作要慢！
连接-做某事-断开连接需要时间。很多时候并没有真正涉及到“某物”，而是花费了很多时间。我发现如果活动的连接少于大约10个，则一切运行顺利。但是，如果有超过10个成功入门，那么InnoDB就会开始迷失自我。
曾经去过拥挤的商店吗？假设所有过道中可容纳200人和手推车。但是，如果您尝试拥有210名购物者，那么每个人都只是在试图争取一个职位而放慢了脚步。吞吐量下降，甚至到了人们想要放弃购物车休假的地步。曾经见过一家店门前排的商店吗？他们解决了这个问题，不允许同时有200多名购物者！
因此，解决问题的方法可能是 MySQL外部。如果您有一个面向MySQL的网页，请对其进行限制以限制其使用的“线程”数。例如，Apache具有这样的功能，外加一个“待办事项列表”，用于在连接到Apache级别进行排队。 MySQL的max_connections和backlog可能以相同的方式工作，但是max_connections（151）的默认值太高。 151名学生在便利店里挤在苏打水机旁可能是一个更好的比喻。
更多个节点/更多的CPU可能或不成为答案的一部分；这取决于“东西”拿出什么锁。
监视器 Threads_running；如果它增加到几十个以上，那么我怀疑我的评论适用。如果监视程序无法连接以检查GLOBAL STATUS，那么我知道它适用。