本文介绍了如何应对小型系统到大规模系统的数据库架构升级，从单机数据库到分库分表，再到读写分离，以支撑百万并发。通过实例分析了数据库分库分表的策略，如根据订单ID进行Hash取模，以及大量分表以减少单表数据量，确保查询性能。同时，讨论了分布式全局唯一ID的生成方案，并提出了读写分离来优化读取性能，以应对高并发场景。
相信看到这个标题，很多人的第一反应就是：对数据库进行分库分表啊！但是实际上，数据库层面的分库分表到底是用来干什么的，其不同的作用如何应对不同的场景，我觉得很多同学可能都没搞清楚。
小型系统的典型数据库单机架构和明显的瓶颈
假如我们现在是一个小创业公司，注册用户就 20 万，每天活跃用户就 1 万，每天单表数据量就 1000，然后高峰期每秒钟并发请求最多就 10。
天呐！就这种系统，随便找一个有几年工作经验的高级工程师，然后带几个年轻工程师，随便干干都可以做出来。
因为这样的系统，实际上主要就是在前期进行快速的业务功能开发，搞一个单块系统部署在一台服务器上，然后连接一个数据库就可以了。
接着大家就是不停地在一个工程里填充进去各种业务代码，尽快把公司的业务支撑起来。
结果呢，没想到我们运气这么好，碰上个优秀的 CEO 带着我们走上了康庄大道！
公司业务发展迅猛，过了几个月，注册用户数达到了 2000 万！每天活跃用户数 100 万！每天单表新增数据量达到 50 万条！高峰期每秒请求量达到 1 万！
同时公司还顺带着融资了两轮，估值达到了惊人的几亿美金！一只朝气蓬勃的幼年独角兽的节奏！
好吧，现在大家感觉压力已经有点大了，为啥呢？因为每天单表新增 50 万条数据，一个月就多 1500 万条数据，一年下来单表会达到上亿条数据。
经过一段时间的运行，现在咱们单表已经两三千万条数据了，勉强还能支撑着。
但是，眼见着系统访问数据库的性能怎么越来越差呢，单表数据量越来越大，拖垮了一些复杂查询 SQL 的性能啊！
然后高峰期请求现在是每秒 1 万，咱们的系统在线上部署了 20 台机器，平均每台机器每秒支撑 500 请求，这个还能抗住，没啥大问题。但是数据库层面呢？
如果
最低0.47元/天 解锁文章
扫一扫
1339
到【灌水乐园】发言
