谈谈雪花算法的使用及源码.docxVIP

谈谈雪花算法的使用及源码 不能消灭反复的ID号，既然是独一标识，这是最基本的要求。 1.2 递增 比较低要求的条件为趋势递增,即保证下一个ID肯定大于上一个ID,而比较苛刻的要求是连续递增,如1,2,3等等。 1.3 高可用高功能 ID生成事关严重,一旦挂掉系统崩溃;高功能是指必需要在压测下表现良好,假如达不到要求则在高并发环境下照旧会导致系统瘫痪。 1.4 信息平安 假如ID是连续的，恶意用户的扒取工作就格外简约做了，直接依据挨次下载指定URL即可；假如是订单号就更危急了，竞对可以直接晓得我们一天的单量。所以在一些应用场景下，会需要ID无规章、不规章。 其次条和第四条有点冲突，需要结合具体的业务场景。 二、常见企业级处理方案(除雪花算法） 2.1 UUID 优点： 能够保证独立性，程序可以在不同的数据库间迁移，效果不受影响。保证生成的ID不只是表独立的，而且是库独立的，这点在你想切分数据库的时候尤为重要。 缺点： 功能为题：UUID太长，通常以36长度的字符串表示,对MySQL索引不利：假如作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严峻影响功能UUID无业务含义：很多需要ID能标识业务含义的地方不使用不满足递增要求信息担忧全：基于MAC地址生成UUID的算法可能会形成MAC地址泄露，这个漏洞曾被用于查找梅丽莎病毒的制造者位置。不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。 2.2 基于数据库方案 利用数据库生成ID是最常见的方案。能够确保ID全数据库独一。其优缺点如下： 优点： 格外简约，利用现有数据库系统的功能实现，成本小，有DBA专业维护。ID号单调自增，可以实现一些对ID有特殊要求的业务。 缺点: 不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。在单个数据库或读写分别或一主多从的情况下，只要一个主库可以生成。有单点毛病的风险。在功能达不到要求的情况下，比较难于扩展。假如涉及多个系统需要合并或者数据迁移会比较麻烦。分表分库的时候会有麻烦。 三、雪花算法 雪花算法原理 3.1 说明 41位为时间戳，12位为在这一刻能够产生2^12个自增的Id这结合了自增Id的优势，同时10位机器ID(dataCenterId 5位和machineId 5位)确保了分布式能够支持1024台节点。Twitter的分布式雪花算法 SnowFlake 每秒自增生成26个万可排序的ID1、twitter的SnowFlake生成ID能够依据时间有序生成2、SnowFlake算法生成id的结果是一个64bit大小的整数3、分布式系统内不会产生反复id（用有datacenterId和machineId来做区分）datacenterId（分布式）（服务ID 1，2，3.....） 每个服务中写死machineId（用于集群） 机器ID 读取机器的环境变量MACHINEID 部署时每台服务器ID不一样。 3.2 缺点： 强依靠时钟,假如主机时间回拨,则会形成反复ID 3.3 Java实现： public class SnowFlake { /** * 开头时间截 (2021-01-01) */ private final long twepoch = 1420041600000L; /** * 机器id所占的位数 */ private final long workerIdBits = 5L; /** * 数据标识id所占的位数 */ private final long dataCenterIdBits = 5L; /** * 支持的最大机器id，结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数) */ private final long maxWorkerId = ~(-1L workerIdBits); /** * 支持的最大数据标识id，结果是31 */ private final long maxDataCenterId = ~(-1L dataCenterIdBits); /** * 序列在id中占的位数 */ private final long sequenceBits = 12L; /** * 机器ID向左移12位 */ private final long workerIdShift = sequenceBits;