admin 管理员组文章数量: 1184232
2024年4月15日发(作者：正则表达式验证工具)
MySQL 分布式系统架构设计偏向扩容问
题 + 业务拆分
分库分表
随着数据量的不断增长，数据库的发展主要经历以下几个步骤：
•
•
•
•
•
•
1 主 - 1 从架构
双主 - 多从架构，读写分离
表分区，提高并发
分表，提高并发
Master 更换 SSD
分库，分表，提高并发
分库分表实现过程
可以将业务库划分成 16 个库，每个库 64 个表进行存储，总共 1024 个表，
MySQL 单表性能超过千万级别会导致性能严重下降，假设按千万计算，最高可
以存储百亿级数据量。随着存储问题的解决，但复杂度会随着增加：
多库怎么保证生成的全局唯一 ID
查询复杂度的增加；
例如：商城购物的订单中心，当买家查询订单时，应该去哪个库哪个表里查找，
卖家应该去哪查；再大的存储量，随着数据量的增长，终究是会遇到瓶颈，该
怎么扩容。
全局唯一订单号
采用 Twitter snowflake 方案，全剧唯一 ID 生成由：时间戳 + 机器 ID + 自增序
列（+userid 后两位）；
订单的生成过程直接在应用实例中生成，直接在内存中计算，且计算过程分散
到每台应用实例中，解决性能问题，userid 后两位在后面解释。
数据库连接问题
分库分表后，要连接数据库变的复杂起来，分为两种方案：
直连代码适配模式
此种方式需要在应用代码中，自己计算订单应该进入哪个库，可取订单的后两
位，先对库 16 进行取模，再对表 64 取模，从而确定。优点是直连数据库性能
更好，缺点是代码复杂度增加。
通过中间价连接
服务中间价可以使用阿里的 mycat 连接，具体使用查看 mycat 文档。优点：代
码实现简单，跟分库前差不多。
数据查询操作
用户需要查询数据的时候，只有 userid，并不知道数据存在哪个库哪张表中，
从每个库每个表中遍历一遍不现实。所以还要对唯一编号进行改进，之前是：
时间戳 + 机器 ID + 自增序列。现在此 ID 的后面加上 userid 的后两位，时间戳
+ 机器 ID + 自增序列 + userid 后两位。
例如：订单入库取模的后两位即 userid 后两位，即同一个买家的所有订单都会
存入同一个表中，通过此设计买家即可找到订单号应该在哪个表中。
扩容问题
此方案已经不是单纯的通过订单号查找订单，还需要通过 userid 查找订单，其
次是订单具有时间特性，用户查询的大部分都是最近的订单，3 月前的订单很
少会查看，所以不适合进行扩容，特别适合迁移历史数据，将 3 个月前的数据
迁移到历史数据库中，从而解决容量增长的问题。
业务拆分
业务极其复杂，不只是订单号的生成插入等，还要减库存、支付等一系列的操
作。所以应该通过消息队列将业务进行拆分，本步骤只做订单生成的操作，通
过消息队列实现数据的最终一致性。
多主架构
版权声明：本文标题：MySQL 分布式系统架构设计偏向扩容问题 + 业务拆分 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/p/1713114471a620561.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论