MySQL 学习 - 不同场景下技术抉择
前言
在生产环境中，我们往往需要冗余节点，也就是避免线上事故的产生。
PXC集群推荐教程：https://coding.imooc.com/class/274.html
业务场景
| 场景 | 对应行业 | 解决方案 |
|---|---|---|
| 读多写少 | 电商、新闻、论坛 | MYSQL + NOSQL |
| 写多读少 | 滴滴、校园成绩 | 低价值数据：使用NoSQL存储 高价值数据：使用TokuDB来存储 |
| 写多读多 | 微信、QQ | 借助Redis，NoSQL等解决方法 |
MySQL 衍生版对比
综合对比之下，建议选择 Percona Server
| 产品 | 版本 | 收费情况 | 是否开源 | 性能 | 兼容性 |
|---|---|---|---|---|---|
| MySQL | 官方原版 | 免费 | 未来可能闭源 | 不好 | 好 |
| MariaDB | 社区版 | 免费 | 继续开源 | 较好 | 一般 |
| Percona | 企业版 | 免费 | 继续开源 | 最好 | 好 |
MySQL 存储引擎
其中 TokuDB 是要自己安装扩展的，Percona公司官网上有
| 引擎名称 | 事务 | 说明 |
|---|---|---|
| MyISAM | N | MySQL5.6之前的默认引擎，最常用的非事务存储引擎 |
| CSV | N | 以CSV格式存储的非事务型存储引擎 |
| Archive | N | 只允许查询和新增数据而不允许修改的非事务性存储引擎 |
| Memory | N | 是一种易失性非事务存储引擎（保存在内存中，重启则无） |
| InnoDB | Y | 最常用的事务型存储引擎 |
| TokuDB | Y | Percona旗下产品(TokuTek研发)，适合写多读少，冷数据业务 |
数据切分中间件
综合对比之下，我们选择 MyCat
| 产品 | 收费情况 | 是否开源 | 普及率 | 功能 |
|---|---|---|---|---|
| MyCat | 免费 | 开源 | 高 | 分片算法丰富、读写分离、全局主键、分布式事务 |
| Atlas | 免费 | 开源 | 低 | 分片算法较少、读写分离 |
| One Proxy | 免费版/企业版 | 闭源 | 低 | 分片算法较少、读写分离 |
| Proxy SQL | 免费 | 开源 | 一般 | 分片算法较少、读写分离 |
负载均衡中间件对比
综合考虑之下，使用 Haproxy 因为nginx刚刚支持没多久，先看看情况
| 比较 | Haproxy | Nginx | Apache | LVS |
|---|---|---|---|---|
| 是否免费 | 免费 | 免费 | 免费 | 免费 |
| 支持虚拟机 | 支持 | 支持 | 支持 | 否 |
| HTTP协议 | 支持 | 支持 | 支持 | 支持 |
| ICP/IP协议 | 支持 | 刚刚支持 | 不支持 | 支持 |
| 支持插件 | 不支持 | 支持 | 不支持 | 不支持 |
| 性能 | 好 | 好 | 一般 | 最好 |
数据库负载均衡的必要性
- 虽然搭建了集群，但是不使用数据库负载均衡，单节点处理所有请求，负载高，性能差
- 使用Haproxy做负载均衡，请求被均匀分发到每个节点，单节点负载低，性能好
单节点数据库的弊病
- 大型互联网程序用户群体庞大，所以架构必须要特殊设计
- 单节点的数据库无法满足性能上的要求
- 单节点的数据库没有冗余设计，无法满足高可用
常见集群架构
数据集群方案
| 方案 | 强一致性 | 写入速度 | 写入方式 | 适合场景 |
|---|---|---|---|---|
| PXC | 是 | 慢 | 任意节点 | 高价值数据 |
| Replication | 否 | 快 | 主写，从读 | 低价值数据 |
集群方法的优点
- 数据库集群能支持更大规模的并发访问，并且存放更多的数据
- 降低单表数量，不让他超过2000万，使用MyCat做数据切分
PXC的数据强一致性
- 同步复制，事务在所有集群节点上要么同时提交，要么不提交
- Replication采用异步复制，无法保证数据的一致性
PXC和Replication方案优劣
- Replication写入数据快，但是不能保证数据的一致性
- PXC可以保证数据的一致性，但是写入速度慢
- PXC方案实双向的，任意一个MySQL节点上都可以读写数据
- Replication方案，单向的，不是每一个节点都可以读写
两者优势各不同，生成环境我们可以采用组合方案
- PXC方案存储高价值数据，如：账号、订单、交易等等
- Replication方案存储低价值数据，如：权限、通知、日志等等
- 用MyCat 或者 JDBC-Sharding切分数据管理集群
存在风险注意问题：
- PXC集群最好使用 奇数方案，不要使用偶数 (避免脑裂)
PXC方案写入图解
- 可以看到，在提交时通过事务，确保所有节点都写入成功后，返回成功
- 这也就是为什么PXC集群，每个主机配置要一致的问题，因为都要等节点写入成功
Replication方法写入图解
- 可以看到，在提交时，主成功了也就直接返回了
- 这时如果从服务在同步时出问题，就会导致数据不一致 (从查找不到订单这类问题)
最终架构
https://www.processon.com/view/link/5dac1642e4b0335f1d3c0086
知名公司记录
- 2016年春节，微信红包支付峰值153.8万次/秒，创下世界纪录
- 2017天猫双11，数据库峰值4200万次/秒，支付峰值25.6万次/秒