mysql单表在数据量超过千万的时候，性能就会受到极大的影响。尤其是对于不命中索引的请求，破坏性是难以想象的。当单表的数据量达到一定程度的时候，我们就需要进行分表或者表分区了。分表面临的第一个问题就是主键ID生成的问题，因为涉及到多表，所以原本单表的自增ID生成已经不可用了。那么我们就需要生成全局的ID，有两种方法供我们选择，两者也各有优缺点。
1.使用外部依赖生成全局ID#####
最常见的算法就是利用外部的存储，例如Redis、Mysql或者Zookeeper来实现。上述三者比较推崇的是用Redis来实现，因为Redis是单线程架构，同时天生是为高并发而生，而且实现起来是比较简单的。对于Mysql的话有点重，大家都懂，性能实在不如Redis。对于Zookeeper的话，场景不是很适用，你可以创建顺序的临时节点来生成ID，但是这确实不是Zookeeper擅长的，就像拿着铁锹切白菜。同时Zookeeper对于高并发场景实在是不行。例如，某东双十一的服务爆炸事件....。但是上面这些实现多少都有些臃肿。因为你需要去依赖一个第三方的东西，而仅仅是为了生成一个ID。第三方系统的可用性，也直接决定了你系统的可用性。这种依赖确实是有些重。所以我们需要更轻量级的ID生成方案。
2.利用算法生成ID#####
相比上面依赖第三方生成ID，那么利用算法生成简直是轻量，性能也是远远高于上面的方法。但是有几个关键的点：
1.对于数据库来说，对于随机ID的插入会导致索引页频繁分裂，这样会使插入操作变慢，索引页碎片越来越严重。所以成算法需要能保证生产ID有序。
2.现在的后台都是服务化的，那么这样生成算法要保证，无论在哪个节点都要保证生成的ID都是全局唯一的。
3.生成的ID需要有比较强的随机性，这样在分表的时候可以尽可能的均匀分布。
这样看来，这样的生成算法确实是比较困难的，下面我们就实现一个这样的ID生成算法。
首先，我们需要确定一个随机因素，这应该是一个随机递增的因子，那么时间戳无疑十分合适，线上服务器往往都有全局统一的时间。我们可以用时间戳递增的特点，来保证ID递增。
同时我们需要一个标识来区分不同的机器，这样能在同一毫秒冲突下，解决冲突问题。
但是光有机器的冲突解决还是不够的，在高并发场景下，同一毫秒会有很多的请求，我们需要解决一台机器的高并发问题，我们可以使用一个递增的序列号，来保证一台机器上的ID是有序的。
那么ID就变成了下面的格式：
时间戳|机器ID|冲突递增序列号####
这样就解决了ID生成的问题，但是好像还有一些问题没解决，ID的长度怎么控制，分表的路由规则怎么确定？
首先，对于ID长度的确定，上面的ID规则里，机器ID和冲突递增号基本是不会更改的，我们可以决定一个Seed，来生成前缀时间戳，可以用当前时间戳减去Seed，这样可以通过控制Seed的长度来控制前缀时间戳的长度，进而控制ID的长度。
对于分表的路由规则，如果我们利用ID取模来实现路由，其实是不能保证均匀的，因为后面机器ID和冲突的序列号对路由取模是有很大影响的，所以我们可以利用位移运算来取前缀的时间戳，因为前缀时间戳是全局顺序的，那么做分区路由的时候也会是尽可能均匀的。
其实ID的生成算法是比较简单的，但是使用过程中还是有很多问题的，比如ID长度，看上去没什么大碍。但是对于一些对接其他系统的场景，ID可能会让你痛不欲生，而洗数据也是体力活儿。如果ID过长极容易产生前端显示问题，毕竟js的long是15位的。所以实际运用中ID长度也要严格把控。
网友评论