3、MySQL/分布式MySQL在金融场景的实践
金融场景对数据库的要求，说白了就三个字：稳、准、快。稳是数据不能丢，准是账不能错，快是响应不能慢。我在银行核心系统项目里摸爬滚打多年，今天就把MySQL在金融场景的那些实战经验，掰开揉碎了讲给你听。
3.1 MySQL InnoDB集群：金融场景的基石
InnoDB集群，我习惯叫它「MySQL原生的高可用方案」。它由三部分组成：MySQL Shell、MySQL Router和Group Replication。嗯，这里要注意，很多人以为InnoDB集群就是Group Replication，其实不对。Router负责路由，Shell负责管理，GR才是真正的数据同步引擎。
核心要点：InnoDB集群采用Paxos协议实现强一致性，这在金融场景里至关重要。你想想看，银行转账如果出现数据不一致，那后果...
我在项目中遇到过一个问题：某支付系统用InnoDB集群，业务高峰期出现脑裂。排查下来，是网络抖动导致Paxos选举超时。后来我们调整了以下参数：
-- 调整组复制的超时时间
SET GLOBAL group_replication_communication_max_message_size = 1048576;
SET GLOBAL group_replication_flow_control_mode = 'DISABLED';
-- 增加成员超时检测
SET GLOBAL group_replication_member_expel_timeout = 5;
调整后，集群稳定性明显提升。我个人建议，金融场景下group_replication_member_expel_timeout不要设得太短，3-5秒比较合适。
3.2 分布式中间件：MyCat vs ShardingSphere
说到分布式中间件，MyCat和ShardingSphere是绕不开的两个选择。我两个都用过，说说我的真实感受。
| 对比维度 | MyCat | ShardingSphere |
|---|---|---|
| 架构模式 | 代理模式（Proxy） | JDBC/Proxy双模式 |
| SQL兼容性 | 有限，复杂SQL需改写 | 较好，支持大部分SQL |
| 分布式事务 | 弱支持，需配合XA | 强支持，Seata集成 |
| 运维复杂度 | 较低，配置简单 | 较高，但功能丰富 |
| 金融场景适用性 | 适合简单分片场景 | 适合复杂金融业务 |
我曾经在某个金融项目里用MyCat做分库分表。一开始挺顺利，直到遇到跨分片的JOIN查询。MyCat的解决方案是把数据拉到内存里做JOIN，数据量一大就OOM。后来我们换成了ShardingSphere，它的联邦查询引擎能智能下推，性能好了不少。
避坑指南：我曾经踩过一个坑——MyCat的全局序列号在高并发下会重复。后来发现是时间回拨问题。解决方案是用雪花算法替代数据库自增序列。
3.3 金融级高可用方案：MGR + ProxySQL
MGR（MySQL Group Replication）加上ProxySQL，是我目前在金融场景最推荐的高可用组合。为什么？因为MGR解决了数据一致性问题，ProxySQL解决了流量调度问题。
先说说MGR的部署架构。我习惯用单主模式，一主多从，所有写操作都走主节点。为什么不用多主？你想想看，金融场景的写冲突检测成本太高，单主模式反而更简单可靠。
-- MGR单主模式配置示例
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
ProxySQL的配置，我建议重点关注查询路由规则。金融场景里，读多写少是常态。我们可以把报表查询、历史数据查询这些只读操作，全部路由到从节点。
实战经验：我在某银行项目中，用ProxySQL实现了读写分离+故障自动切换。当主节点宕机时，ProxySQL能在1秒内感知并切换流量。具体做法是配置了hostgroup和mysql_replication_hostgroups。
-- ProxySQL读写分离配置
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (0, '192.168.1.1', 3306); -- 写组
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '192.168.1.2', 3306); -- 读组
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '192.168.1.3', 3306); -- 读组
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (0, 1);
3.4 金融场景的特别考量
金融场景和互联网场景最大的区别是什么？我总结了三句话：数据不能丢、交易不能错、系统不能停。
- 数据一致性：金融场景必须保证强一致性。我建议用MGR的SINGLE_PRIMARY模式，配合sync_binlog=1和innodb_flush_log_at_trx_commit=1。
- 性能与安全的平衡：加密传输、审计日志这些安全措施会带来性能损耗。我的做法是：核心交易走加密通道，报表查询走明文通道。
- 容灾与备份：金融监管要求RPO小于15分钟。我习惯用MySQL的Clone Plugin做物理备份，配合Binlog做增量恢复。
重要提醒：金融场景千万不要用异步复制！我见过太多因为异步复制导致的数据丢失案例。哪怕性能差一点，也要用半同步复制或MGR。
3.5 知识体系总览
下面这张图，是我梳理的MySQL在金融场景的知识体系。你可以把它当作一张地图，随时回来对照。
这张图把MySQL在金融场景的核心技术栈都串起来了。从底层的InnoDB集群，到中间层的分布式中间件，再到上层的金融级高可用方案，每一层都有它的职责和最佳实践。
个人建议：刚开始接触金融场景的同学，不要一上来就搞分布式。先把单机MySQL的InnoDB引擎吃透，再逐步扩展到集群和中间件。我见过太多人连buffer pool都没调优过，就急着上ShardingSphere，结果问题一大堆。
好了，这一章的内容就到这里。MySQL在金融场景的实践，说白了就是「稳」字当头。不管是InnoDB集群、分布式中间件还是高可用方案，最终目标都是让数据更安全、系统更可靠。希望这些实战经验能帮你少走弯路。