Java各类技能知识点学习链接大全：十四、开放型项目问题

（每一次web请求都要建立一次数据库连接。建立连接是一个费时的活动，每次都得花费0.05s～1s的时间，而且系统还要分配内存资源。这个时间对于一次或几次数据库操作，或许感觉不出系统有多大的开销。可是对于现在的web应用，尤其是大型电子商务网站，同时有几百人甚至几千人在线是很正常的事。在这种情况下，频繁的进行数据库连接操作势必占用很多的系统资源，网站的响应速度必定下降）；

数据库连接池原理之(一)：通俗易懂的数据库连接池原理以及实现机制讲解_奋斗的IT青年-CSDN博客_数据库连接池原理

9、怎么提升系统的QPS和吞吐量

掘金

10、微服务和API网关限流熔断实现关键逻辑思路

今日头条

11、分布式ID方案对比：

（1）System.currentTimeMillis()计算方式

该方法的作用是返回当前的计算机时间，时间的表达格式为当前计算机时间和GMT时间(格林威治时间)1970年1月1号0时0分0秒所差的毫秒数。
在开发过程中，通常很多人都习惯使用new Date()来获取当前时间。new Date()所做的事情其实就是调用了System.currentTimeMillis()。如果仅仅是需要或者毫秒数，那么完全可以使用System.currentTimeMillis()去代替new Date()，效率上会高一点。如果需要在同一个方法里面多次使用new Date()，通常性能就是这样一点一点地消耗掉，这里其实可以声明一个引用。

（2）如果需求是只保证唯一性，那么UUID也是可以使用的，但是按照上面的分布式id的要求， UUID其实是不能做成分布式id的，原因如下：

首先分布式id一般都会作为主键，但是安装mysql官方推荐主键要尽量越短越好，UUID每一个都很长，所以不是很推荐
既然分布式id是主键，然后主键是包含索引的，然后mysql的索引是通过b+树来实现的，每一次新的UUID数据的插入，为了查询的优化，都会对索引底层的b+树进行修改，因为UUID数据是无序的，所以每一次UUID数据的插入都会对主键地城的b+树进行很大的修改，这一点很不好
信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。

（3）雪花算法：

snowflake是twitter开源的分布式ID生成算法，是一种算法，所以它和上面的三种生成分布式ID机制不太一样，它不依赖数据库。

核心思想是：分布式ID固定是一个long型的数字，一个long型占8个字节，也就是64个bit，原始snowflake算法中对于bit的分配如下图：

第一个bit位是标识部分，在java中由于long的最高位是符号位，正数是0，负数是1，一般生成的ID为正数，所以固定为0。
时间戳部分占41bit，这个是毫秒级的时间，一般实现上不会存储当前的时间戳，而是时间戳的差值（当前时间-固定的开始时间），这样可以使产生的ID从更小值开始；41位的时间戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
工作机器id占10bit，这里比较灵活，比如，可以使用前5位作为数据中心机房标识，后5位作为单机房机器标识，可以部署1024个节点。
序列号部分占12bit，支持同一毫秒内同一个节点可以生成4096个ID

根据这个算法的逻辑，只需要将这个算法用Java语言实现出来，封装为一个工具方法，那么各个业务应用可以直接使用该工具方法来获取分布式ID，只需保证每个业务应用有自己的工作机器id即可，而不需要单独去搭建一个获取分布式ID的应用。
snowflake算法实现起来并不难，提供一个github上用java实现的：GitHub - beyondfengyu/SnowFlake: Twitter的雪花算法SnowFlake，使用Java语言实现。
在大厂里，其实并没有直接使用snowflake，而是进行了改造，因为snowflake算法中最难实践的就是工作机器id，原始的snowflake算法需要人工去为每台机器去指定一个机器id，并配置在某个地方从而让snowflake从此处获取机器id。
但是在大厂里，机器是很多的，人力成本太大且容易出错，所以大厂对snowflake进行了改造。

雪花算法缺陷：时钟回拨问题；

定时同步时间：CentOS同步时间_青云ing的博客-CSDN博客

雪花算法解决时钟回拨问题_zhifeng687的博客-CSDN博客

（4）百度（uid-generator）

地址：https://github.com/baidu/uid-generator

uid-generator使用的就是snowflake，只是在生产机器id，也叫做workId时有所不同。
uid-generator中的workId是由uid-generator自动生成的，并且考虑到了应用部署在docker上的情况，在uid-generator中用户可以自己去定义workId的生成策略，默认提供的策略是：应用启动时由数据库分配。说的简单一点就是：应用在启动时会往数据库表(uid-generator需要新增一个WORKER_NODE表)中去插入一条数据，数据插入成功后返回的该数据对应的自增唯一id就是该机器的workId，而数据由host，port组成。
对于uid-generator中的workId，占用了22个bit位，时间占用了28个bit位，序列化占用了13个bit位，需要注意的是，和原始的snowflake不太一样，时间的单位是秒，而不是毫秒，workId也不一样，同一个应用每重启一次就会消费一个workId。

使用springboot集成uid：Spring Boot工程集成全局唯一ID生成器 UidGenerator - 简书

开源分布式ID生成器UidGenerator的技术实现_产业互联网资讯的博客-CSDN博客

（5）redis方式：

这里额外再介绍一下使用Redis来生成分布式ID，其实和利用Mysql自增ID类似，可以利用Redis中的incr命令来实现原子性的自增与返回

127.0.0.1:6379> set seq_id 1     // 初始化自增ID为1
OK
127.0.0.1:6379> incr seq_id      // 增加1，并返回
(integer) 2
127.0.0.1:6379> incr seq_id      // 增加1，并返回
(integer) 3

使用redis的效率是非常高的，但是要考虑持久化的问题。Redis支持RDB和AOF两种持久化的方式。

RDB持久化相当于定时打一个快照进行持久化，如果打完快照后，连续自增了几次，还没来得及做下一次快照持久化，这个时候Redis挂掉了，重启Redis后会出现ID重复。

AOF持久化相当于对每条写命令进行持久化，如果Redis挂掉了，不会出现ID重复的现象，但是会由于incr命令过得，导致重启恢复数据时间过长。

上述几种方案对比，参考帖：掘金

（6）springboot集成UidGenerator：

Spring Boot工程集成全局唯一ID生成器 UidGenerator - 简书

（7）UidGenerator原理：

架构系列---百度分布式唯一ID生成器UidGenerator解析_FeelTouch-CSDN博客

（8）Leaf——美团点评分布式ID生成系统（美团技术博客）

Leaf——美团点评分布式ID生成系统 - 美团技术团队

终极分布式id方案：彻底解决雪花算法时间回拨问题新方案_算法_柿子_InfoQ写作社区

12、凉了呀，面试官叫我设计一个排行榜。