摘要
上一篇文章已经说根据school_id进行分表。通常我们的分表策略有两种方式
- 取模分表
- 范围分表
取模分表
所谓的取模分表就是对分表key取模，通过预估数据量确定分几张表那么则模以几。
在我们设计系统之前，可以先预估一下大概这几年的数据量，如：8000万。每张表我们可以容纳2000万，也我们可以设计4张表进行存储。对指定的路由key（如：school_id）对分表总数进行取模，上图中，id=13的任务，对4进行取模，也就是会得到1，那此订单会放到1表中。id=26的订单，取模得到为2，就会放到2表中。
优点
任务数据可以均匀的放到那4张表中，这样此任务进行操作时，就不会有热点问题。
学习任务有个特点就是时间属性，一般用户操作任务数据，都会集中到这段时间的任务。如果这段时间产生的任务都在同一张任务表中，那就会形成热点，那张表的压力会比较大。
缺点
将来的数据扩容会很难。
随着业务的发展时间的推移，学习任务量很大，超出了8000万的量，那我们就需要增加分表数。如果我们增加4个表。一旦我们增加了分表的总数，取模的基数就会变成8，以前id=13的任务按照此方案就会到5表中查询，但之前的此任务数据在1表的，这样就导致了数据查不到。就是因为取模的基数产生了变化。
遇到这个情况，我们小伙伴想到的方案就是做数据迁移，把之前的8000万数据，重新做一个hash方案，放到新的规划分表中。也就是我们要做数据迁移。
范围分表
范围分表方案也就是以范围进行拆分数据。
范围方案比较简单，就是把一定范围内的任务，存放到一个表中；如上图school_id=13放到0表中，school_id=23456的放到2表中。设计这个方案时就是前期把表的范围设计好。通过school_id进行路由存放。
优点
此方案有利于将来的扩容，不需要做数据迁移。即时再增加4张表，之前的4张表的范围不需要改变，school_id=13的还是在0表，school_id=23456的还是在2表，新增的4张表他们的范围肯定是 大于 40000之后的范围划分的。
缺点
有热点问题，因为school_id的值会一直递增变大，那这段时间的任务是不是会一直在某一张表中，如school_id=1 ～ 10000万之间，这段时间产生的订单是不是都会集中到此张表中，这个就导致1表过热，压力过大，而其他的表没有什么压力。
分组取模分表
取模分表：扩容不方便
范围分表：有热点问题
通过取模分表方式可以既方便扩容又一定程度上缓解热点问题
看下数据存储流程
先根据范围确定是在那个分组，如school_id=12345,根据范围确定在group_0中，再取模确定组内那张表，如school_id=12345,按4取模确定存储在task_1表中。
这样我们扩容时只需要添加对应的group,同时组内的数据均匀分布在不同的表中，一定程度上缓解热点问题。
应用
在我们的业务场景中，我们通过评估最终选取了取模分组。因为通过school_id分表即使根据范围分组依然无法避免扩容问题。因为school_id保持不变，学校对应的用户(学生id)每年都会新增，通过增加school_id的范围依然无法让老学校的新学生任务数据落到新表中。
确定了分表方式后需要预估分表数，此处需要注意的是由于采用的取模分组数据扩容不方便，所以需要假设期望一年、两年、三年数据不扩容需要分多少张表。通过对生产环境数据统计，我们预估单个学校活跃用户量500人，每个人月任务量40个，mysql单表数据容量2000万。这样计算出单个学校每年任务数=5004012=240000。单个mysql表可以支撑的学校数如下：
| 支撑年份 | 单表支撑学校数 |
|---|---|
| 1 | 83 |
| 2 | 48 |
| 3 | 23 |
所以我们计算出预估分表数：
| 活跃学校数 | 支撑年份 | 分表数 |
|---|---|---|
| 500 | 1 | 6 |
| 2 | 12 | |
| 3 | 18 | |
| 1000 | 1 | 12 |
| 2 | 24 | |
| 3 | 36 | |
| 1500 | 1 | 18 |
| 2 | 36 | |
| 3 | 54 | |
| 2000 | 1 | 24 |
| 2 | 48 | |
| 3 | 72 |