mysql集群有哪些方式

坦白讲，选择MySQL集群很复杂，就是如何平衡可用性、性能和成本。
虽然LVS+Keepalived的脑裂问题比较烦人，但是在我们去年跑的3 000级项目中，它是最容易使用的。
毕竟这是K8 环境下的一套； DRBD+Heartbeat看似高可用，但去年测试切换花了近5 分钟，关键公司应付不了。
MySQLProxy 非常酷。
使用Lua分表可以省掉很多修改客户端的精力，但是今年测试发现针对慢查询优化有点慢。

说实话，这很令人困惑。
一开始我以为Keepalived有裂脑保护，后来发现必须手动配置。
还有一点是，在双主复制场景下，当数据同步延迟超过5 秒时，MHA会自动进行故障转移。
但是，如果您使用InnoDB，Cobar的异步复制解决方案可能会更简单。
去年测试1 0000个同时测试时，延迟控制在毫秒以内。
还有另一个关键细节。
Amoeba支持读写分离，但部署时记得调整其缓存策略，否则当QPS达到3 万时，主从延迟会飙升。

等一下，还有一件事，商业案例需要辩证地看待。
MySQLCluster社区版没有InnoDB，但是一些金融客户用它来管理交易量，效果确实不错。
建议先画一张拓扑图，明确标记数据流向和切换点，然后再决定使用哪一种。

MySQL大型分布式集群具体怎么做

分布式：将大型企业划分为较小的企业，每个企业运行一台服务器。
集群：同一业务在多台服务器上进行。
数据分割：将数据分成块并分散存储。
数据库中间件：帮助对数据进行分段，以便于读写。
分布式+集群：提高读写速度。
主从/主主复制：备份数据以防丢失。
负载平衡：明智地分配访问以防止服务器故障。
高可用性：系统全天候运行，服务连续。
分库分表：数据量大，存储分散。
你自己掂量一下吧。

MySQL数据库和Go语言：如何进行数据集群处理？

好的，我们来谈谈使用 MySQL 和 Go 进行集群。
您列出的三件事都非常重要。
我给大家讲一下我遇到的坑和看到的做法。

上周有客户问我关于MySQL集群架构选择的问题。
实在是让人头疼。

你是对的。
选择架构取决于业务。
我们当时接手了一个电商系统，日活几万用户，写的多看的少。
起初，我想创建一个主从系统。
我以为这很容易。
运维师傅每天都在讲这个省事。
结果呢？ 大促当天，主数据库宕机了。
从库延迟增加到几秒。
用户抱怨声甚至比双十一还要大。
后来我咬牙去了主集群，用了Galera。
最初的配置让人不知所措，数据冲突和锁等待让我头发都秃了。
但运行之后发现并发确实增加了，读取也更快了。
不过，运维师傅的压力也很大。
节点较多，监控、备份复杂。
所以你看，主从适合少写多读，主从适合高并发读写，NDB内存引擎适合极限性能要求但必须能够接受数据丢失的风险，Galera一致性好但配置是一个障碍。
不要只阅读文档，而是实际测试它。

Go玩MySQL集群，并发方面确实不错
Go的并发模型真的很神奇。
我们有一个查询接口，它过去在单线程上运行并且像乌龟一样慢。
后来改成了goroutine池。
每个请求都需要一个goroutine连接数据库，并使用通道来传输结果，速度快了十倍以上。
官方的database/sql包很容易使用，并且带有内置的连接池。
SetMaxOpenConns和SetMaxIdleConns可以很好的调整，这样可以省去很多麻烦。
一个陷阱是默认的连接池大小可能不够，必须根据机器性能和并发量手动调整。
在我们的中间件项目中，我们将最大连接数设置为CPU核心数的4 倍，效果相当不错。
Go-MySQL-Driver等第三方驱动的性能也不错，但源码没有官方那么透明。
关键是要利用好goroutine异步处理，不要让数据库操作阻塞主线程，这是主要的性能因素。

配置与优化，细节决定成败
我们搭建集群的时候不能只堆硬件，配置也要跟上。

中间件是读写分离的关键。
我们使用ProxySQL，它比MySQLProxy稳定很多，还可以做SQL重写和缓存策略。
Go代码中封装了一个函数，根据SQL关键字（比如SELECT）判断是读还是写，然后路由到那里。
但需要注意的是，一些复杂的SQL，比如涉及多表JOIN的SQL，可能需要回到主库执行，否则从库可能无法运行。
数据同步。
主从使用binlog，必须开启。
我们监控延迟并使用 Prometheus 捕获 SHOW SLAVE STATUS 落后于 Master 的秒数。
如果延迟超过1 秒，我们就会报警。
大师用的是Galera。
GTID是个好东西，解决了主从切换的麻烦。
但需要注意的是，Galera的写入性能比master-slave差很多。
就看商家能否接受。
连接池。
不要将 SetMaxOpenConns 设置得太小，也不要将 SetMaxIdleConns 设置得太大。
我们通常将其设置为最大连接数的1 /4 到1 /2 否则高峰期无法连接数据库，非高峰期造成资源浪费。
必须根据实际QPS进行调整。
故障排除。
这非常重要！ 我们有一个重试机制，使用指数退避算法。
如果失败，我们会过一段时间再试。
并且它必须能够识别连接确实断开了（例如ErrBadConn），而不是暂时的网络抖动。
另外，一定要有一个自动切换的方案，比如使用Keepalived+Keepbase。
如果主库出现故障，从库会自动连接。
但切换过程中可能会出现数据丢失的情况，这必须是业务可以接受的。

最后随便说一下
监控、压测是必须的。
我们使用Prometheus+Grafana来检查集群状态，各种指标实时可见。
JMeter、k6 等压力测试工具都可以。
了解大促的峰值是多少，提前进行压力测试和调优。
高并发下，Go代码也必须处理。
例如，减少不必要的锁、使用批量操作而不是单次插入可以节省大量资源。
分库分表是最终的解决方案，但是又是一个复杂的系统，比如ShardingSphere，有很多东西可以玩，但是初期投入也很大。
不管怎样，对于集群来说，没有最好，只有最适合。
你要根据自己的业务特点、预算、运维能力来权衡。