CurleyG技术

# 【IT老齐002】聊一聊MySQL经典架构设计及应用场景

需要额外的去学习binlog日志同步，分库分表Mycat和 ShardingSphere

# 单库模式

image.png

  1. 简单粗暴
  2. 适合数据量千万以下小型应用（建议一张表超过千万需要分库分表）
  3. 企业网站，创业公司首选
  4. 不具备可用性与并发性

# 读写分离集群模式

在原有的基础上增加中间层，与后端数据集构成读写分离的集群。

整体基础结构：原有的主库派生出字库1，字库2， 利用mysql原有的主从同步机制（即为：binlog日志同步），将主库的数据变化在从库中复现，保证数据同步。主库一般用于写入处理， 从库负责读取。

细节：如果直接面对主库进行操作无法完成读写分离，需要在前端分配分片中间件（阿里mycat，京东ShardingSphere）, 该中间件通过curd请求,来决定由哪个库处理。MHA中间件实现高可用（即：主服务器坏了，MHA中间件可以将某个从表提升为主服务器）。 所有节点数据均保持同步。适用于读多写少，单表不过千万的互联网应用

image.png

架构复杂度提升，成本提高

所有节点数据均保持同步

适用于读多写少，单表不过千万的互联网应用

配合MHA中间件方案实现高可用性

# 分库分表（分片）集群模式

分库分表（分片）集群模式：一个mysql数据库撑不住的情况下。将数据库的数据分到不同的节点数据库（即：节点数据库的数据合起来为完整的数据体）。 需要用到中间件进行路由。（对sql进行解析，将请求发到对应的数据库，分发请求的过程叫路由）。不具备高可用性。

image.png

  • 架构复杂度提升，成本提高
  • 每个节点数据是所有数据的子集
  • 适用于十亿级数据总量大型应用
  • 不具备高可用特性

# 分片算法

# 范围法

image.png

●范围法结构简单，扩展容易

●适合范围检索

●数据分布不均匀，局部负载压力大

●适用于流水账应用

# HASH法

image.png

●Hash法分为取模与一致性Hash

●数据分配均衡

●节点扩展复杂，数据迁移难度大

●建议提前部署足够的节点

●适用于预算充足的大型互联网应用

互联网主流MySQL集群架构

# 主流应用方案：读写分离+分片集群

image.png

←