这些日子为了解决业务上的挑战，想要解决 MySQL 的性能提升方案。

目前找了主要有：

  1. 分库分表
  2. 读写分离

读写分离最简单，牺牲一点一致性能减少读的压力，分表也比较简单，但是目前没有特别合适的中间件，结合我们的业务场景，分库是目前最适合下点功夫的。（另外还需要做高可用，可以做双主，但是不需要我过多参与，因此这里不谈。）

背景介绍

  • MongoDB 用来存储大部分非事务相关的业务
  • MySQL 用来做电商相关业务，所有数据几乎都与账户 ID 相关
  • 账户 ID 是 MongoDB 的 ObjectId
  • 对于普通用户来说没有关联到其他用户的操作
  • 管理员需要统计以及查看所有的用户数据

分库算法

一致性 hash

需要停机，遍历所有库，将需要移动的数据移动到新的库上。【1】【3】

具体步骤

停机 => 数据迁移（不删除旧数据） => 调整服务器配置 => 上线 => 遍历检查并删除各个库冗余的数据

优点
  • 平滑提升性能，节约服务器
  • 迁移过程中移动数据很少
缺点
  • 线上迁移时间时间会比较久
  • 计算速度没有取模快

取模

  • 也算是一种一致性 hash，只不过更简单；
  • 拆库的方案是按 2 的倍数去拆，比如先拆成 2 个库，然后需要扩容的时候拆成 4 个，不然的话可能每次迁移都得全部重新迁移；
具体步骤

停机 => 所有的库复制一份 => 调整服务器配置 => 上线 => 遍历检查并删除各个库冗余的数据

优点
  • 数据会非常均匀；
  • 由于不用操作迁移数据库，直接使用备份恢复的方式，线上扩容速度会快很多；
  • 一次拆库之后能坚持很长时间；
缺点
  • 比较耗服务器，比如每个库最多放 100W 个用户的数据，那数据涨到 150W 左右的时候就应该拆分了；
    无论怎么拆，性能都是跳跃性提升的，不能平滑提升；
  • 由于我们使用的是 mongodb 的 ObjectId，数据不均匀的可能性非常高；

好了，无论怎么分，都会涉及到停机升级的问题，但是停机意味着损失收入，那么为了解决停机的问题，我们找到了一个迁移方案：** 索引表 **。【2】

经过上面的比较，为了让数据库不停机以及迁移尽可能快，我们选择 一致性 hash 方案再加上索引表：

  • 每次根据用户 ID 取库的时候，先查索引表，如果没有，再计算；
  • 开启定时任务，定期扫描，迁移数据，再更新索引表；

迁移需要注意一点就是需要锁住数据，手动进行 两阶段事务，不然可能会造成数据不一致，然后这个迁移任务尽量在凌晨无人的时候进行，而且也只是单个用户，因此这样可以将对用户的影响减到最少。【2】

几个问题

  1. 是否需要公共库？
    如果是公共库，很可能是跟事务不相关的，移到 MongoDB 即可。
  2. MySQL ID 自增怎么解决？
    换成 ObjectID，或者 UUID 之类的。
  3. Node.js 有没有相关的中间件？
    可以看看 TribeDB，但是不满足我们目前的需求。（蠢蠢欲动想要造轮子了
  4. select *，order by 之类的需要跨库，或者联合所有库的操作怎么办？
    这些操作在我们这一般是管理后台才要用，所以可以放到其它工具去做，比如 elasticsearch，而且这样的查询会影响数据库性能，我们巴不得砍掉这些查询

其他问题可以看看【2】，内容很详实。

Reference

【1】. https://cnodejs.org/topic/5502a23573263b0e4eef9b85
【2】. http://www.infoq.com/cn/articles/yupoo-partition-database
【3】. https://github.com/3rd-Eden/node-hashring

原链接: https://github.com/xizhibei/blog/issues/20

知识共享许可协议

本文采用 署名 - 非商业性使用 - 相同方式共享（BY-NC-SA） 进行许可。