问题1集群时钟不同步导致的问题
**
名词解释：1集群：多个服务器共同工作，对外提供服务 2时钟：服务器上的时间
问题描述：下单场景中，每当插入一条订单记录，就会有”下单时间“这样的字段， 若订单系统是集群化部署，或者数据库是分库分表的集群化部署，而每个服务器的时钟是不同步的，那么数据将会变得混乱。
解决方案分为以下3种情况：
场景1、分布式集群中的各个服务器节点都可以访问互联网
解决思路：每个服务器同步（国家授权中心的时间/时间服务器）
检查系统是否已经安装了【ntpdate】命令，没有安装可以使用yum安装：
rpm -qa | grep ntpdate #查看系统是否安装ntpdate命令
yum install ntp #安装ntpdate（已经安装可以跳过）
ntpdate -u ntp.api.bz # 使用 ntpdate 网络时间同步命令，从一个时间服务器同步时间。
场景2、分布式集群中某个（或几个但不是全部）服务器节点可以访问互联网
解决思路：选取集群中的一个可以访问互联网的服务器节点A(172.17.0.17)作为时间服务器，让这台服务器和网络时间保持同步， 使用 ntpdate 网络时间同步命令（如下所示）
ntpdate -u ntp.api.bz # 从一个时间服务器同步时间
把服务器节点A配置为时间服务器（修改/etc/ntp.conf文件）
1、如果有 restrict default ignore，注释掉它
2、添加如下内容
restrict 172.17.0.0 mask 255.255.255.0 nomodify notrap # 放开局域网同步功能,172.17.0.0是你的局域网网段
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
3、重启并配置ntpd服务开机启动
service ntpd restart
chkconfig ntpd on
唯一性ID生成方案及SnowFlake算法
需求描述：分布式系统是由多个服务器组成的，如果每个服务根据自己的数据库id进行订单号的生成，就会导致整个系统数据混乱，所以在插入数据库之前，需要有一个不重复的全局唯一的id生成策略。
分布式ID的特点
唯一性：确保生成的ID是分布式系统唯一的。
有序递增性：确保生成的ID是对于某个用户或者业务是按一定的数字有序递增的。这样的ID对数据库友好，例如mysql的索引对于这样的有序数据也好排序处理的快。
高可用性：确保任何时候都能正确的生成ID。
带时间：ID里面包含时间，一眼扫过去就知道哪天的交易。
生成方案优缺点如下：
1.UUID
算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。
优点：本地生成，生成简单，性能好，没有高可用风险
缺点：长度过长，存储冗余，且无序不可读，查询效率低
2 数据库自增ID
使用数据库的ID自增策略，如 MySQL 的 auto_increment。并且可以使用两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。
优点：数据库生成的ID绝对有序，高可用实现方式简单
缺点：需要独立部署数据库实例，成本高，有性能瓶颈
3.批量生成ID
一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中记录当前值及最大值。
优点：避免了每次生成ID都要访问数据库并带来压力，提高性能
缺点：属于本地生成策略，存在单点故障，服务重启造成ID不连续
4.Redis生成ID
Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。
优点：不依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排序的结果很有帮助。
缺点：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度；需要编码和配置的工作量比较大。
考虑到单节点的性能瓶颈，可以使用 Redis 集群来获取更高的吞吐量。假如一个集群中有5台 Redis。可以初始化每台 Redis 的值分别是1, 2, 3, 4, 5，然后步长都是 5。各个 Redis 生成的 ID 为：
A：1, 6, 11, 16, 21
B：2, 7, 12, 17, 22
C：3, 8, 13, 18, 23
D：4, 9, 14, 19, 24
E：5, 10, 15, 20, 25
随便负载到哪个机确定好，未来很难做修改。步长和初始值一定需要事先确定。使用 Redis 集群也可以方式单点故障的问题。
另外，比较适合使用 Redis 来生成每天从0开始的流水号。比如订单号 = 日期 + 当日自增长号。可以每天在 Redis 中生成一个 Key ，使用 INCR 进行累加。
5.Twitter的SnowFlake算法
snowflake算法介绍：
1位符号位：
由于 long 类型在 java 中带符号的，最高位为符号位，正数为 0，负数为 1，且实际系统中所使用的ID一般都是正数，所以最高位为 0。
41位时间戳（毫秒级）：
需要注意的是此处的 41 位时间戳并非存储当前时间的时间戳，而是存储时间戳的差值（当前时间戳 - 起始时间戳），这里的起始时间戳一般是ID生成器开始使用的时间戳，由程序来指定，所以41位毫秒时间戳最多可以使用 (1 << 41) / (1000x60x60x24x365) = 69年。
10位数据机器位：
包括5位数据标识位和5位机器标识位，这10位决定了分布式系统中最多可以部署 1 << 10 = 1024 s个节点。超过这个数量，生成的ID就有可能会冲突。
12位毫秒内的序列：
这 12 位计数支持每个节点每毫秒（同一台机器，同一时刻）最多生成 1 << 12 = 4096个ID
加起来刚好64位，为一个Long型。
优点：高性能，低延迟，按时间有序，一般不会造成ID碰撞
缺点：需要独立的开发和部署，依赖于机器的时钟
实现如下;
/* 10位的数据机器位，可以部署在1024个节点，包括5位datacenterId和5位workerId
- ·12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号
- ·加起来刚好64位，为一个Long型。
- ·SnowFlake的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右。
*/
// 1 41 10 12
public class SnowflakeIdWorker {
// Fields=============
/** 开始时间截 (2015-01-01) */
private final long twepoch = 1420041600000L;
/** 机器id所占的位数 */
private final long workerIdBits = 5L;
/** 数据标识id所占的位数 */
private final long datacenterIdBits = 5L;
/** 支持的最大机器id，结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数) *
*负数在计算机中使用补码表示 补码等于反码+1；
*-1的原码:1000 0001
private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
/** 支持的最大数据标识id，结果是31 */
private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
/** 序列在id中占的位数 */
private final long sequenceBits = 12L;
/** 机器ID向左移12位 */
private final long workerIdShift = sequenceBits;
/** 数据标识id向左移17位(12+5) */
private final long datacenterIdShift = sequenceBits + workerIdBits;
/** 时间截向左移22位(5+5+12) */
private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
/** 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095) */
private final long sequenceMask = -1L ^ (-1L << sequenceBits);
/** 工作机器ID(0~31) */
private long workerId;
/** 数据中心ID(0~31) */
private long datacenterId;
/** 毫秒内序列(0~4095) */
private long sequence = 0L;
/** 上次生成ID的时间截 */
private long lastTimestamp = -1L;
//Constructors=======
/**
// Methods============
/**
/**
/**
//Test===============
/** 测试 */
public static void main(String[] args) {
SnowflakeIdWorker worker = new SnowflakeIdWorker(30, 30);
for (int i = 0; i < 1000; i++) {
System.out.println(worker.nextId());
}
}
}
- ·返回以毫秒为单位的当前时间
- ·@return 当前时间(毫秒)
*/
protected long timeGen() {
return System.currentTimeMillis();
} - ·阻塞到下一个毫秒，直到获得新的时间戳
- ·@param lastTimestamp 上次生成ID的时间截
- ·@return 当前时间戳
*/
protected long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
} - ·获得下一个ID (该方法是线程安全的)
- ·@return SnowflakeId
*/
public synchronized long nextId() {
long timestamp = timeGen();
//如果当前时间小于上一次ID生成的时间戳，说明系统时钟回退过这个时候应当抛出异常
if (timestamp < lastTimestamp) {
throw new RuntimeException(
String.format(“Clock moved backwards. Refusing to generate id for %d milliseconds”, lastTimestamp - timestamp));
}
//如果是同一时间生成的，则进行毫秒内序列
if (lastTimestamp == timestamp) {
sequence = (sequence + 1) & sequenceMask;
//毫秒内序列溢出
if (sequence == 0) {
//阻塞到下一个毫秒,获得新的时间戳
timestamp = tilNextMillis(lastTimestamp);
}
}
//时间戳改变，毫秒内序列重置
else {
sequence = 0L;
}
//上次生成ID的时间截
lastTimestamp = timestamp;
//移位并通过或运算拼到一起组成64位的ID
//或运算 两个位只要有一个为1，那么结果就是1，否则就为0，
return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence;
} - ·构造函数
- ·@param workerId 工作ID (0~31)
- ·@param datacenterId 数据中心ID (0~31)
*/
public SnowflakeIdWorker(long workerId, long datacenterId) {
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));
}
this.workerId = workerId;
this.datacenterId = datacenterId;
} - ·反码:1111 1110
- ·补码:1111 1111
- ·在本案例中-1L用二进制表示
- ·1111111111111111111111111111111111111111111111111111111111111111
- ·移位运算符<< (-1L << workerIdBits)结果为
- ·1111111111111111111111111111111111111111111111111111111111100000
- ·^异或运算符 两个操作数的位中，相同则结果为0，不同则结果为1
- ·-1L ^ (-1L << workerIdBits)为
- ·1111111111111111111111111111111111111111111111111111111111111111
- ·和
- ·1111111111111111111111111111111111111111111111111111111111100000
- ·进行异或运算*00000000000000000000000000000000000000000000000000000000000011111
*十进制结果为31
*/
6.美团Leaf-snowflake方案。
项目介绍：eaf在美团点评公司内部服务包含金融、支付交易、餐饮、外卖、酒店旅游、猫眼电影等众多业务线。目前Leaf的性能在4C8G的机器上QPS能压测到近5w/s，TP999 1ms，已经能够满足大部分的业务的需求。每天提供亿数量级的调用量，作为公司内部公共的基础技术设施，必须保证高SLA和高性能的服务，我们目前还仅仅达到了及格线，还有很多提高的空间。
https://tech.meituan.com/2017/04/21/mt-leaf.html
