Node.js工程师养成计划完整无密内置文档资料 node.js

download：Node.js工程师养成计划完整无密内置文档资料
分库分表订单全局ID
概述
分库分表后触及到的另一个问题就是主键如何保证独一且自增。以前单库单表的时分只需求应用数据库特性停止自增即可，如今由于是各自独立的库表，数据库之间的主键自增无法停止交互，比方数据库1的订单明细表主键自增到了1001，数据库2的订单明细表主键如今是1000，假如如今往数据库2的订单明细表中插入一条数据，这个时分获取到的主键ID会是1001，这样就会形成业务上的主键抵触。
全局ID
为理解决订单明细表主键的反复问题。靠数据库的主键自增是无法做到了。如何处理这个问题呢？能够给项目中引入一个全局独一的ID效劳，这个效劳就是用来生成全局独一ID的，每次生成的ID都不一样，能够保证主键的独一性。
全局ID算法
全局ID需求保证如下的特性：
全局独一：必需保证ID是全局性独一的，根本请求
高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈
高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性
好接入：要秉着拿来即用的设计准绳，在系统设计和完成上要尽可能的简单
趋向递增：最好趋向递增，这个请求就得看详细业务场景了，普通不严厉请求
常用的全局ID算法如下：
雪花算法Snowflake
百度uid-generator
美团Leaf
滴滴Tinyid
雪花算法
主要分为 4 个局部：
是 1 个 bit：0，这个是无意义的。
是 41 个 bit：表示的是时间戳。
是 10 个 bit：表示的是机房 id，0000000000，由于我传进去的就是0。
是 12 个 bit：表示的序号，就是某个机房某台机器上这一毫秒内同时生成的 id 的序号，0000 0000 0000。
1 bit，是无意义的：
由于二进制里第一个 bit 为假如是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。
41 bit：表示的是时间戳，单位是毫秒。
41 bit 能够表示的数字多达 2^41 - 1，也就是能够标识 2 ^ 41 - 1 个毫秒值，换算成>年就是表示 69 年的时间。
10 bit：记载工作机器 id，代表的是这个效劳最多能够部署在 2^10 台机器上，也就是 1024 台机器。
但是 10 bit 里 5 个 bit 代表机房 id，5 个 bit 代表机器 id。意义就是最多代表 2 ^ 5 个机房（32 个机房），每个机房里能够代表 2 ^ 5 个机器（32 台机器），这里能够随意拆分，比方拿出4位标识业务号，其他6位作为机器号。能够随意组合。
12 bit：这个是用来记载同一个毫秒内产生的不同 id。
12 bit 能够代表的最大正整数是 2 ^ 12 - 1 = 4096，也就是说能够用这个 12 bit 代表的数字来辨别同一个毫秒内的 4096 个不同的 id。也就是同一毫秒内同一台机器所生成的最大ID数量为4096
简单来说，你的某个效劳假定要生成一个全局独一 id，那么就能够发送一个恳求给部署了 SnowFlake 算法的系统，由这个 SnowFlake 算法系统来生成独一 id。这个 SnowFlake 算法系统首先肯定是晓得本人所在的机器号，（这里权且讲10bit全部作为工作机器ID）接着 SnowFlake 算法系统接纳到这个恳求之后，首先就会用二进制位运算的方式生成一个 64 bit 的 long 型 id，64 个 bit 中的第一个 bit 是无意义的。接着用当前时间戳（单位到毫秒）占用41 个 bit，然后接着 10 个 bit 设置机器 id。最后再判别一下，当前这台机房的这台机器上这一毫秒内，这是第几个恳求，给这次生成 id 的恳求累加一个序号，作为最后的 12 个 bit。
/**

雪花算法解析构造 snowflake的构造如下(每局部用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未运用，接下来的41位为毫秒级时间(41位的长度能够运用69年)，然后是5位datacenterId和5位workerId(10
位的长度最多支持部署1024个节点），最后12位是毫秒内的计数（12位的计数次第号支持每个节点每毫秒产生4096个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串长度为18)
*/

public class IdWorkerUtils {

private static final Logger LOGGER = LoggerFactory.getLogger(IdWorkerUtils.class); /** * 工作机器ID(0~31) */ private long workerId; /** * 数据中心ID(0~31) */ private long datacenterId; /** * 毫秒内序列(0~4095) */ private long sequence; /** * 开端时间截 (2015-01-01) */ private long twepoch = 1288834974657L; /** * 机器id所占的位数 */ private long workerIdBits = 5L; /** * 数据标识id所占的位数 */ private long datacenterIdBits = 5L; /** * 这个是二进制运算，就是 5 bit最多只能有31个数字，也就是说机器id最多只能是32以内 */ private long maxWorkerId = -1L ^ (-1L << workerIdBits); /** * 这个是二进制运算，就是 5 bit最多只能有31个数字，机房id最多只能是32以内 */ private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); /** * 序列在id中占的位数 */ private long sequenceBits = 12L; /** * 机器ID向左移12位 */ private long workerIdShift = sequenceBits; /** * 数据标识id向左移17位(12+5) */ private long datacenterIdShift = sequenceBits + workerIdBits; /** * 时间截向左移22位(5+5+12) */ private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; /** * 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095) */ private long sequenceMask = -1L ^ (-1L << sequenceBits); /** * 上次生成ID的时间截 */ private long lastTimestamp = -1L; public IdWorkerUtils(long workerId, long datacenterId, long sequence) { // sanity check for workerId // 这儿不就检查了一下，请求就是你传送进来的机房id和机器id不能超越32，不能小于0 if (workerId > maxWorkerId || workerId < 0) { throw new IllegalArgumentException( String.format("worker Id can't be greater than %d or less than 0", maxWorkerId)); } if (datacenterId > maxDatacenterId || datacenterId < 0) { throw new IllegalArgumentException( String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId)); }LOGGER.info( "worker starting. timestamp left shift {}, datacenter id bits {}, worker id bits {}, sequence bits {}, workerid {}", timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId); this.workerId = workerId; this.datacenterId = datacenterId; this.sequence = sequence; }public long getWorkerId() { return workerId; }public long getDatacenterId() { return datacenterId; }public long getTimestamp() { return System.currentTimeMillis(); }public synchronized long nextId() { // 这儿就是获取当前时间戳，单位是毫秒 long timestamp = timeGen(); if (timestamp < lastTimestamp) { LOGGER.error("clock is moving backwards.Rejecting requests until {}.", lastTimestamp); throw new RuntimeException(String.format( "Clock moved backwards.Refusing to generate id for %d milliseconds", lastTimestamp - timestamp)); }if (lastTimestamp == timestamp) { // 这个意义是说一个毫秒内最多只能有4096个数字 // 无论你传送几进来，这个位运算保证一直就是在4096这个范围内，防止你本人传送个sequence超越了4096这个范围 sequence = (sequence + 1) & sequenceMask; if (sequence == 0) { timestamp = tilNextMillis(lastTimestamp); } } else { sequence = 0; }// 这儿记载一下最近一次生成id的时间戳，单位是毫秒 lastTimestamp = timestamp; // 这儿就是将时间戳左移，放到 41 bit那儿； // 将机房 id左移放到 5 bit那儿； // 将机器id左移放到5 bit那儿；将序号放最后12 bit； // 最后拼接起来成一个 64 bit的二进制数字，转换成 10 进制就是个 long 型 return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence; }private long tilNextMillis(long lastTimestamp) { long timestamp = timeGen(); while (timestamp <= lastTimestamp) { timestamp = timeGen(); } return timestamp; }private long timeGen() { return System.currentTimeMillis(); }// ---------------测试--------------- /*public static void main(String[] args) { IdWorkerUtils worker = new IdWorkerUtils(1, 1, 1); for (int i = 0; i < 30; i++) { System.out.println(worker.nextId()); } }*/

}
复制代码
时钟回拨
【Node.js工程师养成计划完整无密内置文档资料】由于雪花算法中包含时间戳，因而依赖系统的时间，假如系统的时间由于某一些缘由回到了过去的某个时间，比方如今的系统时间是2022年8月7日09时01分10秒，但是下次获获取到的时间是2022年8月7日09时00分10秒，那么就可能招致生成的全局ID与过去的某一个ID反复，这就是时钟回拨问题。
为理解决时钟回拨问题能够把之前的系统获取到哦啊的时间戳缓存起来，每次获取时间戳和上次的停止比拟，假如本次获取的时间小于上一次的时间，就证明时钟回拨了，就能够取上次时间戳+1来处理。
总结
其实关于散布式ID的生成战略。无论是我们上述提到的哪一种。无非需求具有以下两种特性。自增的、不反复的，而关于不反复且是自增的，那么很容易想到的是时间，而雪花算法就是基于时间戳。但是毫秒级的并发下假如直接拿来用，显然是不合理的。那么就要在这个时间戳上面做一些文章。至于怎样能让这个东西坚持独一且自增。就要翻开本人的脑洞了。能够看到雪花算法中是基于 synchronized 锁停止完成的。