分布式MySQL架构

Posted 2021-11-06 gonghaiyu

分布式数据库一般是以下的这种结构，计算层获取元数据层信息进行路由。下面说下各个层级的目的：

（1）计算层就是单机时的SQL层，用来对数据访问进行权限检查、路由访问，以及对计算结果等操作。
（2）元数据层记录了分布式数据库集群下有多少个存储节点，对应IP、端口等元数据信息是多少。当分布式数据库的计算层启动时，会优先访问元数据层，获取所有集群信息，才能正确进行SQL解析和SQL执行路由。
（3）存储层用来存放数据，但存储层要和计算层在同一台服务器上，甚至不求在同一个进程中。
从可用性的角度看，如果存储层发生宕机，那么只会影响 1/N 的数据，N 取决于数据被打散到多少台服务器上。所以，分布式数据库的可用性对比单机会有很大提升，单机数据库要实现99.999% 的可用性或许很难，但是分布式数据库就容易多了。
其引入了新的分布式服务的几大问题，包括自增实现、索引设计、分布式事务、分片副本等。

在分布式mysql架构下，客户端不再是访问MySQL数据库本身，而是访问一个分布式中间件。

关于分片键的选择

选择分片的算法，比较常见的有 RANGE 和 HASH 算法。

1. RANGE算法。
   缺点：该算法不能解决传输数据库的两个痛点。
   （1）性能可扩展，通过增加分片节点，性能可以线性提升；
   （2）存储容量可扩展，通过增加分片节点，解决单点存储容量的数据瓶颈。
   优点：方便将数据在不同节点之间进行迁移。

2. Hash分区算法。对于海量并发的OLTP业务来说，建议采用这种方式。这种方式在NG上也比较常用。

分布式数据库架构设计的原则是：选择一个适合的分片键和分片算法，把数据打散，并且业务（角度）的绝大部分查询都是根据分片键进行访问。

互联网业务的分片键就是用户的ID，业务的大部分访问都是根据用户ID进行查询，比如：

1. 查看某个用户下的微博/短视频；
2. 查看某个用户的商品信息/购买记录。

分库分表

分库分表的目前是确定数据流。即通过以下方式可以确定。

分片 = 实例 + 库 + 表 = ip@port:db_name:table_name

很多情况下一般都采用既分库又分表的方式。有以下两个优点：

1. 不同分片的数据可以在同一MySQL数据库实例上，便于做容量的规划和后期的扩展；
2. 同一分片键的表都在同一个库下，方便做整体数据迁移和扩容。

按上面这样的分布式设计，数据分片完成后，所有的库表依然是在同一个 MySQL实例上！！！

扩缩容

在 HASH 分片的例子中，我们把数据分片到了 4 个节点，然而在生产环境中，为了方便之后的扩缩容操作，推荐一开始就把分片的数量设置为不少于 1000 个。

不用担心分片数量太多，因为分片 1 个还是 1000 个，管理方式都是一样的，但是 1000 个，意味着可以扩容到 1000 个实例上，对于一般业务来说，1000 个实例足够满足业务的需求了（BTW，网传阿里某核心业务的分布式数据库分片数量为 10000个）。

一般公司建议分片数后能满足最近5年以上的业务发展，并且是2的指数倍数，便于后期的扩容或缩容。