之后上线详解数据库随之

mysql分表之后如何平滑上线详解

数据库教程 2021-11-29 09:23:35 26

导读

分表的目的 项目开发中,我们的数据库数据越来越大,随之而来的是单个表中数据太多。以至于查询数据变慢,而且由于表的锁机制导致应用操作也受到严重影响,出现了数据库性能瓶颈。 当出现这种情况时,我们可以考虑分表,即将单个数据库表进行拆分,拆分成多个数据表,然后用……

分表的目的

项目开发中,我们的数据库数据越来越大,随之而来的是单个表中数据太多。以至于查询数据变慢,而且由于表的锁机制导致应用操作也受到严重影响,出现了数据库性能瓶颈。

当出现这种情况时,我们可以考虑分表,即将单个数据库表进行拆分,拆分成多个数据表,然后用户访问的时候,根据一定的算法,让用户访问不同的表,这样数据分散到多个数据表中,减少了单个数据表的访问压力。提升了数据库访问性能。

举个栗子

比如咱们最常见的用户表(user表)

 

id user_id 其他字段
主键id 用户id 其他字段

 

咱们一般都会用user_id去查询对应的用户信息,但是随着业务的增长,这张表会越来越大,甚至上亿,严重影响了查询性能。 所以咱们就会对这张表进行分表处理,分到多张表减小查询压力

分表策略

以分10张表为例(具体分多少张表 根据实际情况来估算) 首先咱们建10张表 user1、user2、user3。。。。。user10

一般情况下,我们都会用作为索引的字段(user_id)进行取模处理。想分多少张表,就按照多少取模,比如这个case就是10

$table_name = $user_id % 10;

按照上面的取模公式

  • user_id为1295的会落在user5里面
  • user_id为8634的会落在user4里面
  • 。。。。。。。

「每次CURD根据上面查找表的策略进行就行了」,这个问题不大,我们暂且先不多说。

已经上线的运行中的表怎么办?

其实上面的方法大家应该都知道怎么用,但是有个问题,已经上线了的表怎么办?那张表的数据在线上是一直被查找或者改变的。如何能够进行平滑的分表,并且让用户无感知呢?

方法1

直接上线,提前写个脚本,脚本内容是把旧表(user)的数据同步到user1表到user10表,一上线了赶紧执行

这种方法明显是行不通的,主要是存在以下问题

  • 如果执行过程中脚本有问题怎么办?代码全部回滚?
  • 脚本把把旧表(user)的数据同步到user1表到user10表,这个脚本得执行多久? 如果是1个小时,那么这段时间线上和这张表相关的业务都是不正常的

这显然是行不通的,对线上影响很大。

方法2

先写个同步数据的脚本,脚本内容是把旧表(user)的数据同步到user1表到user10表,脚本同步完了再上线。

这个方法看起来友好了一些,不过也存在一些问题。

  • 脚本同步完,立即上线,这两件事之间是有一些时间差的,这个时间差中线上表可能有一些改动,这些改动怎么办?

「以上两种方法看起来貌似都行不通,所以看来得来点不一样的了。咱们直接看结论。」

步骤1 上线双写

首先咱们把双写上线了,什么意思呢?比如user_id=123,对于增加,删除,修改操作来说,咱们既操作user表,也操作user_id=123对应的user3表。

function modify($user_id){  //包含增加,删除,修改操作
  modify_user();  //modify user表
  $table_name = $user_id % 10;
  modify_user($table_name) //modify对应的分表
}

因为查询的部分还是在user表中查询的,所以上面的操作对线上用户是无任何影响的。

步骤2 全量同步

写一个全量同步user表到user1-user10的表,最好找个低峰期执行脚本,以防万一影响user表的查询

这一步执行之后,因为咱们之前上线了双写(见步骤1),所以user表和user1-user10表之间的数据已经是完全一致的了。

步骤3 查询新表数据

将查询的部分改到user1-user10

因为前面两个步骤咱们已经保证了user表和各个分表之间的数据完全一致性,所以直接把查询的部分改掉是没有任何问题的

如果按照以上步骤执行,那么对线上的数据是没有任何影响的,而且我们线上就是这么操作了,经过了多次实践确保不会出问题,放心使用即可。

1253067 TFnetwork_cn