文章目录
- 雪花算法
- 雪花算法id结构
- 雪花算法作用
- 雪花算法优缺点
- UUID
- UUID简介
- UUID的优缺点
雪花算法
SnowFlake 算法，是 Twitter 开源的分布式 id 生成算法。其核心思想就是：使用一个 64 bit 的 long 型的数字作为全局唯一 id。在分布式系统中的应用十分广泛，且ID 引入了时间戳，基本上是保持自增的。
现在的服务基本是分布式、微服务形式的，而且大数据量也导致分库分表的产生，对于水平分表就需要保证表中 id 的全局唯一性。对于 MySQL 而言，一个表中的主键 id 一般使用自增的方式，但是如果进行水平分表之后，多个表中会生成重复的 id 值。
雪花算法id结构
雪花算法的原理就是生成一个的 64 位比特位的 long 类型的唯一 id。
最高 1 位固定值 0，因为生成的 id 是正整数，如果是 1 就是负数了。
接下来 41 位存储毫秒级时间戳，2^41/(1000606024365)=69，大概可以使用 69 年。
再接下 10 位存储机器码，包括 5 位 datacenterId 和 5 位 workerId。最多可以部署 2^10=1024 台机器。
最后 12 位存储序列号。同一毫秒时间戳时，通过这个递增的序列号来区分。即对于同一台机器而言，同一毫秒时间戳下，可以生成 2^12=4096 个不重复 id。
雪花算法作用
1、所有生成的id按时间趋势递增
2、整个分布式系统内不会产生重复id（因为有datacenterId和workerId来做区分）
雪花算法优缺点
优点
1、高并发分布式环境下生成不重复 id，每秒可生成百万个不重复 id。
2、基于时间戳，以及同一时间戳下序列号自增，基本保证 id 有序递增。
3、不依赖第三方库或者中间件。
4、算法简单，在内存中进行，效率高
缺点：
1、不一定是全局递增的(存储机器码导致)
2、依赖服务器时间，服务器时钟回拨时可能会生成重复 id。算法中可通过记录最后一个生成 id 时的时间戳来解决，每次生成 id 之前比较当前服务器时钟是否被回拨，避免生成重复 id。
雪花算法每一部分占用的比特位数量并不是固定死的。例如的业务很可能达不到 69 年这么长时间，那么可用减少时间戳占用的位数，雪花算法服务需要部署的节点超过1024 台，那么可以减少的位数补充给机器码用。
雪花算法中 41 位比特位不是直接用来存储当前服务器毫秒时间戳的，而是需要当前服务器时间戳减去某一个初始时间戳值，一般可以使用服务上线时间作为初始时间戳值。
注：
保障分表后的多张表中的 id 是全局唯一性的方法：
1、UUID作为主键：UUID 生成的是一个无序的字符串，对于 MySQL 推荐使用增长的数值类型值作为主键来说不适合。
2、使用 Redis 的自增原子性来生成唯一 id：实现较为复杂，业界使用较少
UUID
UUID总长度 36，由 32 个 16 进制字符和 4 个连字符组成。连字符仅用于增加可读性，实际的精度为一个 16 进制字符为 2^4=4bit，32 个则为 32*4bit=128bit。UUID具有多个版本，每个版本的算法不同，应用范围也不同。
UUID简介
UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF发布的UUID规范 A Universally Unique IDentifier (UUID) URN Namespace。
uuid：
1、基于时间戳&时钟序列生成
2、基于名字空间/名字的散列值（MD5/SHA1）生成
3、基于随机数生成
UUID的优缺点
优点：
1）简单，代码方便。
2）生成ID性能非常好，基本不会有性能问题。
3）全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。
缺点：
1）没有排序，无法保证趋势递增。
2）UUID往往是使用字符串存储，查问的效率比较低。
3）存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
4）传输数据大。
5）不可读。
6）信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
