前言
作为一个全球人数最多的国家，一个再怎么凄惨的行业，都能找出很多的人为之付出。而在这个互联网的时代，IT公司绝对比牛毛还多很多。但是大多数都是创业公司，长期存活的真的不多。大多数的IT项目在注册量从0-100万，日活跃1-5万，说实话就这种系统随便找一个有几年工作经验的高级工程师，然后带几个年轻工程师，随便干干都可以做出来。
因为这样的系统，实际上主要就是在前期快速的进行业务功能的开发，搞一个单块系统部署在一台服务器上，然后连接一个数据库就可以了。接着大家就是不停的在一个工程里填充进去各种业务代码，尽快把公司的业务支撑起来。
但是如果真的发展的还可以，可能就会遇到如下问题：
在运行的过程中系统访问数据库的性能越来越差，单表数据量越来越大，一些复杂查询 SQL直接拖垮！
这种时候就不得不考虑的解决方案：缓存，负载均衡，项目分块（微服务）；数据库：读写分离，分库分表等技术
如果说此时你还是一台数据库服务器在支撑每秒上万的请求，负责任的告诉你，每次高峰期会出现下述问题：
- 数据库服务器的磁盘 IO、网络带宽、CPU 负载、内存消耗，都会达到非常高的情况，数据库所在服务器的整体负载会非常重，甚至都快不堪重负了。
- 高峰期时，本来你单表数据量就很大，SQL 性能就不太好，这时加上你的数据库服务器负载太高导致性能下降，就会发现你的 SQL 性能更差了。
- 最明显的一个感觉，就是你的系统在高峰期各个功能都运行的很慢，用户体验很差，点一个按钮可能要几十秒才出来结果。
- 如果你运气不太好，数据库服务器的配置不是特别的高的话，弄不好你还会经历数据库宕机的情况，因为负载太高对数据库压力太大了。
那么百万并发的数据库架构如何设计呢？多数都是分库分表加主从吧？
分库分表：说白了就是大量分表来保证海量数据下的查询性能。
其实大多数公司的瓶颈都在数据库，其实如果把上面的解决方案，都实现了，基本上就没的什么问题了，举例：
如果订单一年有 1 亿条数据，可以把订单表一共拆分为 1024 张表，分散在5个库中，这样 1 亿数据量的话，分散到每个表里也就才 10 万量级的数据量，然后这上千张表分散在 5 台数据库里就可以了。
在写入数据的时候，需要做两次路由，先对订单 id hash 后对数据库的数量取模，可以路由到一台数据库上，然后再对那台数据库上的表数量取模，就可以路由到数据库上的一个表里了。
通过这个步骤，就可以让每个表里的数据量非常小，每年 1 亿数据增长，但是到每个表里才 10 万条数据增长，这个系统运行 10 年，每个表里可能才百万级的数据量。
主从：读写分离
这个时候整体效果已经挺不错了，大量分表的策略保证可能未来 10 年，每个表的数据量都不会太大，这可以保证单表内的 SQL 执行效率和性能。
然后多台数据库的拆分方式，可以保证每台数据库服务器承载一部分的读写请求，降低每台服务器的负载。
但是此时还有一个问题，假如说每台数据库服务器承载每秒 2000 的请求，然后其中 400 请求是写入，1600 请求是查询。
也就是说，增删改的 SQL 才占到了 20% 的比例，80% 的请求是查询。此时假如说随着用户量越来越大，又变成每台服务器承载 4000 请求了。
那么其中 800 请求是写入，3200 请求是查询，如果说你按照目前的情况来扩容，就需要增加一台数据库服务器。
但是此时可能就会涉及到表的迁移，因为需要迁移一部分表到新的数据库服务器上去，是不是很麻烦？
其实完全没必要，数据库一般都支持读写分离，也就是做主从架构。
写入的时候写入主数据库服务器，查询的时候读取从数据库服务器，就可以让一个表的读写请求分开落地到不同的数据库上去执行。
这样的话，假如写入主库的请求是每秒 400，查询从库的请求是每秒 1600。
架构大致如下：
写入主库的时候，会自动同步数据到从库上去，保证主库和从库数据一致。
然后查询的时候都是走从库去查询的，这就通过数据库的主从架构实现了读写分离的效果了。
现在的好处就是，假如说现在主库写请求增加到 800，这个无所谓，不需要扩容。然后从库的读请求增加到了 3200，需要扩容了。
这时，你直接给主库再挂载一个新的从库就可以了，两个从库，每个从库支撑 1600 的读请求，不需要因为读请求增长来扩容主库。
实际上线上生产你会发现，读请求的增长速度远远高于写请求，所以读写分离之后，大部分时候就是扩容从库支撑更高的读请求就可以了。
而且另外一点，对同一个表，如果你既写入数据（涉及加锁），还从该表查询数据，可能会牵扯到锁冲突等问题，无论是写性能还是读性能，都会有影响。
所以一旦读写分离之后，对主库的表就仅仅是写入，没任何查询会影响他，对从库的表就仅仅是查询。
全局唯一ID
在分库分表之后你必然要面对的一个问题，就是 id 咋生成？因为要是一个表分成多个表之后，每个表的 id 都是从 1 开始累加自增长，那肯定不对啊。
举个例子，你的订单表拆分为了 1024 张订单表，每个表的 id 都从 1 开始累加，这个肯定有问题了！
你的系统就没办法根据表主键来查询订单了，比如 id = 50 这个订单，在每个表里都有！
所以此时就需要分布式架构下的全局唯一 id 生成的方案了，在分库分表之后，对于插入数据库中的核心 id，不能直接简单使用表自增 id，要全局生成唯一 id，然后插入各个表中，保证每个表内的某个 id，全局唯一。
比如说订单表虽然拆分为了 1024 张表，但是 id = 50 这个订单，只会存在于一个表里。
那么如何实现全局唯一 id 呢？有以下几种方案：
方案一：独立数据库自增 id
这个方案就是说你的系统每次要生成一个 id，都是往一个独立库的一个独立表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。
比如说你有一个 auto_id 库，里面就一个表，叫做 auto_id 表，有一个 id 是自增长的。
那么你每次要获取一个全局唯一 id，直接往这个表里插入一条记录，获取一个全局唯一 id 即可，然后这个全局唯一 id 就可以插入订单的分库分表中。
这个方案的好处就是方便简单，谁都会用。缺点就是单库生成自增 id，要是高并发的话，就会有瓶颈的，因为 auto_id 库要是承载个每秒几万并发，肯定是不现实的了。
方案二：UUID
这个每个人都应该知道吧，就是用 UUID 生成一个全局唯一的 id。
好处就是每个系统本地生成，不要基于数据库来了。不好之处就是，UUID 太长了，作为主键性能太差了，不适合用于主键。
如果你是要随机生成个什么文件名了，编号之类的，你可以用 UUID，但是作为主键是不能用 UUID 的。
方案三：获取系统当前时间
这个方案的意思就是获取当前时间作为全局唯一的 id。但是问题是，并发很高的时候，比如一秒并发几千，会有重复的情况，这个肯定是不合适的。
一般如果用这个方案，是将当前时间跟很多其他的业务字段拼接起来，作为一个 id，如果业务上你觉得可以接受，那么也是可以的。
你可以将别的业务字段值跟当前时间拼接起来，组成一个全局唯一的编号，比如说订单编号：时间戳 + 用户 id + 业务含义编码。
方案四：SnowFlake 算法的思想分析
SnowFlake 算法，是 Twitter 开源的分布式 id 生成算法。其核心思想就是：使用一个 64 bit 的 long 型的数字作为全局唯一 id。这 64 个 bit 中，其中 1 个 bit 是不用的，然后用其中的 41 bit 作为毫秒数，用 10 bit 作为工作机器 id，12 bit 作为序列号。
给大家举个例子吧，比如下面那个 64 bit 的 long 型数字：
- 第一个部分，是 1 个 bit：0，这个是无意义的。
- 第二个部分是 41 个 bit：表示的是时间戳。
- 第三个部分是 5 个 bit：表示的是机房 id，10001。
- 第四个部分是 5 个 bit：表示的是机器 id，1 1001。
- 第五个部分是 12 个 bit：表示的序号，就是某个机房某台机器上这一毫秒内同时生成的 id 的序号，0000 00000000。
①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 台机器）。
④12 bit：这个是用来记录同一个毫秒内产生的不同 id。
12 bit 可以代表的最大正整数是 2 ^ 12 – 1 = 4096，也就是说可以用这个 12 bit 代表的数字来区分同一个毫秒内的 4096 个不同的 id。简单来说，你的某个服务假设要生成一个全局唯一 id，那么就可以发送一个请求给部署了 SnowFlake 算法的系统，由这个 SnowFlake 算法系统来生成唯一 id。
这个 SnowFlake 算法系统首先肯定是知道自己所在的机房和机器的，比如机房 id = 17，机器 id = 12。
接着 SnowFlake 算法系统接收到这个请求之后，首先就会用二进制位运算的方式生成一个 64 bit 的 long 型 id，64 个 bit 中的第一个 bit 是无意义的。
接着 41 个 bit，就可以用当前时间戳（单位到毫秒），然后接着 5 个 bit 设置上这个机房 id，还有 5 个 bit 设置上机器 id。
最后再判断一下，当前这台机房的这台机器上这一毫秒内，这是第几个请求，给这次生成 id 的请求累加一个序号，作为最后的 12 个 bit。
最终一个 64 个 bit 的 id 就出来了，类似于：
下面我们简单看看这个 SnowFlake 算法的一个代码实现，这就是个示例，大家如果理解了这个意思之后，以后可以自己尝试改造这个算法。
总之就是用一个 64 bit 的数字中各个 bit 位来设置不同的标志位，区分每一个 id。
SnowFlake 算法JAVA版（含测试方法）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 |
import java.util.ArrayList; import java.util.HashMap; import java.util.HashSet; import java.util.List; import java.util.Map; import java.util.Set; import java.util.concurrent.CountDownLatch; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import lombok.ToString; /** * Copyright: Copyright (c) 2019 * * @ClassName: IdWorker.java * @Description: <p>SnowFlake 算法，是 Twitter 开源的分布式 id 生成算法。 * 其核心思想就是：使用一个 64 bit 的 long 型的数字作为全局唯一 id。 * 这 64 个 bit 中，其中 1 个 bit 是不用的，然后用其中的 41 bit 作为毫秒数， * 用 10 bit 作为工作机器 id，12 bit 作为序列号 * </p> * @version: v1.0.0 * @author: BianPeng * @date: 2019年4月11日 下午3:13:41 * * Modification History: * Date Author Version Description *---------------------------------------------------------------* * 2019年4月11日 BianPeng v1.0.0 initialize */ @ToString public class SnowflakeIdFactory { static Logger log = LoggerFactory.getLogger(SnowflakeIdFactory.class); private final long twepoch = 1288834974657L; private final long workerIdBits = 5L; private final long datacenterIdBits = 5L; private final long maxWorkerId = -1L ^ (-1L << workerIdBits); private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); private final long sequenceBits = 12L; private final long workerIdShift = sequenceBits; private final long datacenterIdShift = sequenceBits + workerIdBits; private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; private final long sequenceMask = -1L ^ (-1L << sequenceBits); private long workerId; private long datacenterId; private long sequence = 0L; private long lastTimestamp = -1L; public SnowflakeIdFactory(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; } public synchronized long nextId() { long timestamp = timeGen(); if (timestamp < lastTimestamp) { //服务器时钟被调整了,ID生成器停止服务. 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; } lastTimestamp = timestamp; return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence; } protected long tilNextMillis(long lastTimestamp) { long timestamp = timeGen(); while (timestamp <= lastTimestamp) { timestamp = timeGen(); } return timestamp; } protected long timeGen() { return System.currentTimeMillis(); } public static void testProductIdByMoreThread(int dataCenterId, int workerId, int n) throws InterruptedException { List<Thread> tlist = new ArrayList<>(); Set<Long> setAll = new HashSet<>(); CountDownLatch cdLatch = new CountDownLatch(10); long start = System.currentTimeMillis(); int threadNo = dataCenterId; Map<String,SnowflakeIdFactory> idFactories = new HashMap<>(); for(int i=0;i<10;i++){ //用线程名称做map key. idFactories.put("snowflake"+i,new SnowflakeIdFactory(workerId, threadNo++)); } for(int i=0;i<10;i++){ Thread temp =new Thread(new Runnable() { @Override public void run() { Set<Long> setId = new HashSet<>(); SnowflakeIdFactory idWorker = idFactories.get(Thread.currentThread().getName()); for(int j=0;j<n;j++){ setId.add(idWorker.nextId()); } synchronized (setAll){ setAll.addAll(setId); log.info("{}生产了{}个id,并成功加入到setAll中.",Thread.currentThread().getName(),n); } cdLatch.countDown(); } },"snowflake"+i); tlist.add(temp); } for(int j=0;j<10;j++){ tlist.get(j).start(); } cdLatch.await(); long end1 = System.currentTimeMillis() - start; log.info("共耗时:{}毫秒,预期应该生产{}个id, 实际合并总计生成ID个数:{}",end1,10*n,setAll.size()); } public static void testProductId(int dataCenterId, int workerId, int n){ SnowflakeIdFactory idWorker = new SnowflakeIdFactory(workerId, dataCenterId); SnowflakeIdFactory idWorker2 = new SnowflakeIdFactory(workerId+1, dataCenterId); Set<Long> setOne = new HashSet<>(); Set<Long> setTow = new HashSet<>(); long start = System.currentTimeMillis(); for (int i = 0; i < n; i++) { setOne.add(idWorker.nextId());//加入set } long end1 = System.currentTimeMillis() - start; log.info("第一批ID预计生成{}个,实际生成{}个<<<<*>>>>共耗时:{}",n,setOne.size(),end1); for (int i = 0; i < n; i++) { setTow.add(idWorker2.nextId());//加入set } long end2 = System.currentTimeMillis() - start; log.info("第二批ID预计生成{}个,实际生成{}个<<<<*>>>>共耗时:{}",n,setTow.size(),end2); setOne.addAll(setTow); log.info("合并总计生成ID个数:{}",setOne.size()); } public static void testPerSecondProductIdNums(){ SnowflakeIdFactory idWorker = new SnowflakeIdFactory(1, 2); long start = System.currentTimeMillis(); int count = 0; for (int i = 0; System.currentTimeMillis()-start<1000; i++,count=i) { /** 测试方法一: 此用法纯粹的生产ID,每秒生产ID个数为400w+ */ //idWorker.nextId(); /** 测试方法二: 在log中打印,同时获取ID,此用法生产ID的能力受限于log.error()的吞吐能力. * 每秒徘徊在10万左右. */ log.info(""+idWorker.nextId()); } long end = System.currentTimeMillis()-start; System.out.println(end); System.out.println(count); } public static void main(String[] args) { /** case1: 测试每秒生产id个数? * 结论: 每秒生产id个数400w+ */ //testPerSecondProductIdNums(); /** case2: 单线程-测试多个生产者同时生产N个id,验证id是否有重复? * 结论: 验证通过,没有重复. */ //testProductId(1,2,10000);//验证通过! //testProductId(1,2,20000);//验证通过! /** case3: 多线程-测试多个生产者同时生产N个id, 全部id在全局范围内是否会重复? * 结论: 验证通过,没有重复. */ try { testProductIdByMoreThread(1,2,100000);//单机测试此场景,性能损失至少折半! } catch (InterruptedException e) { e.printStackTrace(); } } } |
这个算法也叫雪花算法我使用的类源码：https://gitee.com/flying-cattle/earn_knife/blob/master/item-common/src/main/java/com/item/util/SnowflakeIdWorker.java
其次在推荐一种算法：国美最近开源的分布式ID：https://tech.meituan.com/2019/03/07/open-source-project-leaf.html
项目是一个递进的过程，优先考虑缓存，其次读写分离，再分表分库。当然这只是个人想法，各位伙伴还是根据自己的项目和业务来综合考虑实行方案。
本文来自边鹏_尛爺鑫 ，本文观点不代表蓝洛水深立场，转载请联系原作者。
微信扫一扫 
支付宝扫一扫 
