说明：
(1)、 项目业务拆分：业务大项目做业务垂直分割，同时 MySQL 层根据业务需
求切割分库（比如：电商项目拆成订单子模块， 物流派送子模块，用户子模块
等）。数据库根据业务划分切分库后，不同模块之间数据交互通过接口来进行数
据通信；
(2)、 MySQL 存储层：采用 MySQL Group Rreplication(组复制)三节点，若
项目暂时没有多数据机房部署(多个 DC)需求，就使用单主模式(1 主 2 从，见上
图：其中 M1,S11,S12 )。上图关于 S13 和 S14 两台从库，一台 S14 从库专提
供给 ElasticSearch 或者大数据做 Binlog 增量数据抽取；另一台 S13 从库可以
提供做延迟备份从库，该从库和其主库数据同步延迟 12 个小时(可配置)，用于
防范 DDL&DML 误操作及时恢复；S11 和 S12 为 OLTP 业务系统读从库，M1
为 其 主 库 。 若 程 序 代 码 发 送 含 事 务 SQL 包 ( 包 含 SELECT,
INSERT/UPDATE/DELETE 代码包)，那么中间件会将该 SQL 包放到主库执行，
即主库也会支持部分读操作流量。
另：若后期有多机房需求，才开启多主模式（例如：2 个主或者 3 个主库都可以
写入）。
(3)、DB 系统架构和高可用说明：
3.1、MySQL 组复制单主模式+proxysql。在当前主库宕机后，组复制会重
新选举一个新主库，结合 proxysql 重新识别新主库和从库，重新将读写路由到
生存的 DB 节点上；
3.2、proxysql + haproxy 结合使用，使得 proxysql 负载均衡，以及负责
proxysql 的高可用。而中间件 proxysql 负责 MySQL 的读写分离以及分库；
(4)、中间件和 DB 存储层网络分离： 中间件和 DB 层网段分离，采用不同网段
IP，APP 通过中间件访问数据库，DB 层只开通 3306 端口映射到中间件层，确
保 DB 安全；
(5)、禁用 MySQL 的存储过程，函数，触发器和事件：由于 MySQL 的存储过
程，函数，触发器和事件执行性能不好，特别在高并发的应用程序，因此不建议
在 MySQL 数据库上部署存储过程，函数，触发器和事件；
评论0
最新资源