先来参考文章:https://mp.weixin.qq.com/s/AHRCYOjnXAgcy2j6vziukQ?tdsourcetag=s_pctim_aiomsg
方案
一般情况下,MySQL分表会有几种方案:
1、初始点不同但是步数相同,比如A表起点是1步数是2,B表起点是2步数是2;
2、使用一个中间服务生成id,不再使用表自增,自己负责自增id;
3、使用UUID做id,就不怕冲突啦;
4、使用雪花算法做id,全数字还相对自增,一秒几百万种可能,就不怕冲突啦。
实际上,如果系统是新开发,推荐你是用雪花算法
,因为uuid不能保证顺序性,而第一增加运维压力,第二个增加开发压力。
问题
问题来咯。
如果是旧系统,旧系统是自增id表,现在要分表怎么办呢?
我们每个方法预演一下:
1、旧表是单表,分表必定要根据业务id取模分到各个子表里面,那么大家的起点就会有问题,设置步长也是会冲突。除非手动将每个子表的maxid重新设置一个新的而且各个表的maxid是有序的,再去设置相同步长。这里涉及到运维成本!
2、新的中间服务,考虑可用性必须是分布式的,考虑线程安全必须做骚操作,开发成本!!!
3、呵呵了,人家int的主键被你这样一改,怕是代码都得重写吧。
4、同上。
所以说:旧系统是自增id表,分表要么运维成本,要么开发成本!
我肯定选择开发成本,因为步长法也有一个很大的缺点,不能保证有序性,A子表的id大,B子表的id小,但是实际上是A子表先插入的。
解决
解决方案:
1、留下一个表,一行参数。
|max_id|
| 100|
2、写一个生成id的服务,每次去表里面那max_id,然后虚拟出100个id在服务内部(后面业务要用的时候分配),再把max_id设置为200。
|max_id|
| 200|
3、为了保证可用性,这个生成id的服务是分布式的,有多个。
4、然后就出现并发问题了,每个服务同时取到了100,同时生成100个相同的id,同时去更新100为200.
5、解决办法,更新的时候做手脚,如果更新条数为0就重新拿id。
6、只要实施类似CAS乐观锁的思路(对比成功才替换的思路),在写回时对max-id的初始条件进行比对,就能避免数据的不一致,写回SQL由:
update T set max_id=200;
升级为:
update T set max_id=200 where max_id=100;
7、但是实际上上述是悲观锁,利用了mysql的排他锁机制,update语句会变成两条语句:
update T set max_id=200 where max_id=100;
变种为:
1、 a = select max_id from T where max_id=100;//无锁
2、 update T set max_id=a.max_id where max_id=100;//排他锁
- 先执行第一句是无锁的,每个服务都拿到相同的a。
- 但是第二句是排它锁,只能有一个请求执行sql,第一个执行之后max_id就变了,那么后续的update语句都会执行条数为0.
8、如果update会自带排他锁,但是不能代表一定能够保证线程安全,需要有技巧的使用才行的,比如:
这里改成name
。
update T set name =200 where max_id=100;
变种为:
1、 a = select name from T where max_id=100;//无锁
2、 update T set name=a.name where max_id=100;//排他锁
大家拿到相同的a,第二条语句的max_id不变,就会所有线程都能成功执行update语句!!!