是的，这是个好主意。将proxysql与pxc结合使用也是一个好主意。通过使用proxysql，您可以：a）通过将两个节点放入同一主机组中来实现“writer”ha，一个节点具有超高的权重（10000000），另一个节点具有较低的权重（10）。如果高权重节点脱机，proxysql将无缝地开始向另一个节点发送流量。b） 将所有节点放入一个具有相同权重的独立“读卡器”主机组，从而实现写流量的负载平衡。c） 如果需要，可以创建一个只有1个节点的第三个主机组，并为“高负载”查询创建一个查询规则来匹配模式、用户或查询模式，并直接执行到该特定节点。proxysql还可以让您缓存一些严重的查询。
就我个人而言，除非你知道你的网络坚如磐石，否则我会选择更少的示例和更高的cpu。在pxc中，所有节点必须同步地确认所有事务。节点越多，这些操作所需的延迟就越长。可以提交的最快时间是两个最慢节点之间的时间。请确保你总是有一个奇数个节点，除非你得到先进的pc.weight设置（但这是超级棘手的获得权利）。
一般来说，对于mysql，所有节点都应该是相同的配置。如果你的主人比奴隶更强大，一般来说，奴隶就跟不上数量。使用pxc，这意味着您将更频繁地经历流控制事件，这可能导致应用程序暂停。如果node2不能像node1那样快速地写，node2就会发出流控制消息（呼救），请求其他节点在它赶上的时候放慢速度。
是的，如#1所述使用proxysql。
请注意，查询优化是“加快速度”的第一种方法。不要总是用硬件来解决问题。花点时间检查您缓慢的查询日志并尝试改进查询是值得的。有时，一个单一的指数可以使一个晚上/白天的差异。
免责声明：我是percona的高级讲师，已经完成了许多全天的pxc和proxysql密集型教程。

看来你的尖刺才是问题所在。而且你需要尽可能快地处理洪水，因为用户希望得到那些热门门票。
添加队列只会增加复杂性，并在动作很快时减慢处理速度。所以“不要排队，就这样做吧。”进一步注意，队列将被过渡地复制到其他节点，从而使得排队/出列可能比简单地对请求进行操作要慢！
连接-做某事-断开连接需要时间。很多时候并不是真的涉及到“某物”，而是围绕着它。我发现，如果只有不到10个连接处于活动状态，事情就会顺利进行。但是，如果超过10家公司成功启动，那么innodb就会开始自我绊倒。
去过拥挤的商店吗？假设所有过道都能容纳200人和手推车。但如果你试着有210个顾客，每个人都会放慢脚步，只是为了争夺一个职位。吞吐量下降，可能到了人们想弃车休假的地步。你见过前面排着队的商店吗？他们解决了这个问题，不允许超过200同时购物者！
所以，问题的解决方案可能在mysql之外。如果你有一个面向mysql的网页，那么就限制它的线程数。例如，apache有这样的功能，还有一个“backlog”，用于在connecttoapache级别排队。mysql有 max_connections 以及 backlog 可能也是这样，但是 max_connections （151）太高。151名学生挤在便利店的汽水机旁或许是一个更好的类比。
多个节点/多个CPU可能是答案的一部分，也可能不是答案的一部分；这取决于什么锁是由“某物”取出的。
班长 Threads_running ; 如果它增长到几十个以上，那么我怀疑我的评论适用。如果监视器程序无法连接，请检查 GLOBAL STATUS ，那么我知道它适用。