对雪花算法的初识到热恋

👨‍💻 博客主页：作者主页
👍 觉得文章不错的朋友可以点点赞和关注
🎁 粉丝福利：学习资料、简历模板统统都有点击领取

分库分表常见主键id生产策略讲解

引入什么技术都是会存在一定的风险，分库分表也不会是例外。在不同的数据节点生成一个唯一主键是一个难题，一张逻辑表x_order会被拆分成多个真实表x_order_n，然后这些表又被分散到不同的库中db_0、db1、db2各个表自增键由于没有办法相互的感应会产生重复的主键，这就没有办法满足分库分表对主键的全局唯一的要求了。

尽管可以使用分片表的自增主键初始值和步长来解决，但是这样会导致运维成本提高，可扩展性差，这种方式不太可取。

业界常用ID解决方案

「UUID： 性能非常高，没有网络消耗。缺点就是无序的字符串，不具备有趋势自增的特性，UUID太长也不便于存储，浪费存储空间，所以很多的场景是不使用的

「Redsi发号器：」 利用Redis的INCR和INCRBY来实现，原子操作，线程安全，性能比Mysql强劲。缺点就是需要占用网络资源，增加系统复杂度。

「Snowflake雪花算法：」 它是twitter开源式的分布式ID生成算法，代码实现简单，而且不占用宽带，数据的迁移不会受到影响，生成的id里包含有时间戳，所以生成的id按照时间进行递增，部署多台服务器的话，需要保证系统时间是一样的。缺点就是依赖系统时钟。

UUID

进入UUID的主键生成实现类，发现它只有一个规则，那就是UUID.randomUUID()，可以看出是多么的牛啊。UUID虽然可以做到全局的唯一性，但还是不推荐作为主键，因为我们知道，在实际业务中主键一般为整型，而UUID是生成32位的字符串。它对MYSQL的性能消耗会比较大，而且MYSQL也建议主键要尽量的短，UUID主键的无序性还会导致数据位置的频繁变动，严重的影响了性能。

public final class UUIDShardingKeyGenerator implements ShardingKeyGenerator {
    private Properties properties = new Properties();

    public UUIDShardingKeyGenerator() {
    }

    public String getType() {
        return "UUID";
    }

    public synchronized Comparable<?> generateKey() {