MySQL 学习 - 不同场景下技术抉择

淡淡的烟草味﹌ 2023-05-30 15:57 3阅读 0赞

## 前言 ##

在生产环境中，我们往往需要冗余节点，也就是避免线上事故的产生。

PXC集群推荐教程：https://coding.imooc.com/class/274.html

## 业务场景 ##

<table> 
 <thead> 
  <tr> 
   <th>场景</th> 
   <th>对应行业</th> 
   <th>解决方案</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>读多写少</td> 
   <td>电商、新闻、论坛</td> 
   <td>MYSQL + NOSQL</td> 
  </tr> 
  <tr> 
   <td>写多读少</td> 
   <td>滴滴、校园成绩</td> 
   <td>低价值数据：使用NoSQL存储<br>高价值数据：使用TokuDB来存储</td> 
  </tr> 
  <tr> 
   <td>写多读多</td> 
   <td>微信、QQ</td> 
   <td>借助Redis，NoSQL等解决方法</td> 
  </tr> 
 </tbody> 
</table>

## MySQL 衍生版对比 ##

综合对比之下，建议选择 Percona Server

<table> 
 <thead> 
  <tr> 
   <th>产品</th> 
   <th>版本</th> 
   <th>收费情况</th> 
   <th>是否开源</th> 
   <th>性能</th> 
   <th>兼容性</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>MySQL</td> 
   <td>官方原版</td> 
   <td>免费</td> 
   <td>未来可能闭源</td> 
   <td>不好</td> 
   <td>好</td> 
  </tr> 
  <tr> 
   <td>MariaDB</td> 
   <td>社区版</td> 
   <td>免费</td> 
   <td>继续开源</td> 
   <td>较好</td> 
   <td>一般</td> 
  </tr> 
  <tr> 
   <td>Percona</td> 
   <td>企业版</td> 
   <td>免费</td> 
   <td>继续开源</td> 
   <td>最好</td> 
   <td>好</td> 
  </tr> 
 </tbody> 
</table>

## MySQL 存储引擎 ##

其中 `TokuDB` 是要自己安装扩展的，Percona公司官网上有

<table> 
 <thead> 
  <tr> 
   <th>引擎名称</th> 
   <th>事务</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>MyISAM</td> 
   <td>N</td> 
   <td>MySQL5.6之前的默认引擎，最常用的非事务存储引擎</td> 
  </tr> 
  <tr> 
   <td>CSV</td> 
   <td>N</td> 
   <td>以CSV格式存储的非事务型存储引擎</td> 
  </tr> 
  <tr> 
   <td>Archive</td> 
   <td>N</td> 
   <td>只允许查询和新增数据而不允许修改的非事务性存储引擎</td> 
  </tr> 
  <tr> 
   <td>Memory</td> 
   <td>N</td> 
   <td>是一种易失性非事务存储引擎（保存在内存中，重启则无）</td> 
  </tr> 
  <tr> 
   <td>InnoDB</td> 
   <td>Y</td> 
   <td>最常用的事务型存储引擎</td> 
  </tr> 
  <tr> 
   <td>TokuDB</td> 
   <td>Y</td> 
   <td>Percona旗下产品(TokuTek研发)，适合写多读少，冷数据业务</td> 
  </tr> 
 </tbody> 
</table>

## 数据切分中间件 ##

综合对比之下，我们选择 MyCat

<table> 
 <thead> 
  <tr> 
   <th>产品</th> 
   <th align="center">收费情况</th> 
   <th align="center">是否开源</th> 
   <th align="center">普及率</th> 
   <th>功能</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>MyCat</td> 
   <td align="center">免费</td> 
   <td align="center">开源</td> 
   <td align="center">高</td> 
   <td>分片算法丰富、读写分离、全局主键、分布式事务</td> 
  </tr> 
  <tr> 
   <td>Atlas</td> 
   <td align="center">免费</td> 
   <td align="center">开源</td> 
   <td align="center">低</td> 
   <td>分片算法较少、读写分离</td> 
  </tr> 
  <tr> 
   <td>One Proxy</td> 
   <td align="center">免费版/企业版</td> 
   <td align="center">闭源</td> 
   <td align="center">低</td> 
   <td>分片算法较少、读写分离</td> 
  </tr> 
  <tr> 
   <td>Proxy SQL</td> 
   <td align="center">免费</td> 
   <td align="center">开源</td> 
   <td align="center">一般</td> 
   <td>分片算法较少、读写分离</td> 
  </tr> 
 </tbody> 
</table>

## 负载均衡中间件对比 ##

综合考虑之下，使用 `Haproxy` 因为nginx刚刚支持没多久，先看看情况

<table> 
 <thead> 
  <tr> 
   <th>比较</th> 
   <th>Haproxy</th> 
   <th>Nginx</th> 
   <th>Apache</th> 
   <th>LVS</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>是否免费</td> 
   <td>免费</td> 
   <td>免费</td> 
   <td>免费</td> 
   <td>免费</td> 
  </tr> 
  <tr> 
   <td>支持虚拟机</td> 
   <td>支持</td> 
   <td>支持</td> 
   <td>支持</td> 
   <td>否</td> 
  </tr> 
  <tr> 
   <td>HTTP协议</td> 
   <td>支持</td> 
   <td>支持</td> 
   <td>支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>ICP/IP协议</td> 
   <td>支持</td> 
   <td>刚刚支持</td> 
   <td>不支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>支持插件</td> 
   <td>不支持</td> 
   <td>支持</td> 
   <td>不支持</td> 
   <td>不支持</td> 
  </tr> 
  <tr> 
   <td>性能</td> 
   <td>好</td> 
   <td>好</td> 
   <td>一般</td> 
   <td>最好</td> 
  </tr> 
 </tbody> 
</table>

## 数据库负载均衡的必要性 ##

*  虽然搭建了集群，但是不使用数据库负载均衡，单节点处理所有请求，负载高，性能差
 *  使用Haproxy做负载均衡，请求被均匀分发到每个节点，单节点负载低，性能好

## 单节点数据库的弊病 ##

*  大型互联网程序用户群体庞大，所以架构必须要特殊设计
 *  单节点的数据库无法满足性能上的要求
 *  单节点的数据库没有冗余设计，无法满足高可用

## 常见集群架构 ##

数据集群方案

<table> 
 <thead> 
  <tr> 
   <th>方案</th> 
   <th>强一致性</th> 
   <th>写入速度</th> 
   <th>写入方式</th> 
   <th>适合场景</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>PXC</td> 
   <td>是</td> 
   <td>慢</td> 
   <td>任意节点</td> 
   <td>高价值数据</td> 
  </tr> 
  <tr> 
   <td>Replication</td> 
   <td>否</td> 
   <td>快</td> 
   <td>主写，从读</td> 
   <td>低价值数据</td> 
  </tr> 
 </tbody> 
</table>

集群方法的优点

*  数据库集群能支持更大规模的并发访问，并且存放更多的数据
 *  降低单表数量，不让他超过2000万，使用MyCat做数据切分

PXC的数据强一致性

*  同步复制，事务在所有集群节点上要么同时提交，要么不提交
 *  Replication采用异步复制，无法保证数据的一致性

PXC和Replication方案优劣

*  Replication写入数据快，但是不能保证数据的一致性
 *  PXC可以保证数据的一致性，但是写入速度慢
 *  PXC方案实双向的，任意一个MySQL节点上都可以读写数据
 *  Replication方案，单向的，不是每一个节点都可以读写

两者优势各不同，生成环境我们可以采用组合方案

*  PXC方案存储高价值数据，如：账号、订单、交易等等
 *  Replication方案存储低价值数据，如：权限、通知、日志等等
 *  用MyCat 或者 JDBC-Sharding切分数据管理集群

存在风险注意问题：

*  PXC集群最好使用 奇数方案，不要使用偶数 (避免脑裂)

PXC方案写入图解

*  可以看到，在提交时通过事务，确保所有节点都写入成功后，返回成功
 *  这也就是为什么PXC集群，每个主机配置要一致的问题，因为都要等节点写入成功  
    ![PXC方案图解][PXC]

Replication方法写入图解

*  可以看到，在提交时，主成功了也就直接返回了
 *  这时如果从服务在同步时出问题，就会导致数据不一致 (从查找不到订单这类问题)  
    ![Replication图解][Replication]

## 最终架构 ##

https://www.processon.com/view/link/5dac1642e4b0335f1d3c0086

![组织架构][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94aWFtZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]

## 知名公司记录 ##

*  2016年春节，微信红包支付峰值153.8万次/秒，创下世界纪录
 *  2017天猫双11，数据库峰值4200万次/秒，支付峰值25.6万次/秒

[PXC]: https://img-blog.csdnimg.cn/20191111110219867.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aWFtZW4uYmxvZy5jc2RuLm5ldA==,size_16,color_FFFFFF,t_70
[Replication]: https://img-blog.csdnimg.cn/20191111110201254.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aWFtZW4uYmxvZy5jc2RuLm5ldA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94aWFtZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191111110128728.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aWFtZW4uYmxvZy5jc2RuLm5ldA==,size_16,color_FFFFFF,t_70