在实际开发中，数据库的扩容和不同的分库分表规则直接相关。
本文从系统设计的角度，抽象了一个项目开发中出现的业务场景
从数据库设计，路由规则以及数据库迁移方案的角度进行讨论
从业务场景出发进行讨论
假设现在要设计电商网站的订单数据库模块，经过对业务增长的估算
预估三年后，数据规模可能达到6000万，每日订单数会超过10万
- 选择存储实现，订单作为电商业务的核心数据，应该尽量避免数据丢失，并且对数据一致性有强要求。选择支持事务的关系型数据库，比如使用 MySQL及 InnoDB 存储引擎。
- 数据库的高可用，订单数据是典型读多写少的数据。在业务中配置基于主从复制的读写分离，并且设置多个从库，提高数据安全。
- 数据规模，6000万的数据量，显然超出了单表的承受范围。参考《阿里巴巴Java开发手册》中的【单表行数超过500万行】进行分表的建议。
如何设计路由规则和拆分方案？
20230709151930.jpg
哈希取模的方式
哈希取模是根据不同的业务主键输入，对数据库进行取模，得到插入数据的位置。
20230709152123.jpg
通过哈希取模的方式进行路由
- 优点：数据拆分比较均匀
- 缺点：不利于后面的扩容
假设订单增长速度超出预估，数据规模很快达到了几亿的数量级，数据库需要继续进行拆分。为了适配新的分库分表规则，保证数据的读写正常，不可避免地要进行数据迁移。
具体的操作，可以分为停机迁移和不停机迁移。
- 停机迁移
比如在使用一些网站或者应用时，经常会收到某段时间内暂停服务的通知。
一般是在这段时间内，完成数据迁移，将历史数据按照新的规则重新分配到新的存储中，然后切换服务。 - 不停机迁移
不停机迁移也就是常说的动态扩容，依赖业务上的双写操作实现。需要同时处理存量和增量数据，并且做好各种数据校验。
如果重新部署新的数据库存储，可以粗略地分为以下的步骤：
- 创建一套新的订单数据库
- 在某个时间点上，将历史数据按照新的路由规则分配到新的数据库中
- 在旧数据的操作上开启双写，同时写入到两个数据库
- 用新的读写服务逐步替代旧服务，同步进行数据不一致校验，最后完成全面切流
基于数据范围进行拆分
基于数据范围进行路由，通常是根据特定的字段进行划分不同区间对订单表进行拆分中，如果基于数据范围路由，可以按照订单 ID 进行范围的划分。
20230709153059.jpg
结合数据范围和哈希取模，那么是不是可以实现数据均匀分布，也可以更好的进行扩容？
20230709153215.jpg
这种方式避免了单纯基于数据范围可能出现的热点存储，在后期扩展时，可以直接增加对应的扩展表。
总结
回答系统设计类问题，有哪些要注意的点呢？
- 系统设计类问题出现在面试中，很重要的一方面是考察沟通，要和面试官确认整体的数据规模输入和输出，明确系统设计的边界，比如数据规模不同，直接影响数据库表的设计方式。
- 找到主要问题，理解系统的瓶颈，然后就可以应用各种系统设计的技巧，进行各个业务层的设计。
网友评论