目录
三次握手过程：
客户端——发送带有SYN标志的数据包——服务端 一次握手 Client进入syn_sent状态
服务端——发送带有SYN/ACK标志的数据包——客户端 二次握手 服务端进入syn_rcvd
客户端——发送带有ACK标志的数据包——服务端 三次握手 连接就进入Established状态
为什么三次：
主要是为了建立可靠的通信信道，保证客户端与服务端同时具备发送、接收数据的能力
为什么两次不行？
1、防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源
2、 两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输， TCP 协议的通信双方， 都必须维 护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方 相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认）
**TCP四次挥手过程 **
四次挥手过程：
客户端——发送带有FIN标志的数据包——服务端，关闭与服务端的连接 ，客户端进入FIN-WAIT-1状态
服务端收到这个 FIN，它发回⼀ 个 ACK，确认序号为收到的序号加1，服务端就进入了CLOSE-WAIT状态
服务端——发送⼀个FIN数据包——客户端，关闭与客户端的连接，客户端就进入FIN-WAIT-2状态
客户端收到这个 FIN，发回 ACK 报⽂确认，并将确认序号设置为收到序号加1，TIME-WAIT状态
为什么四次：
因为需要确保客户端与服务端的数据能够完成传输。
CLOSE-WAIT：
这种状态的含义其实是表示在等待关闭
TIME-WAIT：
为了解决网络的丢包和网络不稳定所带来的其他问题，确保连接方能在时间范围内，关闭自己的连接
如何查看TIME-WAIT状态的链接数量？
netstat -an |grep TIME_WAIT|wc -l 查看连接数等待time_wait状态连接数
为什么会TIME-WAIT过多？解决方法是怎样的？
可能原因： 高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接
解决：负载均衡服务器；Web服务器首先关闭来自负载均衡服务器的连接
1、OSI与TCP/IP 模型
OSI七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
TCP/IP五层：物理层、数据链路层、网络层、传输层、应用层
2、常见网络服务分层
应用层：HTTP、SMTP、DNS、FTP
传输层：TCP 、UDP
网络层：ICMP 、IP、路由器、防火墙
数据链路层：网卡、网桥、交换机
物理层：中继器、集线器
3、TCP与UDP区别及场景
| 类型 |
特点 |
性能 |
应用过场景 |
首部字节 |
|
| TCP |
面向连接、可靠、字节流 |
传输效率慢、所需资源多 |
文件、邮件传输 |
20-60 |
|
| UDP |
无连接、不可靠、数据报文段 |
传输效率快、所需资源少 |
语音、视频、直播 |
8个字节 |
基于TCP的协议：HTTP、FTP、SMTP
基于UDP的协议：RIP、DNS、SNMP
4、TCP滑动窗口，拥塞控制
TCP通过：应用数据分割、对数据包进行编号、校验和、流量控制、拥塞控制、超时重传等措施保证数据的可靠传输；
拥塞控制目的：为了防止过多的数据注入到网络中，避免网络中的路由器、链路过载
拥塞控制过程：TCP维护一个拥塞窗口，该窗口随着网络拥塞程度动态变化，通过慢开始、拥塞避免等算法减少网络拥塞的发生。
5、TCP粘包原因和解决方法
TCP粘包是指：发送方发送的若干包数据到接收方接收时粘成一包
发送方原因：
TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量）：
收集多个小分组，在一个确认到来时一起发送、导致发送方可能会出现粘包问题
接收方原因：
TCP将接收到的数据包保存在接收缓存里，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。
解决粘包问题：
最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪，通过使用某种方案给出边界，例如：
6、TCP、UDP报文格式
TCP报文格式：
源端口号和目的端口号：
用于寻找发端和收端应用进程。这两个值加上ip首部源端ip地址和目的端ip地址唯一确定一个tcp连接。
序号字段：
序号用来标识从T C P发端向T C P收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则 T C P用序号对每个字节进行计数。序号是32 bit的无符号数，序号到达 2^32-1后又从0开始。
当建立一个新的连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个ISN加1，因为SYN标志消耗了一个序号
确认序号：
既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加 1。只有ACK标志为 1时确认序号字段才有效。发送ACK无需任何代价，因为 32 bit的确认序号字段和A C K标志一样，总是T C P首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置， ACK标志也总是被设置为1。TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。
首都长度：
首部长度给出首部中 32 bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4 bit，因此T C P最多有6 0字节的首部。然而，没有任选字段，正常的长度是 2 0字节。
标志字段：在T C P首部中有 6个标志比特。它们中的多个可同时被设置为1.
URG紧急指针（u rgent pointer）有效
ACK确认序号有效。
PSH接收方应该尽快将这个报文段交给应用层。
RST重建连接。
SYN同步序号用来发起一个连接。这个标志和下一个标志将在第 1 8章介绍。
FIN发端完成发送任务。
窗口大小：
T C P的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节。窗口大小是一个 16 bit字段，因而窗口大小最大为 65535字节。
检验和：
检验和覆盖了整个的 T C P报文段：T C P首部和T C P数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。
紧急指针：
只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。 T C P的紧急方式是发送端向另一端发送紧急数据的一种方式。
选项：
最常见的可选字段是最长报文大小，又称为 MSS (Maximum Segment Size)。每个连接方通常都在通信的第一个报文段（为建立连接而设置 S Y N标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。
UDP报文格式：
端口号：
用来表示发送和接受进程。由于 I P层已经把I P数据报分配给T C P或U D P（根据I P首部中协议字段值），因此T C P端口号由T C P来查看，而 U D P端口号由UDP来查看。T C P端口号与UDP端口号是相互独立的。
长度：
UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为 8字节（发送一份0字节的UDP数据报是 O K）。
检验和：
UDP检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。
IP报文格式：普通的IP首部长为20个字节，除非含有可选项字段。
4位版本：
目前协议版本号是4，因此IP有时也称作IPV4.
4位首部长度：
首部长度指的是首部占32bit字的数目，包括任何选项。由于它是一个4比特字段，因此首部长度最长为60个字节。
服务类型（TOS）：
服务类型字段包括一个3bit的优先权字段（现在已经被忽略），4bit的TOS子字段和1bit未用位必须置0。4bit的TOS分别代表：最小时延，最大吞吐量，最高可靠性和最小费用。4bit中只能置其中1比特。如果所有4bit均为0，那么就意味着是一般服务。
总长度：
总长度字段是指整个IP数据报的长度，以字节为单位。利用首部长度和总长度字段，就可以知道IP数据报中数据内容的起始位置和长度。由于该字段长16bit，所以IP数据报最长可达65535字节。当数据报被分片时，该字段的值也随着变化。
标识字段：
标识字段唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。
生存时间：
TTL（time-to-live）生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置（通常为 3 2或6 4），一旦经过一个处理它的路由器，它的值就减去 1。当该字段的值为 0时，数据报就被丢弃，并发送 ICMP 报文通知源主机。
首部检验和：
首部检验和字段是根据 I P首部计算的检验和码。它不对首部后面的数据进行计算。 ICMP、IGMP、UDP和TCP在它们各自的首部中均含有同时覆盖首部和数据检验和码。
以太网报文格式：
目的地址和源地址：
是指网卡的硬件地址（也叫MAC 地址），长度是48 位，是在网卡出厂时固化的。
数据：
以太网帧中的数据长度规定最小46 字节，最大1500 字节，ARP 和RARP 数据包的长度不够46 字节，要在后面补填充位。最大值1500 称为以太网的最大传输单元（MTU），不同的网络类型有不同的MTU，如果一个数据包从以太网路由到拨号链路上，数据包度大于拨号链路的MTU了，则需要对数据包进行分片fragmentation）。ifconfig 命令的输出中也有“MTU:1500”。注意，MTU 个概念指数据帧中有效载荷的最大长度，不包括帧首部的长度。
1、HTTP协议1.0_1.1_2.0
HTTP1.0：服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）
HTTP1.1：KeepAlived长连接避免了连接建立和释放的开销；通过Content-Length来判断当前请求数据是否已经全部接受（有状态）
HTTP2.0：引入二进制数据帧和流的概念，其中帧对数据进行顺序标识；因为有了序列，服务器可以并行的传输数据。
http1.0和http1.1的主要区别如下：
1、缓存处理：1.1添加更多的缓存控制策略（如：Entity tag，If-Match）
2、网络连接的优化：1.1支持断点续传
3、错误状态码的增多：1.1新增了24个错误状态响应码，丰富的错误码更加明确各个状态
4、Host头处理：支持Host头域，不在以IP为请求方标志
5、长连接：减少了建立和关闭连接的消耗和延迟。
http1.1和http2.0的主要区别：
1、新的传输格式：2.0使用二进制格式，1.0依然使用基于文本格式
2、多路复用：连接共享，不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）
3、header压缩：由于1.X中header带有大量的信息，并且得重复传输，2.0使用encoder来减少需要传输的hearder大小
4、服务端推送：同google的SPDUY（1.0的一种升级）一样
2、HTTP与HTTPS之间的区别
HTTP与HTTPS之间的区别：
| HTTP |
HTTPS |
| 默认端口80 |
HTTPS默认使用端口443 |
| 明文传输、数据未加密、安全性差 |
传输过程ssl加密、安全性较好 |
| 响应速度快、消耗资源少 |
响应速度较慢、消耗资源多、需要用到CA证书 |
HTTPS链接建立的过程：
1.首先客户端先给服务器发送一个请求
2.服务器发送一个SSL证书给客户端，内容包括：证书的发布机构、有效期、所有者、签名以及公钥
3.客户端对发来的公钥进行真伪校验，校验为真则使用公钥对对称加密算法以及对称密钥进行加密
4.服务器端使用私钥进行解密并使用对称密钥加密确认信息发送给客户端
5.随后客户端和服务端就使用对称密钥进行信息传输
对称加密算法：
双方持有相同的密钥，且加密速度快，典型对称加密算法：DES、AES
非对称加密算法：
密钥成对出现（私钥、公钥），私钥只有自己知道，不在网络中传输；而公钥可以公开。相比对称加密速度较慢，典型的非对称加密算法有：RSA、DSA
3、Get和Post请求区别
HTTP请求：
| 方法 |
描述 |
| GET |
向特定资源发送请求，查询数据，并返回实体 |
| POST |
向指定资源提交数据进行处理请求，可能会导致新的资源建立、已有资源修改 |
| PUT |
向服务器上传新的内容 |
| HEAD |
类似GET请求，返回的响应中没有具体的内容，用于获取报头 |
| DELETE |
请求服务器删除指定标识的资源 |
| OPTIONS |
可以用来向服务器发送请求来测试服务器的功能性 |
| TRACE |
回显服务器收到的请求，用于测试或诊断 |
| CONNECT |
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器 |
get和Post区别：
| GET |
POST |
|
| 可见性 |
数据在URL中对所有人可见 |
数据不会显示在URL中 |
| 安全性 |
与post相比，get的安全性较差，因为所 |
安全，因为参数不会被保存在浏览器 |
| 数据长度 |
受限制，最长2kb |
无限制 |
| 编码类型 |
application/x-www-form-urlencoded |
multipart/form-data |
| 缓存 |
能被缓存 |
不能被缓存 |
4、HTTP常见响应状态码
100：Continue --- 继续。客户端应继续其请求。
200：OK --- 请求成功。一般用于GET与POST请求。
301：Moved Permanently --- 永久重定向。
302：Found --- 暂时重定向。
400：Bad Request --- 客户端请求的语法错误，服务器无法理解。
403：Forbideen --- 服务器理解请求客户端的请求，但是拒绝执行此请求。
404：Not Found --- 服务器无法根据客户端的请求找到资源（网页）。
500：Internal Server Error --- 服务器内部错误，无法完成请求。
502：Bad Gateway --- 作为网关或者代理服务器尝试执行请求时，从远程服务器接收到了无效的响应。
5、重定向和转发区别
重定向：redirect：
地址栏发生变化
重定向可以访问其他站点（服务器）的资源
重定向是两次请求。不能使用request对象来共享数据
转发：forward：
转发地址栏路径不变
转发只能访问当前服务器下的资源
转发是一次请求，可以使用request对象共享数据
6、Cookie和Session区别。
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但两者有所区别：
Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行欺骗,考虑到安全应当使用session。
Cookie ⼀般⽤来保存⽤户信息，Session 的主要作⽤就是通过服务端记录⽤户的状态
过程：DNS解析、TCP连接、发送HTTP请求、服务器处理请求并返回HTTP报文、浏览器渲染、结束
| 过程 |
使用的协议 |
| 1、浏览器查找域名DNS的IP地址 |
DNS：获取域名对应的ip |
| 2、根据ip建立TCP连接 |
TCP：与服务器建立连接 |
| 3、浏览器向服务器发送HTTP请求 |
HTTP：发送请求 |
| 4、服务器响应HTTP响应 |
HTTP |
| 5、浏览器进行渲染 |
进程：是资源分配的最小单位，一个进程可以有多个线程，多个线程共享进程的堆和方法区资源，不共享栈、程序计数器
线程：是任务调度和执行的最小单位，线程并行执行存在资源竞争和上下文切换的问题
协程：是一种比线程更加轻量级的存在，正如一个进程可以拥有多个线程一样，一个线程可以拥有多个协程。
1、进程间通信方式IPC
管道pipe：
亲缘关系使用匿名管道，非亲缘关系使用命名管道，管道遵循FIFO，半双工，数据只能单向通信；
信号：
信号是一种比较复杂的通信方式，用户调用kill命令将信号发送给其他进程。
消息队列：
消息队列克服了信号传递信息少，管道只能承载无格式字节流以及缓冲区大小受限等特点。
共享内存(share memory)：
信号量(Semaphores) ：
信号量是⼀个计数器，⽤于多进程对共享数据的访问，这种通信⽅式主要⽤于解决与同步相关的问题并避免竞争条件。
套接字(Sockets) :
简单的说就是通信的两⽅的⼀种约定，⽤套接字中的相关函数来完成通信过程。
2、用户态和核心态
用户态：只能受限的访问内存，运行所有的应用程序
核心态：运行操作系统程序，cpu可以访问内存的所有数据，包括外围设备
为什么要有用户态和内核态：
由于需要限制不同的程序之间的访问能力, 防止他们获取别的程序的内存数据, 或者获取外围设备的数据, 并发送到网络
用户态切换到内核态的3种方式：
a. 系统调用
主动调用，系统调用的机制其核心还是使用了操作系统为用户特别开放的一个中断来实现，例如Linux的int 80h中断。
b. 异常
当CPU在执行运行在用户态下的程序时，发生了某些事先不可知的异常，比如缺页异常，这时会触发切换内核态处理异常。
c. 外围设备的中断
当外围设备完成用户请求的操作后，会向CPU发出相应的中断信号，这时CPU会由用户态到内核态的切换。
3、操作系统的进程空间
栈区（stack）— 由编译器自动分配释放 ，存放函数的参数值，局部变量的值等。
堆区（heap）— 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。
静态区（static）—存放全局变量和静态变量的存储
代码区(text)—存放函数体的二进制代码。
线程共享堆区、静态区
存管理方式：页式管理、段式管理、段页式管理
分段管理：
将程序的地址空间划分为若干段（segment），如代码段，数据段，堆栈段；这样每个进程有一个二维地址空间，相互独立，互不干扰。段式管理的优点是：没有内碎片（因为段大小可变，改变段大小来消除内碎片）。但段换入换出时，会产生外碎片（比如4k的段换5k的段，会产生1k的外碎片）
分页管理：
在页式存储管理中，将程序的逻辑地址划分为固定大小的页（page），而物理内存划分为同样大小的页框，程序加载时，可以将任意一页放入内存中任意一个页框，这些页框不必连续，从而实现了离散分离。页式存储管理的优点是：没有外碎片（因为页的大小固定），但会产生内碎片（一个页可能填充不满）
段页式管理：
段⻚式管理机制结合了段式管理和⻚式管理的优点。简单来说段⻚式管理机制就是把主存先分成若⼲段，每个段⼜分成若⼲⻚，也就是说 段⻚式管理机制 中段与段之间以及段的内部的都是离散的
1、页面置换算法FIFO、LRU
置换算法：先进先出FIFO、最近最久未使用LRU、最佳置换算法OPT
先进先出FIFO:
缺点：没有考虑到实际的页面使用频率，性能差、与通常页面使用的规则不符合，实际应用较少
最近最久未使用LRU:
原理：选择最近且最久未使用的页面进行淘汰
优点：考虑到了程序访问的时间局部性，有较好的性能，实际应用也比较多
缺点：没有合适的算法，只有适合的算法，lFU、random都可以
/**
* @program: Java
* @description: LRU最近最久未使用置换算法，通过LinkedHashMap实现
* @author: Mr.Li
* @create: 2020-07-17 10:29
**/
public class LRUCache {
private LinkedHashMap<Integer,Integer> cache;
private int capacity; //容量大小
/**
*初始化构造函数
* @param capacity
*/
public LRUCache(int capacity) {
cache = new LinkedHashMap<>(capacity);
this.capacity = capacity;
}
public int get(int key) {
//缓存中不存在此key，直接返回
if(!cache.containsKey(key)) {
return -1;
}
int res = cache.get(key);
cache.remove(key); //先从链表中删除
cache.put(key,res); //再把该节点放到链表末尾处
return res;
}
public void put(int key,int value) {
if(cache.containsKey(key)) {
cache.remove(key); //已经存在，在当前链表移除
}
if(capacity == cache.size()) {
//cache已满，删除链表头位置
Set<Integer> keySet = cache.keySet();
Iterator<Integer> iterator = keySet.iterator();
cache.remove(iterator.next());
}
cache.put(key,value); //插入到链表末尾
}
}
/**
* @program: Java
* @description: LRU最近最久未使用置换算法，通过LinkedHashMap内部removeEldestEntry方法实现
* @author: Mr.Li
* @create: 2020-07-17 10:59
**/
class LRUCache {
private Map<Integer, Integer> map;
private int capacity;
/**
*初始化构造函数
* @param capacity
*/
public LRUCache(int capacity) {
this.capacity = capacity;
map = new LinkedHashMap<Integer, Integer>(capacity, 0.75f, true) {
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
return size() > capacity; // 容量大于capacity 时就删除
}
};
}
public int get(int key) {
//返回key对应的value值，若不存在，返回-1
return map.getOrDefault(key, -1);
}
public void put(int key, int value) {
map.put(key, value);
}
}
最佳置换算法OPT:
原理：每次选择当前物理块中的页面在未来长时间不被访问的或未来不再使用的页面进行淘汰
优点：具有较好的性能，可以保证获得最低的缺页率
缺点：过于理想化，但是实际上无法实现（没办法预知未来的页面）
2、死锁条件、解决方式。
死锁是指两个或两个以上进程在执行过程中，因争夺资源而造成的下相互等待的现象；
死锁的条件：
互斥条件：进程对所分配到的资源不允许其他进程访问，若其他进程访问该资源，只能等待至占有该资源的进程释放该资源；
请求与保持条件：进程获得一定的资源后，又对其他资源发出请求，阻塞过程中不会释放自己已经占有的资源
非剥夺条件：进程已获得的资源，在未完成使用之前，不可被剥夺，只能在使用后自己释放
循环等待条件：系统中若干进程组成环路，环路中每个进程都在等待相邻进程占用的资源
解决方法：破坏死锁的任意一条件
乐观锁，破坏资源互斥条件，CAS
资源一次性分配，从而剥夺请求和保持条件、tryLock
可剥夺资源：即当进程新的资源未得到满足时，释放已占有的资源，从而破坏不可剥夺的条件，数据库deadlock超时
资源有序分配法：系统给每类资源赋予一个序号，每个进程按编号递增的请求资源，从而破坏环路等待的条件，转账场景
特性：封装、继承、多态
封装：对抽象的事物抽象化成一个对象，并对其对象的属性私有化，同时提供一些能被外界访问属性的方法；
继承：子类扩展新的数据域或功能，并复用父类的属性与功能，单继承，多实现；
多态：通过继承（多个⼦类对同⼀⽅法的重写）、也可以通过接⼝（实现接⼝并覆盖接⼝）
1、Java与C++区别
不同点：c++支持多继承，并且有指针的概念，由程序员自己管理内存；Java是单继承，可以用接口实现多继承，Java 不提供指针来直接访问内存，程序内存更加安全，并且Java有JVM⾃动内存管理机制，不需要程序员⼿动释放⽆⽤内存
2、多态实现原理
多态的底层实现是动态绑定，即在运行时才把方法调用与方法实现关联起来。
静态绑定与动态绑定：
一种是在编译期确定，被称为静态分派，比如方法的重载；
一种是在运行时确定，被称为动态分派，比如方法的覆盖（重写）和接口的实现。
多态的实现
虚拟机栈中会存放当前方法调用的栈帧（局部变量表、操作栈、动态连接 、返回地址）。多态的实现过程，就是方法调用动态分派的过程，如果子类覆盖了父类的方法，则在多态调用中，动态绑定过程会首先确定实际类型是子类，从而先搜索到子类中的方法。这个过程便是方法覆盖的本质。
3、static和final关键字
static：可以修饰属性、方法
static修饰属性：
类级别属性，所有对象共享一份，随着类的加载而加载（只加载一次），先于对象的创建；可以使用类名直接调用。
static修饰方法：
随着类的加载而加载；可以使用类名直接调用；静态方法中，只能调用静态的成员，不可用this；
final：关键字主要⽤在三个地⽅：变量、⽅法、类。
final修饰变量：
如果是基本数据类型的变量，则其数值⼀旦在初始化之后便不能更改；
如果是引⽤类型的变量，则在对其初始化之后便不能再让其指向另⼀个对象。
final修饰方法：
把⽅法锁定，以防任何继承类修改它的含义（重写）；类中所有的 private ⽅法都隐式地指定为 final。
final修饰类：
final 修饰类时，表明这个类不能被继承。final 类中的所有成员⽅法都会被隐式地指定为 final ⽅法。
一个类不能被继承，除了final关键字之外，还有可以私有化构造器。（内部类无效）
4、抽象类和接口
抽象类：包含抽象方法的类，即使用abstract修饰的类；抽象类只能被继承，所以不能使用final修饰，抽象类不能被实例化，
接口：接口是一个抽象类型，是抽象方法的集合，接口支持多继承，接口中定义的方法，默认是public abstract修饰的抽象方法
相同点：
① 抽象类和接口都不能被实例化
② 抽象类和接口都可以定义抽象方法，子类/实现类必须覆写这些抽象方法
不同点：
① 抽象类有构造方法，接口没有构造方法
③抽象类可以包含普通方法，接口中只能是public abstract修饰抽象方法（Java8之后可以）
③ 抽象类只能单继承，接口可以多继承
④ 抽象类可以定义各种类型的成员变量，接口中只能是public static final修饰的静态常量
抽象类的使用场景：
既想约束子类具有共同的行为（但不再乎其如何实现），又想拥有缺省的方法，又能拥有实例变量
接口的应用场景：
约束多个实现类具有统一的行为，但是不在乎每个实现类如何具体实现；实现类中各个功能之间可能没有任何联系
5、泛型以及泛型擦除
参考：Java泛型类型擦除以及类型擦除带来的问题_heroleader的博客-CSDN博客
泛型：
泛型的本质是参数化类型。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口和泛型方法。
泛型擦除：
Java的泛型是伪泛型，使用泛型的时候加上类型参数，在编译器编译生成的字节码的时候会去掉，这个过程成为类型擦除。
如List等类型，在编译之后都会变成 List。JVM 看到的只是 List，而由泛型附加的类型信息对 JVM 来说是不可见的。
可以通过反射添加其它类型元素
6、反射原理以及使用场景
Java反射：
是指在运行状态中，对于任意一个类都能够知道这个类所有的属性和方法；并且都能够调用它的任意一个方法；
反射原理：
反射首先是能够获取到Java中的反射类的字节码，然后将字节码中的方法，变量，构造函数等映射成 相应的 Method、Filed、Constructor 等类
如何得到Class的实例:
1.类名.class(就是一份字节码) 2.Class.forName(String className);根据一个类的全限定名来构建Class对象 3.每一个对象多有getClass()方法:obj.getClass();返回对象的真实类型
使用场景：
7、Java异常体系
Throwable 是 Java 语言中所有错误或异常的超类。下一层分为 Error 和 Exception
Error ：
是指 java 运行时系统的内部错误和资源耗尽错误。应用程序不会抛出该类对象。如果出现了这样的错误，除了告知用户，剩下的就是尽力使程序安全的终止。
Exception 包含：RuntimeException 、CheckedException
编程错误可以分成三类：语法错误、逻辑错误和运行错误。
语法错误（也称编译错误）是在编译过程中出现的错误，由编译器检查发现语法错误
逻辑错误指程序的执行结果与预期不符，可以通过调试定位并发现错误的原因
运行错误是引起程序非正常终端的错误，需要通过异常处理的方式处理运行错误
RuntimeException： 运行时异常，程序应该从逻辑角度尽可能避免这类异常的发生。
如 NullPointerException 、 ClassCastException ；
CheckedException：受检异常，程序使用trycatch进行捕捉处理
如IOException、SQLException、NotFoundException；
1、ArrayList和LinkedList
ArrayList：
底层基于数组实现，支持对元素进行快速随机访问，适合随机查找和遍历，不适合插入和删除。（提一句实际上）
默认初始大小为10，当数组容量不够时，会触发扩容机制（扩大到当前的1.5倍），需要将原来数组的数据复制到新的数组中；当从 ArrayList 的中间位置插入或者删除元素时，需要对数组进行复制、移动、代价比较高。
LinkedList：
底层基于双向链表实现，适合数据的动态插入和删除；
内部提供了 List 接口中没有定义的方法，用于操作表头和表尾元素，可以当作堆栈、队列和双向队列使用。（比如jdk官方推荐使用基于linkedList的Deque进行堆栈操作）
ArrayList与LinkedList区别：
都是线程不安全的，ArrayList 适用于查找的场景，LinkedList 适用于增加、删除多的场景
实现线程安全：
可以使用原生的Vector，或者是Collections.synchronizedList(List list)函数返回一个线程安全的ArrayList集合。
建议使用concurrent并发包下的CopyOnWriteArrayList的。
①Vector: 底层通过synchronize修饰保证线程安全，效率较差
②CopyOnWriteArrayList：写时加锁，使用了一种叫写时复制的方法；读操作是可以不用加锁的
2、List遍历快速和安全失败
①普通for循环遍历List删除指定元素
for(int i=0; i < list.size(); i++){ if(list.get(i) == 5) list.remove(i); }
② 迭代遍历,用list.remove(i)方法删除元素
Iterator<Integer> it = list.iterator(); while(it.hasNext()){ Integer value = it.next(); if(value == 5){ list.remove(value); } }
③foreach遍历List删除元素
for(Integer i:list){ if(i==3) list.remove(i); }
fail—fast：快速失败
当异常产生时，直接抛出异常，程序终止;
fail-fast主要是体现在当我们在遍历集合元素的时候，经常会使用迭代器，但在迭代器遍历元素的过程中，如果集合的结构（modCount）被改变的话，就会抛出异常ConcurrentModificationException，防止继续遍历。这就是所谓的快速失败机制。
fail—safe：安全失败
采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。由于在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发ConcurrentModificationException。
缺点：基于拷贝内容的优点是避免了ConcurrentModificationException，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。
场景：java.util.concurrent包下的容器都是安全失败，可以在多线程下并发使用，并发修改。
3、详细介绍HashMap
角度：数据结构+扩容情况+put查找的详细过程+哈希函数+容量为什么始终都是2^N，JDK1.7与1.8的区别。
参考：https://www.jianshu.com/p/9fe4cb316c05
数据结构：
HashMap在底层数据结构上采用了数组＋链表＋红黑树，通过散列映射来存储键值对数据
扩容情况：
默认的负载因子是0.75，如果数组中已经存储的元素个数大于数组长度的75%，将会引发扩容操作。
【1】创建一个长度为原来数组长度两倍的新数组。
【2】1.7采用Entry的重新hash运算，1.8采用高于与运算。
put操作步骤：
1、判断数组是否为空，为空进行初始化;
2、不为空，则计算 key 的 hash 值，通过(n - 1) & hash计算应当存放在数组中的下标 index;
3、查看 table[index] 是否存在数据，没有数据就构造一个Node节点存放在 table[index] 中；
4、存在数据，说明发生了hash冲突(存在二个节点key的hash值一样), 继续判断key是否相等，相等，用新的value替换原数据；
5、若不相等，判断当前节点类型是不是树型节点，如果是树型节点，创造树型节点插入红黑树中；
6、若不是红黑树，创建普通Node加入链表中；判断链表长度是否大于 8，大于则将链表转换为红黑树；
7、插入完成之后判断当前节点数是否大于阈值，若大于，则扩容为原数组的二倍
哈希函数：
通过hash函数（优质因子31循环累加）先拿到 key 的hashcode，是一个32位的值，然后让hashcode的高16位和低16位进行异或操作。该函数也称为扰动函数，做到尽可能降低hash碰撞，通过尾插法进行插入。
容量为什么始终都是2^N：
先做对数组的⻓度取模运算，得到的余数才能⽤来要存放的位置也就是对应的数组下标。这个数组下标的计算⽅法是“ (n - 1) & hash ”。（n代表数组⻓度）。方便数组的扩容和增删改时的取模。
JDK1.7与1.8的区别：
JDK1.7 HashMap：
底层是 数组和链表 结合在⼀起使⽤也就是链表散列。如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。扩容翻转时顺序不一致使用头插法会产生死循环，导致cpu100%
JDK1.8 HashMap：
底层数据结构上采用了数组＋链表＋红黑树；当链表⻓度⼤于阈值（默认为 8-泊松分布），数组的⻓度大于 64时，链表将转化为红⿊树，以减少搜索时间。（解决了tomcat臭名昭著的url参数dos攻击问题）
**4、ConcurrentHashMap **
可以通过ConcurrentHashMap 和 Hashtable来实现线程安全；Hashtable 是原始API类，通过synchronize同步修饰，效率低下；ConcurrentHashMap 通过分段锁实现，效率较比Hashtable要好；
ConcurrentHashMap的底层实现：
JDK1.7的 ConcurrentHashMap 底层采⽤ 分段的数组+链表 实现；采用 分段锁（Sagment） 对整个桶数组进⾏了分割分段(Segment默认16个)，每⼀把锁只锁容器其中⼀部分数据，多线程访问容器⾥不同数据段的数据，就不会存在锁竞争，提⾼并发访问率。
JDK1.8的 ConcurrentHashMap 采⽤的数据结构跟HashMap1.8的结构⼀样，数组+链表/红⿊树；摒弃了Segment的概念，⽽是直接⽤ Node 数组+链表+红⿊树的数据结构来实现，通过并发控制 synchronized 和CAS来操作保证线程的安全。
5、序列化和反序列化
序列化的意思就是将对象的状态转化成字节流，以后可以通过这些值再生成相同状态的对象。对象序列化是对象持久化的一种实现方法，它是将对象的属性和方法转化为一种序列化的形式用于存储和传输。反序列化就是根据这些保存的信息重建对象的过程。
序列化：将java对象转化为字节序列的过程。
反序列化：将字节序列转化为java对象的过程。
优点：
a、实现了数据的持久化，通过序列化可以把数据永久地保存到硬盘上（通常存放在文件里）Redis的RDB
b、利用序列化实现远程通信，即在网络上传送对象的字节序列。 Google的protoBuf
反序列化失败的场景：
序列化ID：serialVersionUID不一致的时候，导致反序列化失败
6、String
String 使用数组存储内容，数组使用 final 修饰，因此 String 定义的字符串的值也是不可变的
StringBuffer 对方法加了同步锁，线程安全，效率略低于 StringBuilder
1、单例模式
某个类只能生成一个实例，该实例全局访问，例如Spring容器里一级缓存里的单例池。
优点：
唯一访问：如生成唯一序列化的场景、或者spring默认的bean类型。
提高性能：频繁实例化创建销毁或者耗时耗资源的场景，如连接池、线程池。
缺点：
不适合有状态且需变更的
实现方式：
饿汉式：线程安全速度快
懒汉式：双重检测锁，第一次减少锁的开销、第二次防止重复、volatile防止重排序导致实例化未完成
静态内部类：线程安全利用率高
枚举：effictiveJAVA推荐，反射也无法破坏
2、工厂模式
定义一个用于创建产品的接口，由子类决定生产何种产品。
优点：解耦：提供参数即可获取产品，通过配置文件可以不修改代码增加具体产品。
缺点：每增加一个产品就得新增一个产品类
3、抽象工厂模式
提供一个接口，用于创建相关或者依赖对象的家族，并由此进行约束。
优点：可以在类的内部对产品族进行约束
缺点：假如产品族中需要增加一个新的产品，则几乎所有的工厂类都需要进行修改。
构造方法可以被重载，只有当类中没有显性声明任何构造方法时，才会有默认构造方法。
构造方法没有返回值，构造方法的作用是创建新对象。
静态初始化块的优先级最高，会最先执行，在非静态初始化块之前执行。
静态初始化块会在类第一次被加载时最先执行，因此在 main 方法之前。
关键字 this 代表当前对象的引用。当前对象指的是调用类中的属性或方法的对象
关键字 this 不可以在静态方法中使用。静态方法不依赖于类的具体对象的引用
重载指在同一个类中定义多个方法，这些方法名称相同，签名不同。
重写指在子类中的方法的名称和签名都和父类相同，使用override注解
toString 默认是个指针，一般需要重写
equals 比较对象是否相同，默认和==功能一致
hashCode 散列码，equals则hashCode相同，所以重写equals必须重写hashCode
**finalize ** 用于垃圾回收之前做的遗嘱，默认空，子类需重写
clone 深拷贝，类需实现cloneable的接口
getClass 反射获取对象元数据，包括类名、方法、
notify、wait 用于线程通知和唤醒
| 类型 |
缓存范围 |
| Byte,Short,Integer,Long |
[-128, 127] |
| Character |
[0, 127] |
| Boolean |
[false, true] |
1、JVM运行时数据区域
堆、方法区（元空间）、虚拟机栈、本地方法栈、程序计数器
Heap(堆)：
对象的实例以及数组的内存都是要在堆上进行分配的，堆是线程共享的一块区域，用来存放对象实例，也是垃圾回收（GC）的主要区域；开启逃逸分析后，某些未逃逸的对象可以通过标量替换的方式在栈中分配
堆细分：新生代、老年代，对于新生代又分为：Eden区和Surviver1和Surviver2区；
方法区：
对于JVM的方法区也可以称之为永久区，它储存的是已经被java虚拟机加载的类信息、常量、静态变量；Jdk1.8以后取消了方法区这个概念，称之为元空间（MetaSpace）；
当应用中的 Java 类过多时，比如 Spring 等一些使用动态代理的框架生成了很多类，如果占用空间超出了我们的设定值，就会发生元空间溢出
虚拟机栈：
虚拟机栈是线程私有的，他的生命周期和线程的生命周期是一致的。里面装的是一个一个的栈帧，每一个方法在执行的时候都会创建一个栈帧，栈帧中用来存放（局部变量表、操作数栈 、动态链接 、返回地址）；在Java虚拟机规范中，对此区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将会抛出StackOverflowError异常；如果虚拟机栈动态扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。
本地方法栈：
本地方法栈和虚拟机栈类似，不同的是虚拟机栈服务的是Java方法，而本地方法栈服务的是Native方法。在HotSpot虚拟机实现中是把本地方法栈和虚拟机栈合二为一的，同理它也会抛出StackOverflowError和OOM异常。
PC程序计数器：
PC，指的是存放下一条指令的位置的一个指针。它是一块较小的内存空间，且是线程私有的。由于线程的切换，CPU在执行的过程中，需要记住原线程的下一条指令的位置，所以每一个线程都需要有自己的PC。
2、堆内存分配策略
3、创建一个对象的步骤
步骤：类加载检查、分配内存、初始化零值、设置对象头、执行init方法
①类加载检查：
虚拟机遇到 new 指令时，⾸先去检查是否能在常量池中定位到这个类的符号引⽤，并且检查这个符号引⽤代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执⾏相应的类加载过程。
②分配内存：
在类加载检查通过后，接下来虚拟机将为新⽣对象分配内存，分配⽅式有 “指针碰撞” 和 “空闲列表” 两种，选择那种分配⽅式由 Java 堆是否规整决定，⽽Java堆是否规整⼜由所采⽤的垃圾收集器是否带有压缩整理功能决定。
③初始化零值：
内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值，这⼀步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使⽤，程序能访问到这些字段的数据类型所对应的零值。
④设置对象头：
初始化零值完成之后，虚拟机要对对象进⾏必要的设置，例如这个对象是那个类的实例、如何才能找到类的元数据信息、对象的哈希吗、对象的 GC 分代年龄等信息。 这些信息存放在对象头中。 另外，根据虚拟机当前运⾏状态的不同，如是否启⽤偏向锁等，对象头会有不同的设置⽅式。
⑤执⾏ init ⽅法：
从虚拟机的视⻆来看，⼀个新的对象已经产⽣了，但从Java 程序的视⻆来看， ⽅法还没有执⾏，所有的字段都还为零。所以⼀般来说（除循环依赖），执⾏ new 指令之后会接着执⾏ ⽅法，这样⼀个真正可⽤的对象才算产⽣出来。
4、对象引用
普通的对象引用关系就是强引用。
软引用用于维护一些可有可无的对象。只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。
弱引用对象相比软引用来说，要更加无用一些，它拥有更短的生命周期，当 JVM 进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。
虚引用是一种形同虚设的引用，在现实场景中用的不是很多，它主要用来跟踪对象被垃圾回收的活动。
过程：加载、验证、准备、解析、初始化
加载阶段：
1.通过一个类的全限定名来获取定义此类的二进制字节流。
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3.在Java堆中生成一个代表这个类的java.lang.class对象，作为方法区这些数据的访问入口。
验证阶段：
1.文件格式验证（是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理）
2.元数据验证（对字节码描述的信息进行语意分析，以保证其描述的信息符合Java语言规范要求）
3.字节码验证（保证被校验类的方法在运行时不会做出危害虚拟机安全的行为）
4.符号引用验证（虚拟机将符号引用转化为直接引用时，解析阶段中发生）
准备阶段：
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段。将对象初始化为“零”值
解析阶段：
解析阶段时虚拟机将常量池内的符号引用替换为直接引用的过程。
字符串常量池：堆上，默认class文件的静态常量池
运行时常量池：在方法区，属于元空间
初始化阶段：
初始化阶段时加载过程的最后一步，而这一阶段也是真正意义上开始执行类中定义的Java程序代码。
1、双亲委派机制
每⼀个类都有⼀个对应它的类加载器。系统中的 ClassLoder 在协同⼯作的时候会默认使⽤ 双亲委派模型 。即在类加载的时候，系统会⾸先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，⾸先会把该请求委派该⽗类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当⽗类加载器⽆法处理时，才由⾃⼰来处理。当⽗类加载器为null时，会使⽤启动类加载器 BootstrapClassLoader 作为⽗类加载器。
使用好处：
此机制保证JDK核心类的优先加载；使得Java程序的稳定运⾏，可以避免类的重复加载，也保证了 Java 的核⼼ API 不被篡改。如果不⽤没有使⽤双亲委派模型，⽽是每个类加载器加载⾃⼰的话就会出现⼀些问题，⽐如我们编写⼀个称为 java.lang.Object 类的话，那么程序运⾏的时候，系统就会出现多个不同的Object 类。
破坏双亲委派机制：
2、tomcat的类加载机制
步骤：
总结一下以上步骤，WebAppClassLoader 加载类的时候，故意打破了JVM 双亲委派机制，绕开了 AppClassLoader，直接先使用 ExtClassLoader 来加载类。
1、存活算法和两次标记过程
引用计数法：
给对象添加一个引用计数器，每当由一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
优点：实现简单，判定效率也很高
缺点：他很难解决对象之间相互循环引用的问题，基本上被抛弃
可达性分析法：
通过一系列的成为“GC Roots”(活动线程相关的各种引用，虚拟机栈帧引用，静态变量引用，JNI引用)的对象作为起始点，从这些节点ReferenceChains开始向下搜索，搜索所走过的路径成为引用链，当一个对象到GC ROOTS没有任何引用链相连时，则证明此对象时不可用的；
两次标记过程：
对象被回收之前，该对象的finalize()方法会被调用；两次标记，即第一次标记不在“关系网”中的对象。第二次的话就要先判断该对象有没有实现finalize()方法了，如果没有实现就直接判断该对象可回收；如果实现了就会先放在一个队列中，并由虚拟机建立的一个低优先级的线程去执行它，随后就会进行第二次的小规模标记，在这次被标记的对象就会真正的被回收了。
2、垃圾回收算法
垃圾回收算法：复制算法、标记清除、标记整理、分代收集
复制算法：(young)
将内存分为⼤⼩相同的两块，每次使⽤其中的⼀块。当这⼀块的内存使⽤完后，就将还存活的对象复制到另⼀块去，然后再把使⽤的空间⼀次清理掉。这样就使每次的内存回收都是对内存区间的⼀半进⾏回收；
优点：实现简单，内存效率高，不易产生碎片
缺点：内存压缩了一半，倘若存活对象多，Copying 算法的效率会大大降低
标记清除：(cms)
标记出所有需要回收的对象，在标记完成后统⼀回收所有被标记的对象
缺点：效率低，标记清除后会产⽣⼤量不连续的碎⽚，需要预留空间给分配阶段的浮动垃圾
标记整理：(old)
标记过程仍然与“标记-清除”算法⼀样，再让所有存活的对象向⼀端移动，然后直接清理掉端边界以外的内存；解决了产生大量不连续碎片问题
分代收集：
根据各个年代的特点选择合适的垃圾收集算法。
新生代采用复制算法，新生代每次垃圾回收都要回收大部分对象，存活对象较少，即要复制的操作比较少，一般将新生代划分为一块较大的 Eden 空间和两个较小的 Survivor 空间(From Space, To Space)，每次使用Eden 空间和其中的一块 Survivor 空间，当进行回收时，将该两块空间中还存活的对象复制到另一块 Survivor 空间中。
老年代的对象存活⼏率是⽐较⾼的，⽽且没有额外的空间对它进⾏分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进⾏垃圾收集。
Safepoint 当发生 GC 时，用户线程必须全部停下来，才可以进行垃圾回收，这个状态我们可以认为 JVM 是安全的（safe），整个堆的状态是稳定的。如果在 GC 前，有线程迟迟进入不了 safepoint，那么整个 JVM 都在等待这个阻塞的线程，造成了整体 GC 的时间变长
MinorGC、MajorGC、FullGC
MinorGC 在年轻代空间不足的时候发生，
MajorGC 指的是老年代的 GC，出现 MajorGC 一般经常伴有 MinorGC。
FullGC 1、当老年代无法再分配内存的时候；2、元空间不足的时候；3、显示调用 System.gc 的时候。另外，像 CMS 一类的垃圾回收器，在 MinorGC 出现 promotion failure 的时候也会发生 FullGC。
对象优先在 Eden 区分配
大多数情况下，对象在新生代 Eden 区分配，当 Eden 区空间不够时，发起 Minor GC。
大对象直接进入老年代
大对象是指需要连续内存空间的对象，比如很长的字符串以及数组。老年代直接分配的目的是避免在 Eden 区和 Survivor 区之间出现大量内存复制。
长期存活的对象进入老年代
虚拟机给每个对象定义了年龄计数器，对象在 Eden 区出生之后，如果经过一次 Minor GC 之后，将进入 Survivor 区，同时对象年龄变为 1，增加到一定阈值时则进入老年代（阈值默认为 15）
动态对象年龄判定
为了能更好地适应不同程序的内存状况，虚拟机并不总是要求对象的年龄必须达到阈值才能进入老年代。如果在 Survivor 区中相同年龄的所有对象的空间总和大于 Survivor 区空间的一半，则年龄大于或等于该年龄的对象直接进入老年代。
空间分配担保
在发生 Minor GC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象的空间总和，如果这个条件成立，那么 Minor GC 可以确保是安全的。如果不成立则进行 Full GC。
3、垃圾收集器
JDK3：Serial Parnew 关注效率
Serial：
Serial 是一个单线程的收集器，它不但只会使用一个 CPU 或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。适合用于客户端垃圾收集器。
Parnew：
ParNew 垃圾收集器其实是 Serial 收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和 Serial 收集器完全一样，ParNew 垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。
JDK5：parallel Scavenge+（Serial old/parallel old）关注吞吐量
parallel Scavenge：(关注吞吐量)
Parallel Scavenge收集器关注点是吞吐量（⾼效率的利⽤CPU）。CMS等垃圾收集器的关注点更多的是⽤户线程的停顿时间（提⾼⽤户体验）；高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。
Serial old：
Serial收集器的⽼年代版本，它同样是⼀个单线程收集器，使用标记-整理算法。主要有两个用途：
parallel old：
Parallel Scavenge收集器的⽼年代版本。使⽤多线程和“标记-整理”算法。
JDK8-CMS：（关注最短垃圾回收停顿时间）
CMS收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下 4 个阶段：
初始标记：只是标记一下 GC Roots 能直接关联的对象，速度很快，STW。
并发标记：进行 ReferenceChains跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
重新标记：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，STW。
并发清除：清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。
由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行。
优点：并发收集、低停顿
缺点：对CPU资源敏感；⽆法处理浮动垃圾；使⽤“标记清除”算法，会导致⼤量空间碎⽚产⽣。
JDK9-G1：（精准控制停顿时间，避免垃圾碎片）
是⼀款⾯向服务器的垃圾收集器,主要针对配备多颗处理器及⼤容量内存的机器.以极⾼概率满⾜GC停顿时间要求的同时,还具备⾼吞吐量性能特征；相比与 CMS 收集器，G1 收集器两个最突出的改进是：
【1】基于标记-整理算法，不产生内存碎片。
【2】可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。
G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收集效率。
**JDK11-ZGC:**（在不关注容量的情况获取最小停顿时间5TB/10ms）
着色笔技术：加快标记过程
读屏障：解决GC和应用之间并发导致的STW问题
4、配置垃圾收集器
4、JVM性能调优
对应进程的JVM状态以定位问题和解决问题并作出相应的优化
常用命令：jps、jinfo、jstat、jstack、jmap
jps：查看java进程及相关信息
jps -l 输出jar包路径，类全名 jps -m 输出main参数 jps -v 输出JVM参数
jinfo：查看JVM参数
jinfo 11666 jinfo -flags 11666 Xmx、Xms、Xmn、MetaspaceSize
jstat：查看JVM运行时的状态信息，包括内存状态、垃圾回收
jstat [option] LVMID [interval] [count]其中LVMID是进程id，interval是打印间隔时间（毫秒），count是打印次数（默认一直打印） option参数解释：-gc 垃圾回收堆的行为统计-gccapacity 各个垃圾回收代容量(young,old,perm)和他们相应的空间统计-gcutil 垃圾回收统计概述-gcnew 新生代行为统计-gcold 年老代和永生代行为统计
jstack：查看JVM线程快照，jstack命令可以定位线程出现长时间卡顿的原因，例如死锁，死循环
jstack [-l] <pid> (连接运行中的进程) option参数解释：-F 当使用jstack <pid>无响应时，强制输出线程堆栈。-m 同时输出java和本地堆栈(混合模式)-l 额外显示锁信息
jmap：可以用来查看内存信息(配合jhat使用)
jmap [option] <pid> (连接正在执行的进程)option参数解释：-heap 打印java heap摘要-dump:<dump-options> 生成java堆的dump文件
5、JDK新特性
JDK8
支持 Lamda 表达式、集合的 stream 操作、提升HashMap性能
JDK9
//Stream API中iterate方法的新重载方法，可以指定什么时候结束迭代IntStream.iterate(1, i -> i < 100, i -> i + 1).forEach(System.out::println);
默认G1垃圾回收器
JDK10
其重点在于通过完全GC并行来改善G1最坏情况的等待时间。
JDK11
ZGC (并发回收的策略) 4TB
用于 Lambda 参数的局部变量语法
JDK12
Shenandoah GC (GC 算法)停顿时间和堆的大小没有任何关系，并行关注停顿响应时间。
JDK13
增加ZGC以将未使用的堆内存返回给操作系统，16TB
JDK14
删除cms垃圾回收器、弃用ParallelScavenge+SerialOldGC垃圾回收算法组合
将ZGC垃圾回收器应用到macOS和windows平台
1、硬件故障排查
如果一个实例发生了问题，根据情况选择，要不要着急去重启。如果出现的CPU、内存飙高或者日志里出现了OOM异常
第一步是隔离，第二步是保留现场，第三步才是问题排查。
隔离
就是把你的这台机器从请求列表里摘除，比如把 nginx 相关的权重设成零。
现场保留
瞬时态和历史态
查看比如 CPU、系统内存等，通过历史状态可以体现一个趋势性问题，而这些信息的获取一般依靠监控系统的协作。
保留信息
（1）系统当前网络连接
ss -antp > $DUMP_DIR/ss.dump 2>&1
使用 ss 命令而不是 netstat 的原因，是因为 netstat 在网络连接非常多的情况下，执行非常缓慢。
后续的处理，可通过查看各种网络连接状态的梳理，来排查 TIME_WAIT 或者 CLOSE_WAIT，或者其他连接过高的问题，非常有用。
（2）网络状态统计
netstat -s > $DUMP_DIR/netstat-s.dump 2>&1
它能够按照各个协议进行统计输出，对把握当时整个网络状态，有非常大的作用。
sar -n DEV 1 2 > $DUMP_DIR/sar-traffic.dump 2>&1
在一些速度非常高的模块上，比如 Redis、Kafka，就经常发生跑满网卡的情况。表现形式就是网络通信非常缓慢。
（3）进程资源
lsof -p $PID > $DUMP_DIR/lsof-$PID.dump
通过查看进程，能看到打开了哪些文件，可以以进程的维度来查看整个资源的使用情况，包括每条网络连接、每个打开的文件句柄。同时，也可以很容易的看到连接到了哪些服务器、使用了哪些资源。这个命令在资源非常多的情况下，输出稍慢，请耐心等待。
（4）CPU 资源
mpstat > $DUMP_DIR/mpstat.dump 2>&1vmstat 1 3 > $DUMP_DIR/vmstat.dump 2>&1sar -p ALL > $DUMP_DIR/sar-cpu.dump 2>&1uptime > $DUMP_DIR/uptime.dump 2>&1
主要用于输出当前系统的 CPU 和负载，便于事后排查。
（5）I/O 资源
iostat -x > $DUMP_DIR/iostat.dump 2>&1
一般，以计算为主的服务节点，I/O 资源会比较正常，但有时也会发生问题，比如日志输出过多，或者磁盘问题等。此命令可以输出每块磁盘的基本性能信息，用来排查 I/O 问题。在第 8 课时介绍的 GC 日志分磁盘问题，就可以使用这个命令去发现。
（6）内存问题
free -h > $DUMP_DIR/free.dump 2>&1
free 命令能够大体展现操作系统的内存概况，这是故障排查中一个非常重要的点，比如 SWAP 影响了 GC，SLAB 区挤占了 JVM 的内存。
（7）其他全局
ps -ef > $DUMP_DIR/ps.dump 2>&1dmesg > $DUMP_DIR/dmesg.dump 2>&1sysctl -a > $DUMP_DIR/sysctl.dump 2>&1
dmesg 是许多静悄悄死掉的服务留下的最后一点线索。当然，ps 作为执行频率最高的一个命令，由于内核的配置参数，会对系统和 JVM 产生影响，所以我们也输出了一份。
（8）进程快照，最后的遗言（jinfo）
${JDK_BIN}jinfo $PID > $DUMP_DIR/jinfo.dump 2>&1
此命令将输出 Java 的基本进程信息，包括环境变量和参数配置，可以查看是否因为一些错误的配置造成了 JVM 问题。
（9）dump 堆信息
${JDK_BIN}jstat -gcutil $PID > $DUMP_DIR/jstat-gcutil.dump 2>&1${JDK_BIN}jstat -gccapacity $PID > $DUMP_DIR/jstat-gccapacity.dump 2>&1
jstat 将输出当前的 gc 信息。一般，基本能大体看出一个端倪，如果不能，可将借助 jmap 来进行分析。
（10）堆信息
${JDK_BIN}jmap $PID > $DUMP_DIR/jmap.dump 2>&1${JDK_BIN}jmap -heap $PID > $DUMP_DIR/jmap-heap.dump 2>&1${JDK_BIN}jmap -histo $PID > $DUMP_DIR/jmap-histo.dump 2>&1${JDK_BIN}jmap -dump:format=b,file=$DUMP_DIR/heap.bin $PID > /dev/null 2>&1
jmap 将会得到当前 Java 进程的 dump 信息。如上所示，其实最有用的就是第 4 个命令，但是前面三个能够让你初步对系统概况进行大体判断。因为，第 4 个命令产生的文件，一般都非常的大。而且，需要下载下来，导入 MAT 这样的工具进行深入分析，才能获取结果。这是分析内存泄漏一个必经的过程。
（11）JVM 执行栈
${JDK_BIN}jstack $PID > $DUMP_DIR/jstack.dump 2>&1
jstack 将会获取当时的执行栈。一般会多次取值，我们这里取一次即可。这些信息非常有用，能够还原 Java 进程中的线程情况。
top -Hp $PID -b -n 1 -c > $DUMP_DIR/top-$PID.dump 2>&1
为了能够得到更加精细的信息，我们使用 top 命令，来获取进程中所有线程的 CPU 信息，这样，就可以看到资源到底耗费在什么地方了。
（12）高级替补
kill -3 $PID
有时候，jstack 并不能够运行，有很多原因，比如 Java 进程几乎不响应了等之类的情况。我们会尝试向进程发送 kill -3 信号，这个信号将会打印 jstack 的 trace 信息到日志文件中，是 jstack 的一个替补方案。
gcore -o $DUMP_DIR/core $PID
对于 jmap 无法执行的问题，也有替补，那就是 GDB 组件中的 gcore，将会生成一个 core 文件。我们可以使用如下的命令去生成 dump：
${JDK_BIN}jhsdb jmap --exe ${JDK}java --core $DUMP_DIR/core --binaryheap
稍微提一下 jmap 命令，它在 9 版本里被干掉了，取而代之的是 jhsdb，你可以像下面的命令一样使用。
jhsdb jmap --heap --pid 37340jhsdb jmap --pid 37288jhsdb jmap --histo --pid 37340jhsdb jmap --binaryheap --pid 37340
一般内存溢出，表现形式就是 Old 区的占用持续上升，即使经过了多轮 GC 也没有明显改善。比如ThreadLocal里面的GC Roots，内存泄漏的根本就是，这些对象并没有切断和 GC Roots 的关系，可通过一些工具，能够看到它们的联系。
2、报表异常 | JVM调优
有一个报表系统，频繁发生内存溢出，在高峰期间使用时，还会频繁的发生拒绝服务，由于大多数使用者是管理员角色，所以很快就反馈到研发这里。
业务场景是由于有些结果集的字段不是太全，因此需要对结果集合进行循环，并通过 HttpClient 调用其他服务的接口进行数据填充。使用 Guava 做了 JVM 内缓存，但是响应时间依然很长。
初步排查，JVM 的资源太少。接口 A 每次进行报表计算时，都要涉及几百兆的内存，而且在内存里驻留很长时间，有些计算又非常耗 CPU，特别的“吃”资源。而我们分配给 JVM 的内存只有 3 GB，在多人访问这些接口的时候，内存就不够用了，进而发生了 OOM。在这种情况下，没办法，只有升级机器。把机器配置升级到 4C8G，给 JVM 分配 6GB 的内存，这样 OOM 问题就消失了。但随之而来的是频繁的 GC 问题和超长的 GC 时间，平均 GC 时间竟然有 5 秒多。
进一步，由于报表系统和高并发系统不太一样，它的对象，存活时长大得多，并不能仅仅通过增加年轻代来解决；而且，如果增加了年轻代，那么必然减少了老年代的大小，由于 CMS 的碎片和浮动垃圾问题，我们可用的空间就更少了。虽然服务能够满足目前的需求，但还有一些不太确定的风险。
第一，了解到程序中有很多缓存数据和静态统计数据，为了减少 MinorGC 的次数，通过分析 GC 日志打印的对象年龄分布，把 MaxTenuringThreshold 参数调整到了 3（特殊场景特殊的配置）。这个参数是让年轻代的这些对象，赶紧回到老年代去，不要老呆在年轻代里。
第二，我们的 GC 时间比较长，就一块开了参数 CMSScavengeBeforeRemark，使得在 CMS remark 前，先执行一次 Minor GC 将新生代清掉。同时配合上个参数，其效果还是比较好的，一方面，对象很快晋升到了老年代，另一方面，年轻代的对象在这种情况下是有限的，在整个 MajorGC 中占的时间也有限。
第三，由于缓存的使用，有大量的弱引用，拿一次长达 10 秒的 GC 来说。我们发现在 GC 日志里，处理 weak refs 的时间较长，达到了 4.5 秒。这里可以加入参数 ParallelRefProcEnabled 来并行处理Reference，以加快处理速度，缩短耗时。
优化之后，效果不错，但并不是特别明显。经过评估，针对高峰时期的情况进行调研，我们决定再次提升机器性能，改用 8core16g 的机器。但是，这带来另外一个问题。
高性能的机器带来了非常大的服务吞吐量，通过 jstat 进行监控，能够看到年轻代的分配速率明显提高，但随之而来的 MinorGC 时长却变的不可控，有时候会超过 1 秒。累积的请求造成了更加严重的后果。
这是由于堆空间明显加大造成的回收时间加长。为了获取较小的停顿时间，我们在堆上改用了 G1 垃圾回收器，把它的目标设定在 200ms。G1 是一款非常优秀的垃圾收集器，不仅适合堆内存大的应用，同时也简化了调优的工作。通过主要的参数初始和最大堆空间、以及最大容忍的 GC 暂停目标，就能得到不错的性能。修改之后，虽然 GC 更加频繁了一些，但是停顿时间都比较小，应用的运行较为平滑。
到目前为止，也只是勉强顶住了已有的业务，但是，这时候领导层面又发力，要求报表系统可以支持未来两年业务10到100倍的增长，并保持其可用性，但是这个“千疮百孔”的报表系统，稍微一压测，就宕机，那如何应对十倍百倍的压力呢 ? 硬件即使可以做到动态扩容，但是毕竟也有极限。
使用 MAT 分析堆快照，发现很多地方可以通过代码优化，那些占用内存特别多的对象：
1、select * 全量排查，只允许获取必须的数据
2、报表系统中cache实际的命中率并不高，将Guava 的 Cache 引用级别改成弱引用（WeakKeys）
3、限制报表导入文件大小，同时拆分用户超大范围查询导出请求。
每一步操作都使得JVM使用变得更加可用，一系列优化以后，机器相同压测数据性能提升了数倍。
3、大屏异常 | JUC调优
有些数据需要使用 HttpClient 来获取进行补全。提供数据的服务提供商有的响应时间可能会很长，也有可能会造成服务整体的阻塞。
接口 A 通过 HttpClient 访问服务 2，响应 100ms 后返回；接口 B 访问服务 3，耗时 2 秒。HttpClient 本身是有一个最大连接数限制的，如果服务 3 迟迟不返回，就会造成 HttpClient 的连接数达到上限，概括来讲，就是同一服务，由于一个耗时非常长的接口，进而引起了整体的服务不可用
这个时候，通过 jstack 打印栈信息，会发现大多数竟然阻塞在了接口 A 上，而不是耗时更长的接口 B，这个现象起初十分具有迷惑性，不过经过分析后，我们猜想其实是因为接口 A 的速度比较快，在问题发生点进入了更多的请求，它们全部都阻塞住的同时被打印出来了。
为了验证这个问题，我搭建了一个demo 工程，模拟了两个使用同一个 HttpClient 的接口。fast 接口用来访问百度，很快就能返回；slow 接口访问谷歌，由于众所周知的原因，会阻塞直到超时，大约 10 s。 利用ab对两个接口进行压测，同时使用 jstack 工具 dump 堆栈。首先使用 jps 命令找到进程号，然后把结果重定向到文件（可以参考 10271.jstack 文件）。
过滤一下 nio 关键字，可以查看 tomcat 相关的线程，足足有 200 个，这和 Spring Boot 默认的 maxThreads 个数不谋而合。更要命的是，有大多数线程，都处于 BLOCKED 状态，说明线程等待资源超时。通过grep fast | wc -l 分析，确实200个中有150个都是blocked的fast的进程。
问题找到了，解决方式就顺利成章了。
1、fast和slow争抢连接资源，通过线程池限流或者熔断处理
2、有时候slow的线程也不是一直slow，所以就得加入监控
3、使用带countdownLaunch对线程的执行顺序逻辑进行控制
4、接口延迟 | SWAP调优
有一个关于服务的某个实例，经常发生服务卡顿。由于服务的并发量是比较高的，每多停顿 1 秒钟，几万用户的请求就会感到延迟。
我们统计、类比了此服务其他实例的 CPU、内存、网络、I/O 资源，区别并不是很大，所以一度怀疑是机器硬件的问题。
接下来我们对比了节点的 GC 日志，发现无论是 Minor GC，还是 Major GC，这个节点所花费的时间，都比其他实例长得多。
通过仔细观察，我们发现在 GC 发生的时候，vmstat 的 si、so 飙升的非常严重，这和其他实例有着明显的不同。
使用 free 命令再次确认，发现 SWAP 分区，使用的比例非常高，引起的具体原因是什么呢？
更详细的操作系统内存分布，从 /proc/meminfo 文件中可以看到具体的逻辑内存块大小，有多达 40 项的内存信息，这些信息都可以通过遍历 /proc 目录的一些文件获取。我们注意到 slabtop 命令显示的有一些异常，dentry（目录高速缓冲）占用非常高。
问题最终定位到是由于某个运维工程师删除日志时，定时执行了一句命令：
find / | grep "xxx.log"
他是想找一个叫做 要被删除 的日志文件，看看在哪台服务器上，结果，这些老服务器由于文件太多，扫描后这些文件信息都缓存到了 slab 区上。而服务器开了 swap，操作系统发现物理内存占满后，并没有立即释放 cache，导致每次 GC 都要和硬盘打一次交道。
解决方式就是关闭 SWAP 分区。
swap 是很多性能场景的万恶之源，建议禁用。在高并发 SWAP 绝对能让你体验到它魔鬼性的一面：进程倒是死不了了，但 GC 时间长的却让人无法忍受。
5、内存溢出 | Cache调优
有一次线上遇到故障，重新启动后，使用 jstat 命令，发现 Old 区一直在增长。我使用 jmap 命令，导出了一份线上堆栈，然后使用 MAT 进行分析，通过对 GC Roots 的分析，发现了一个非常大的 HashMap 对象，这个原本是其他同事做缓存用的，但是做了一个无界缓存，没有设置超时时间或者 LRU 策略，在使用上又没有重写key类对象的hashcode和equals方法，对象无法取出也直接造成了堆内存占用一直上升，后来，将这个缓存改成 guava 的 Cache，并设置了弱引用，故障就消失了。
关于文件处理器的应用，在读取或者写入一些文件之后，由于发生了一些异常，close 方法又没有放在 finally 块里面，造成了文件句柄的泄漏。由于文件处理十分频繁，产生了严重的内存泄漏问题。
内存溢出是一个结果，而内存泄漏是一个原因。内存溢出的原因有内存空间不足、配置错误等因素。一些错误的编程方式，不再被使用的对象、没有被回收、没有及时切断与 GC Roots 的联系，这就是内存泄漏。
举个例子，有团队使用了 HashMap 做缓存，但是并没有设置超时时间或者 LRU 策略，造成了放入 Map 对象的数据越来越多，而产生了内存泄漏。
再来看一个经常发生的内存泄漏的例子，也是由于 HashMap 产生的。代码如下，由于没有重写 Key 类的 hashCode 和 equals 方法，造成了放入 HashMap 的所有对象都无法被取出来，它们和外界失联了。所以下面的代码结果是 null。
//leak exampleimport java.util.HashMap;import java.util.Map;public class HashMapLeakDemo { public static class Key { String title; public Key(String title) { this.title = title; }}public static void main(String[] args) { Map<Key, Integer> map = new HashMap<>(); map.put(new Key("1"), 1); map.put(new Key("2"), 2); map.put(new Key("3"), 2); Integer integer = map.get(new Key("2")); System.out.println(integer); }}
即使提供了 equals 方法和 hashCode 方法，也要非常小心，尽量避免使用自定义的对象作为 Key。
再看一个例子，关于文件处理器的应用，在读取或者写入一些文件之后，由于发生了一些异常，close 方法又没有放在 finally 块里面，造成了文件句柄的泄漏。由于文件处理十分频繁，产生了严重的内存泄漏问题。
6：CPU飙高 | 死循环
我们有个线上应用，单节点在运行一段时间后，CPU 的使用会飙升，一旦飙升，一般怀疑某个业务逻辑的计算量太大，或者是触发了死循环（比如著名的 HashMap 高并发引起的死循环），但排查到最后其实是 GC 的问题。
（1）使用 top 命令，查找到使用 CPU 最多的某个进程，记录它的 pid。使用 Shift + P 快捷键可以按 CPU 的使用率进行排序。
top
（2）再次使用 top 命令，加 -H 参数，查看某个进程中使用 CPU 最多的某个线程，记录线程的 ID。
top -Hp $pid
（3）使用 printf 函数，将十进制的 tid 转化成十六进制。
printf %x $tid
（4）使用 jstack 命令，查看 Java 进程的线程栈。
jstack $pid >$pid.log
（5）使用 less 命令查看生成的文件，并查找刚才转化的十六进制 tid，找到发生问题的线程上下文。
less $pid.log
我们在 jstack 日志搜关键字DEAD，以及中找到了 CPU 使用最多的几个线程id。
可以看到问题发生的根源，是我们的堆已经满了，但是又没有发生 OOM，于是 GC 进程就一直在那里回收，回收的效果又非常一般，造成 CPU 升高应用假死。接下来的具体问题排查，就需要把内存 dump 一份下来，使用 MAT 等工具分析具体原因了。
1、线程状态
线程是cpu任务调度的最小执行单位，每个线程拥有自己独立的程序计数器、虚拟机栈、本地方法栈
线程状态：创建、就绪、运行、阻塞、死亡
2、线程状态切换
| 方法 |
作用 |
区别 |
| start |
启动线程，由虚拟机自动调度执行run()方法 |
线程处于就绪状态 |
| run |
线程逻辑代码块处理，JVM调度执行 |
线程处于运行状态 |
| sleep |
让当前正在执行的线程休眠（暂停执行） |
不释放锁 |
| wait |
使得当前线程等待 |
释放同步锁 |
| notify |
唤醒在此对象监视器上等待的单个线程 |
唤醒单个线程 |
| notifyAll |
唤醒在此对象监视器上等待的所有线程 |
唤醒多个线程 |
| yiled |
停止当前线程，让同等优先权的线程运行 |
用Thread类调用 |
| join |
使当前线程停下来等待，直至另一个调用join方法的线程终止 |
用线程对象调用 |
3、阻塞唤醒过程
阻塞：
这三个方法的调用都会使当前线程阻塞。该线程将会被放置到对该Object的请求等待队列中，然后让出当前对Object所拥有的所有的同步请求。线程会一直暂停所有线程调度，直到下面其中一种情况发生：
① 其他线程调用了该Object的notify方法，而该线程刚好是那个被唤醒的线程；
② 其他线程调用了该Object的notifyAll方法；
唤醒：
线程将会从等待队列中移除，重新成为可调度线程。它会与其他线程以常规的方式竞争对象同步请求。一旦它重新获得对象的同步请求，所有之前的请求状态都会恢复，也就是线程调用wait的地方的状态。线程将会在之前调用wait的地方继续运行下去。
为什么要出现在同步代码块中：
由于wait()属于Object方法，调用之后会强制释放当前对象锁，所以在wait() 调用时必须拿到当前对象的监视器monitor对象。因此，wait()方法在同步方法/代码块中调用。
4、wait和sleep区别
5、创建线程方式
实现 Runnable 接口（优先使用）
public class RunnableThread implements Runnable { @Override public void run() {System.out.println('用实现Runnable接口实现线程');}}
实现Callable接口（有返回值可抛出异常）
class CallableTask implements Callable<Integer> { @Override public Integer call() throws Exception { return new Random().nextInt();}}
继承Thread类（java不支持多继承）
public class ExtendsThread extends Thread { @Override public void run() {System.out.println('用Thread类实现线程');}}
使用线程池（底层都是实现run方法）
static class DefaultThreadFactory implements ThreadFactory { DefaultThreadFactory() { SecurityManager s = System.getSecurityManager(); group = (s != null) ? s.getThreadGroup() : Thread.currentThread().getThreadGroup(); namePrefix = "pool-" + poolNumber.getAndIncrement() +"-thread-"; } public Thread newThread(Runnable r) { Thread t = new Thread(group, r,namePrefix + threadNumber.getAndIncrement(),0); if (t.isDaemon()) t.setDaemon(false); //是否守护线程 if (t.getPriority() != Thread.NORM_PRIORITY) t.setPriority(Thread.NORM_PRIORITY); //线程优先级 return t; }}
优点：通过复用已创建的线程，降低资源损耗、线程可以直接处理队列中的任务加快响应速度、同时便于统一监控和管理。
1、线程池构造函数
/*** 线程池构造函数7大参数*/public ThreadPoolExecutor(int corePoolSize,int maximumPoolSize,long keepAliveTime, TimeUnit unit,BlockingQueue<Runnable> workQueue,ThreadFactory threadFactory, RejectedExecutionHandler handler) {}
参数介绍：
| 参数 |
作用 |
| corePoolSize |
核心线程池大小 |
| maximumPoolSize |
最大线程池大小 |
| keepAliveTime |
线程池中超过 corePoolSize 数目的空闲线程最大存活时间； |
| TimeUnit |
keepAliveTime 时间单位 |
| workQueue |
阻塞任务队列 |
| threadFactory |
新建线程工厂 |
| RejectedExecutionHandler |
拒绝策略。当提交任务数超过 maxmumPoolSize+workQueue 之和时，任务会交给RejectedExecutionHandler 来处理 |
2、线程处理任务过程：
3、线程拒绝策略
线程池中的线程已经用完了，无法继续为新任务服务，同时，等待队列也已经排满了，再也塞不下新任务了。这时候我们就需要拒绝策略机制合理的处理这个问题。
JDK 内置的拒绝策略如下：
AbortPolicy：直接抛出异常，阻止系统正常运行。可以根据业务逻辑选择重试或者放弃提交等策略。
CallerRunsPolicy ：只要线程池未关闭，该策略直接在调用者线程中，运行当前被丢弃的任务。
不会造成任务丢失，同时减缓提交任务的速度，给执行任务缓冲时间。
DiscardOldestPolicy ：丢弃最老的一个请求，也就是即将被执行的任务，并尝试再次提交当前任务。
DiscardPolicy ：该策略默默地丢弃无法处理的任务，不予任何处理。如果允许任务丢失，这是最好的一种方案。
4、Execuors类实现线程池
因为以上方式都存在弊端：
FixedThreadPool 和 SingleThreadExecutor ： 允许请求的队列⻓度为 Integer.MAX_VALUE，会导致OOM。
CachedThreadPool 和 ScheduledThreadPool ： 允许创建的线程数量为 Integer.MAX_VALUE，会导致OOM。
手动创建的线程池底层使用的是ArrayBlockingQueue可以防止OOM。
5、线程池大小设置
CPU 密集的意思是该任务需要大量的运算，而没有阻塞，CPU 一直全速运行。
CPU 密集型任务尽可能的少的线程数量，一般为 CPU 核数 + 1 个线程的线程池。
由于 IO 密集型任务线程并不是一直在执行任务，可以多分配一点线程数，如 CPU * 2
也可以使用公式：CPU 核心数 *（1+平均等待时间/平均工作时间）。
1、乐观锁，CAS思想
java乐观锁机制：
乐观锁体现的是悲观锁的反面。它是一种积极的思想，它总是认为数据是不会被修改的，所以是不会对数据上锁的。但是乐观锁在更新的时候会去判断数据是否被更新过。乐观锁的实现方案一般有两种（版本号机制和CAS）。乐观锁适用于读多写少的场景，这样可以提高系统的并发量。在Java中 java.util.concurrent.atomic下的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
乐观锁，大多是基于数据版本 (Version)记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来 实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提 交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
CAS思想：
CAS就是compare and swap（比较交换），是一种很出名的无锁的算法，就是可以不使用锁机制实现线程间的同步。使用CAS线程是不会被阻塞的，所以又称为非阻塞同步。CAS算法涉及到三个操作：
需要读写内存值V；进行比较的值A；准备写入的值B
当且仅当V的值等于A的值等于V的值的时候，才用B的值去更新V的值，否则不会执行任何操作（比较和替换是一个原子操作-A和V比较，V和B替换），一般情况下是一个自旋操作，即不断重试
缺点：
高并发的情况下，很容易发生并发冲突，如果CAS一直失败，那么就会一直重试，浪费CPU资源
原子性：
功能限制CAS是能保证单个变量的操作是原子性的，在Java中要配合使用volatile关键字来保证线程的安全；当涉及到多个变量的时候CAS无能为力；除此之外CAS实现需要硬件层面的支持，在Java的普通用户中无法直接使用，只能借助atomic包下的原子类实现，灵活性受到了限制
2、synchronized底层实现
使用方法：主要的三种使⽤⽅式
修饰实例⽅法: 作⽤于当前对象实例加锁，进⼊同步代码前要获得当前对象实例的锁
修饰静态⽅法: 也就是给当前类加锁，会作⽤于类的所有对象实例，因为静态成员不属于任何⼀个实例对象，是类成员。
修饰代码块: 指定加锁对象，对给定对象加锁，进⼊同步代码库前要获得给定对象的锁。
总结：synchronized锁住的资源只有两类：一个是对象，一个是类。
底层实现：
对象头是我们需要关注的重点，它是synchronized实现锁的基础，因为synchronized申请锁、上锁、释放锁都与对象头有关。对象头主要结构是由Mark Word 组成，其中Mark Word存储对象的hashCode、锁信息或分代年龄或GC标志等信息。
锁也分不同状态，JDK6之前只有两个状态：无锁、有锁（重量级锁），而在JDK6之后对synchronized进行了优化，新增了两种状态，总共就是四个状态：无锁状态、偏向锁、轻量级锁、重量级锁，其中无锁就是一种状态了。锁的类型和状态在对象头Mark Word中都有记录，在申请锁、锁升级等过程中JVM都需要读取对象的Mark Word数据。
同步代码块是利用 monitorenter 和 monitorexit 指令实现的，而同步方法则是利用 flags 实现的。
3、ReenTrantLock底层实现
由于ReentrantLock是java.util.concurrent包下提供的一套互斥锁，相比Synchronized，ReentrantLock类提供了一些高级功能
使用方法：
基于API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成
底层实现：
ReenTrantLock的实现是一种自旋锁，通过循环调用CAS操作来实现加锁。它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。
和synchronized区别：
1、底层实现：synchronized 是JVM层面的锁，是Java关键字，通过monitor对象来完成（monitorenter与monitorexit），ReentrantLock 是从jdk1.5以来（java.util.concurrent.locks.Lock）提供的API层面的锁。
2、实现原理****：synchronized 的实现涉及到锁的升级，具体为无锁、偏向锁、自旋锁、向OS申请重量级锁；ReentrantLock实现则是通过利用CAS**（CompareAndSwap）自旋机制保证线程操作的原子性和volatile保证数据可见性以实现锁的功能。
3、是否可手动释放：synchronized 不需要用户去手动释放锁，synchronized 代码执行完后系统会自动让线程释放对锁的占用； ReentrantLock则需要用户去手动释放锁，如果没有手动释放锁，就可能导致死锁现象。
4、是否可中断synchronized是不可中断类型的锁，除非加锁的代码中出现异常或正常执行完成； ReentrantLock则可以中断，可通过trylock(long timeout,TimeUnit unit)设置超时方法或者将lockInterruptibly()放到代码块中，调用interrupt方法进行中断。
5、是否公平锁synchronized为非公平锁 ReentrantLock则即可以选公平锁也可以选非公平锁，通过构造方法new ReentrantLock时传入boolean值进行选择，为空默认false非公平锁，true为公平锁,公平锁性能非常低。
4、公平锁和非公平锁区别
公平锁：
公平锁自然是遵循FIFO（先进先出）原则的，先到的线程会优先获取资源，后到的会进行排队等待
优点：所有的线程都能得到资源，不会饿死在队列中。适合大任务
缺点：吞吐量会下降，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销大
非公平锁：
多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。
优点：可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。
缺点：你们可能也发现了，这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁
公平锁效率低原因：
公平锁要维护一个队列，后来的线程要加锁，即使锁空闲，也要先检查有没有其他线程在 wait，如果有自己要挂起，加到队列后面，然后唤醒队列最前面线程。这种情况下相比较非公平锁多了一次挂起和唤醒。
线程切换的开销，其实就是非公平锁效率高于公平锁的原因，因为非公平锁减少了线程挂起的几率，后来的线程有一定几率逃离被挂起的开销。
5、使用层面锁优化
【1】减少锁的时间：
不需要同步执行的代码，能不放在同步快里面执行就不要放在同步快内，可以让锁尽快释放；
【2】减少锁的粒度：
它的思想是将物理上的一个锁，拆成逻辑上的多个锁，增加并行度，从而降低锁竞争。它的思想也是用空间来换时间；java中很多数据结构都是采用这种方法提高并发操作的效率，比如：
ConcurrentHashMap：
java中的ConcurrentHashMap在jdk1.8之前的版本，使用一个Segment 数组：Segment< K,V >[] segments
Segment继承自ReenTrantLock，所以每个Segment是个可重入锁，每个Segment 有一个HashEntry< K,V >数组用来存放数据，put操作时，先确定往哪个Segment放数据，只需要锁定这个Segment，执行put，其它的Segment不会被锁定；所以数组中有多少个Segment就允许同一时刻多少个线程存放数据，这样增加了并发能力。
【3】锁粗化：
大部分情况下我们是要让锁的粒度最小化，锁的粗化则是要增大锁的粒度;
假如有一个循环，循环内的操作需要加锁，我们应该把锁放到循环外面，否则每次进出循环，都进出一次临界区，效率是非常差的；
【4】使用读写锁：
ReentrantReadWriteLock 是一个读写锁，读操作加读锁，可并发读，写操作使用写锁，只能单线程写；
【5】使用CAS：
如果需要同步的操作执行速度非常快，并且线程竞争并不激烈，这时候使用cas效率会更高，因为加锁会导致线程的上下文切换，如果上下文切换的耗时比同步操作本身更耗时，且线程对资源的竞争不激烈，使用volatiled+cas操作会是非常高效的选择；
6、系统层面锁优化
自适应自旋锁：
自旋锁可以避免等待竞争锁进入阻塞挂起状态被唤醒造成的内核态和用户态之间的切换的损耗，它们只需要等一等（自旋），但是如果锁被其他线程长时间占用，一直不释放CPU，死等会带来更多的性能开销；自旋次数默认值是10
对上面自旋锁优化方式的进一步优化，它的自旋的次数不再固定，其自旋的次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，这就解决了自旋锁带来的缺点
锁消除：
锁削除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。Netty中无锁化设计pipeline中channelhandler会进行锁消除的优化。
锁升级：
偏向锁：
如果线程已经占有这个锁，当他在次试图去获取这个锁的时候，他会已最快的方式去拿到这个锁，而不需要在进行一些monitor操作，因为在大部分情况下是没有竞争的，所以使用偏向锁是可以提高性能的；
轻量级锁：
在竞争不激烈的情况下，通过CAS避免线程上下文切换，可以显著的提高性能。
重量级锁：
重量级锁的加锁、解锁过程造成的损耗是固定的，重量级锁适合于竞争激烈、高并发、同步块执行时间长的情况。
7、ThreadLocal原理
ThreadLocal简介：
通常情况下，我们创建的变量是可以被任何⼀个线程访问并修改的。如果想实现每⼀个线程都有⾃⼰的
专属本地变量该如何解决呢？ JDK中提供的 ThreadLocal 类正是为了解决这样的问题。类似操作系统中的TLAB
原理：
首先 ThreadLocal 是一个泛型类，保证可以接受任何类型的对象。因为一个线程内可以存在多个 ThreadLocal 对象，所以其实是 ThreadLocal 内部维护了一个 Map ，是 ThreadLocal 实现的一个叫做 ThreadLocalMap 的静态内部类。
最终的变量是放在了当前线程的 ThreadLocalMap 中，并不是存在 ThreadLocal 上，ThreadLocal 可以理解为只是ThreadLocalMap的封装，传递了变量值。
我们使用的 get()、set() 方法其实都是调用了这个ThreadLocalMap类对应的 get()、set() 方法。例如下面的
如何使用：
1）存储用户Session
private static final ThreadLocal threadSession = new ThreadLocal();
2）解决线程安全的问题
private static ThreadLocal<SimpleDateFormat> format1 = new ThreadLocal<SimpleDateFormat>()
ThreadLocal内存泄漏的场景
实际上 ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用，⽽ value 是强引⽤。弱引用的特点是，如果这个对象持有弱引用，那么在下一次垃圾回收的时候必然会被清理掉。
所以如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候会被清理掉的，这样一来 ThreadLocalMap中使用这个 ThreadLocal 的 key 也会被清理掉。但是，value 是强引用，不会被清理，这样一来就会出现 key 为 null 的 value。 假如我们不做任何措施的话，value 永远⽆法被GC 回收，如果线程长时间不被销毁，可能会产⽣内存泄露。
ThreadLocalMap实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。如果说会出现内存泄漏，那只有在出现了 key 为 null 的记录后，没有手动调用 remove() 方法，并且之后也不再调用 get()、set()、remove() 方法的情况下。因此使⽤完ThreadLocal ⽅法后，最好⼿动调⽤ remove() ⽅法。
8、HashMap线程安全
死循环造成 CPU 100%
HashMap 有可能会发生死循环并且造成 CPU 100% ，这种情况发生最主要的原因就是在扩容的时候，也就是内部新建新的 HashMap 的时候，扩容的逻辑会反转散列桶中的节点顺序，当有多个线程同时进行扩容的时候，由于 HashMap 并非线程安全的，所以如果两个线程同时反转的话，便可能形成一个循环，并且这种循环是链表的循环，相当于 A 节点指向 B 节点，B 节点又指回到 A 节点，这样一来，在下一次想要获取该 key 所对应的 value 的时候，便会在遍历链表的时候发生永远无法遍历结束的情况，也就发生 CPU 100% 的情况。
所以综上所述，HashMap 是线程不安全的，在多线程使用场景中推荐使用线程安全同时性能比较好的 ConcurrentHashMap。
9、String不可变原因
Java 内存模型（Java Memory Model，JMM）就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了 Java 程序在各种平台下对内存的访问都能保证效果一致的机制及规范。
JMM 是一种规范，是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。目的是保证并发编程场景中的原子性、可见性和有序性。
原子性：
在 Java 中，为了保证原子性，提供了两个高级的字节码指令 Monitorenter 和 Monitorexit。这两个字节码，在 Java 中对应的关键字就是 Synchronized。因此，在 Java 中可以使用 Synchronized 来保证方法和代码块内的操作是原子性的。
可见性：
Java 中的 Volatile 关键字修饰的变量在被修改后可以立即同步到主内存。被其修饰的变量在每次使用之前都从主内存刷新。因此，可以使用 Volatile 来保证多线程操作时变量的可见性。除了 Volatile，Java 中的 Synchronized 和 Final 两个关键字也可以实现可见性。只不过实现方式不同
有序性
在 Java 中，可以使用 Synchronized 和 Volatile 来保证多线程之间操作的有序性。区别：Volatile 禁止指令重排。Synchronized 保证同一时刻只允许一条线程操作。
1、volatile底层实现
作用：
保证数据的“可见性”：被volatile修饰的变量能够保证每个线程能够获取该变量的最新值，从而避免出现数据脏读的现象。
禁止指令重排：在多线程操作情况下，指令重排会导致计算结果不一致
底层实现：
“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”
lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：
1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；
2）它会强制将对缓存的修改操作立即写入主存；
3）如果是写操作，它会导致其他CPU中对应的缓存行无效。
单例模式中volatile的作用：
防止代码读取到instance不为null时，instance引用的对象有可能还没有完成初始化。
class Singleton{ private volatile static Singleton instance = null; //禁止指令重排 private Singleton() { } public static Singleton getInstance() { if(instance==null) { //减少加锁的损耗 synchronized (Singleton.class) { if(instance==null) //确认是否初始化完成 instance = new Singleton(); } } return instance; }}
2、AQS思想
AQS的全称为（AbstractQueuedSynchronizer）抽象的队列式的同步器，是⼀个⽤来构建锁和同步器的框架，使⽤AQS能简单且⾼效地构造出应⽤⼴泛的⼤量的同步器，如：基于AQS实现的lock, CountDownLatch、CyclicBarrier、Semaphore需解决的问题：
状态的原子性管理线程的阻塞与解除阻塞队列的管理
AQS核⼼思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的⼯作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占⽤，那么就需要⼀套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是⽤CLH（虚拟的双向队列）队列锁实现的，即将暂时获取不到锁的线程加⼊到队列中。
lock：
是一种可重入锁，除了能完成 synchronized 所能完成的所有工作外，还提供了诸如可响应中断锁、可轮询锁请求、定时锁等避免多线程死锁的方法。默认为非公平锁，但可以初始化为公平锁； 通过方法 lock()与 unlock()来进行加锁与解锁操作；
CountDownLatch：
通过计数法（倒计时器），让一些线程堵塞直到另一个线程完成一系列操作后才被唤醒；该⼯具通常⽤来控制线程等待，它可以让某⼀个线程等待直到倒计时结束，再开始执⾏。具体可以使用countDownLatch.await()来等待结果。多用于多线程信息汇总。
CompletableFuture：
通过设置参数，可以完成CountDownLatch同样的多平台响应问题，但是可以针对其中部分返回结果做更加灵活的展示。
CyclicBarrier：
字面意思是可循环(Cyclic)使用的屏障（Barrier）。他要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活，线程进入屏障通过CyclicBarrier的await()方法。可以用于批量发送消息队列信息、异步限流。
Semaphore：
信号量主要用于两个目的，一个是用于多个共享资源的互斥作用，另一个用于并发线程数的控制。SpringHystrix限流的思想
3、happens-before
用来描述和可见性相关问题：如果第一个操作 happens-before 第二个操作，那么我们就说第一个操作对于第二个操作是可见的
常见的happens-before：volatile 、锁、线程生命周期。
NoSQL数据库四大家族
云存储OSS
海量Aerospike
Aerospike（简称AS）是一个分布式，可扩展的键值存储的NoSQL数据库。T级别大数据高并发的结构化数据存储，采用混合架构，索引存储在内存中，而数据可存储在机械硬盘(HDD)或固态硬盘(SSD) 上，读写操作达微妙级，99%的响应可在1毫秒内实现。
| Aerospike |
Redis |
|
| 类型 |
Nosql数据库 |
缓存 |
| 线程数 |
多线程 |
单线程 |
| 数据分片 |
自动处理相当于分片 |
提供分片算法、平衡各分片数据 |
| 数据扩容 |
动态增加数据卷平衡流量 |
需停机 |
| 数据同步 |
设置复制因子后可以透明的完成故障转移 |
手动故障转移和数据同步 |
| 载体 |
内存存储索引+SSD存储数据 |
内存 |
Aerospike作为一个大容量的NoSql解决方案，适合对容量要求比较大，QPS相对低一些的场景，主要用在广告行业，个性化推荐厂告是建立在了和掌握消费者独特的偏好和习性的基础之上，对消费者的购买需求做出准确的预测或引导，在合适的位置、合适的时间，以合适的形式向消费者呈现与其需求高度吻合的广告，以此来促进用户的消费行为。
（ETL数据仓库技术）抽取（extract）、转换（transform）、加载（load）
| Aerospike |
Mysql |
|
| 库名 |
Namespace |
Database |
| 表名 |
Set |
Table |
| 记录 |
Bin |
Column |
| 字段 |
Record |
Row |
| 索引 |
key 、 pk 、kv |
pk |
图谱Neo4j
Neo4j是一个开源基于java开发的图形noSql数据库，它将结构化数据存储在图中而不是表中。它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎。程序数据是在一个面向对象的、灵活的网络结构下，而不是严格的表中，但具备完全的事务特性、企业级的数据库的所有好处。
一种基于图的数据结构，由节点(Node)和边(Edge)组成。其中节点即实体，由一个全局唯一的ID标示，边就是关系用于连接两个节点。通俗地讲，知识图谱就是把所有不同种类的信息，连接在一起而得到的一个关系网络。知识图谱提供了从“关系”的角度去分析问题的能力。
互联网、大数据的背景下，谷歌、百度、搜狗等搜索引擎纷纷基于该背景，创建自己的知识图Knowledge Graph（谷歌）、知心（百度）和知立方（搜狗），主要用于改进搜索质量。
自己项目主要用作好友推荐，图数据库(Graph database)指的是以图数据结构的形式来存储和查询数据的数据库。关系图谱中，关系的组织形式采用的就是图结构，所以非常适合用图库进行存储。
// 查询三层级关系节点如下：with可以将前面查询结果作为后面查询条件match (na:Person)-[re]-(nb:Person) where na.name="林婉儿" WITH na,re,nb match (nb:Person)- [re2:Friends]->(nc:Person) return na,re,nb,re2,nc// 直接拼接关系节点查询match data=(na:Person{name:"范闲"})-[re]->(nb:Person)-[re2]->(nc:Person) return data// 使用深度运算符显然使用以上方式比较繁琐,可变数量的关系->节点可以使用-[:TYPE*minHops..maxHops]-。match data=(na:Person{name:"范闲"})-[*1..2]-(nb:Person) return data
文档MongoDB
MongoDB 是一个基于分布式文件存储的数据库，是非关系数据库中功能最丰富、最像关系数据库的。在高负载的情况下，通过添加更多的节点，可以保证服务器性能。由 C++ 编写，可以为 WEB 应用提供可扩展、高性能、易部署的数据存储解决方案。
什么是BSON
{key:value,key2:value2}和Json类似，是一种二进制形式的存储格式，支持内嵌的文档对象和数组对象，但是BSON有JSON没有的一些数据类型，比如 value包括字符串,double,Array,DateBSON可以做为网络数据交换的一种存储形式,它的优点是灵活性高，但它的缺点是空间利用率不是很理想。
BSON有三个特点：轻量性、可遍历性、高效性
/* 查询 find() 方法可以传入多个键(key)，每个键(key)以逗号隔开*/db.collection.find({key1:value1, key2:value2}).pretty()/* 更新 $set ：设置字段值 $unset :删除指定字段 $inc：对修改的值进行自增*/db.collection.update({where},{$set:{字段名:值}},{multi:true})/* 删除 justOne :如果设为true，只删除一个文档，默认false，删除所有匹配条件的文档*/db.collection.remove({where}, {justOne: <boolean>, writeConcern: <回执> } )
优点：
缺点：
MySQL 8.0 版本
1. 性能：MySQL 8.0 的速度要比 MySQL 5.7 快 2 倍。
2. NoSQL：MySQL 从 5.7 版本开始提供 NoSQL 存储功能，在 8.0 版本中nosql得到了更大的改进。
3. 窗口函数：实现若干新的查询方式。窗口函数与 SUM()、COUNT() 这种集合函数类似，但它不会将多行查询结果合并为一行，而是将结果放回多行当中，即窗口函数不需要 GROUP BY。
4. 隐藏索引：在 MySQL 8.0 中，索引可以被“隐藏”和“显示”。当对索引进行隐藏时，它不会被查询优化器所使用。我们可以使用这个特性用于性能调试，例如我们先隐藏一个索引，然后观察其对数据库的影响。如果数据库性能有所下降，说明这个索引是有用的，然后将其“恢复显示”即可；如果数据库性能看不出变化，说明这个索引是多余的，可以考虑删掉。
云存储
| OSS |
自建 |
|
| 可靠性 |
可用性不低于99.995% |
受限于硬件可靠性，易出问题，一旦出现磁盘坏道，容易出现不可逆转的数据丢失。人工数据恢复困难、耗时、耗力。 |
| 安全 |
服务端加密、客户端加密、防盗链、IP黑白名单等。多用户资源隔离机制，支持异地容灾机制。 |
需要另外购买清洗和黑洞设备。需要单独实现安全机制。 |
| 成本 |
多线BGP骨干网络，无带宽限制，上行流量免费。无需运维人员与托管费用，0成本运维。 |
单线或双线接入速度慢，有带宽限制，峰值时期需人工扩容。需专人运维，成本高。 |
使用步骤
1、开通服务
2、创建存储空间
3、上传文件、下载文件、删除文件
4、域名绑定、日志记录
5、根据开放接口进行鉴权访问
功能
图片编辑（裁剪、模糊、水印）
视频截图
音频转码、视频修复
CDN加速
对象存储OSS与阿里云CDN服务结合，可优化静态热点文件下载加速的场景（即同一地区大量用户同时下载同一个静态文件的场景）。可以将OSS的存储空间（Bucket）作为源站，利用阿里云CDN将源内容发布到边缘节点。当大量终端用户重复访问同一文件时，可以直接从边缘节点获取已缓存的数据，提高访问的响应速度
FastDFS
开源的轻量级分布式文件系统。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。如相册网站、视频网站等
扩展能力: 支持水平扩展，可以动态扩容；
高可用性: 一是整个文件系统的可用性，二是数据的完整和一致性；
弹性存储: 可以根据业务需要灵活地增删存储池中的资源，而不需要中断系统运行。
特性
组成
上传
下载
断点续传
续传涉及到的文件大小MD5不会改变。续传流程与文件上传类似，先定位到源storage，完成完整或部分上传，再通过binlog进行同group内server文件同步。
配置优化
配置文件：tracker.conf 和 storage.conf
// FastDFS采用内存池的做法。 // v5.04对预分配采用增量方式，tracker一次预分配 1024个，storage一次预分配256个。 max_connections = 10240// 根据实际需要将 max_connections 设置为一个较大的数值，比如 10240 甚至更大。// 同时需要将一个进程允许打开的最大文件数调大vi /etc/security/limits.conf 重启系统生效 * soft nofile 65535 * hard nofile 65535
work_threads = 4 // 说明：为了避免CPU上下文切换的开销，以及不必要的资源消耗，不建议将本参数设置得过大。// 公式为： work_threads + (reader_threads + writer_threads) = CPU数
// 对于单盘挂载方式，磁盘读写线程分 别设置为 1即可 // 如果磁盘做了RAID，那么需要酌情加大读写线程数，这样才能最大程度地发挥磁盘性能disk_rw_separated：磁盘读写是否分离 disk_reader_threads：单个磁盘读线程数 disk_writer_threads：单个磁盘写线程数
避免重复
如何避免文件重复上传 解决方案 上传成功后计算文件对应的MD5然后存入MySQL,添加文件时把文件MD5和之前存入MYSQL中的存储的信息对比 。DigestUtils.md5DigestAsHex(bytes)。
1、事务4大特性
事务4大特性：原子性、一致性、隔离性、持久性
原⼦性： 事务是最⼩的执⾏单位，不允许分割。事务的原⼦性确保动作要么全部完成，要么全不执行
一致性： 执⾏事务前后，数据保持⼀致，多个事务对同⼀个数据读取的结果是相同的；
隔离性： 并发访问数据库时，⼀个⽤户的事务不被其他事务所⼲扰，各并发事务之间数据库是独⽴的；
持久性： ⼀个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发⽣故障也不应该对其有任何影响。
实现保证：
MySQL的存储引擎InnoDB使用重做日志保证一致性与持久性，回滚日志保证原子性，使用各种锁来保证隔离性。
2、事务隔离级别
读未提交：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
读已提交：允许读取并发事务已经提交的数据，可以阻⽌脏读，但是幻读或不可重复读仍有可能发⽣。
可重复读：同⼀字段的多次读取结果都是⼀致的，除⾮数据是被本身事务⾃⼰所修改，可以阻⽌脏读和不可重复读，会有幻读。
串行化：最⾼的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执⾏，这样事务之间就完全不可能产⽣⼲扰。
| 隔离级别 |
并发问题 |
| 读未提交 |
可能会导致脏读、幻读或不可重复读 |
| 读已提交 |
可能会导致幻读或不可重复读 |
| 可重复读 |
可能会导致幻读 |
| 可串行化 |
不会产⽣⼲扰 |
3、默认隔离级别-RR
默认隔离级别：可重复读；
同⼀字段的多次读取结果都是⼀致的，除⾮数据是被本身事务⾃⼰所修改；
可重复读是有可能出现幻读的，如果要保证绝对的安全只能把隔离级别设置成SERIALIZABLE；这样所有事务都只能顺序执行，自然不会因为并发有什么影响了，但是性能会下降许多。
第二种方式，使用MVCC解决快照读幻读问题（如简单select），读取的不是最新的数据。维护一个字段作为version，这样可以控制到每次只能有一个人更新一个版本。
select id from table_xx where id = ? and version = Vupdate id from table_xx where id = ? and version = V+1
第三种方式，如果需要读最新的数据，可以通过GapLock+Next-KeyLock可以解决当前读幻读问题，
select id from table_xx where id > 100 for update;select id from table_xx where id > 100 lock in share mode;
4、RR和RC使用场景
事务隔离级别RC(read commit)和RR（repeatable read）两种事务隔离级别基于多版本并发控制MVCC(multi-version concurrency control）来实现。
| RC |
RR |
|
| 实现 |
多条查询语句会创建多个不同的ReadView |
仅需要一个版本的ReadView |
| 粒度 |
语句级读一致性 |
事务级读一致性 |
| 准确性 |
每次语句执行时间点的数据 |
第一条语句执行时间点的数据 |
5、行锁，表锁，意向锁
InnoDB⽀持⾏级锁(row-level locking)和表级锁,默认为⾏级锁
InnoDB按照不同的分类的锁：
共享/排它锁(Shared and Exclusive Locks)：行级别锁，
意向锁(Intention Locks)，表级别锁
间隙锁(Gap Locks)，锁定一个区间
记录锁(Record Locks)，锁定一个行记录
表级锁：（串行化）
Mysql中锁定 粒度最大的一种锁，对当前操作的整张表加锁，实现简单 ，资源消耗也比较少，加锁快，不会出现死锁 。其锁定粒度最大，触发锁冲突的概率最高，并发度最低，MyISAM和 InnoDB引擎都支持表级锁。
行级锁：（RR、RC）
Mysql中锁定 粒度最小 的一种锁，只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。 InnoDB支持的行级锁，包括如下几种：
记录锁（Record Lock）: 对索引项加锁，锁定符合条件的行。其他事务不能修改和删除加锁项；
间隙锁（Gap Lock）: 对索引项之间的“间隙”加锁，锁定记录的范围，不包含索引项本身，其他事务不能在锁范围内插入数据。
Next-key Lock： 锁定索引项本身和索引范围。即Record Lock和Gap Lock的结合。可解决幻读问题。
InnoDB 支持多粒度锁（multiple granularity locking），它允许行级锁与表级锁共存，而意向锁就是其中的一种表锁。
共享锁（ shared lock, S ）锁允许持有锁读取行的事务。加锁时将自己和子节点全加S锁，父节点直到表头全加IS锁
排他锁（ exclusive lock， X ）锁允许持有锁修改行的事务。 加锁时将自己和子节点全加X锁，父节点直到表头全加IX锁
意向共享锁（intention shared lock, IS）：事务有意向对表中的某些行加共享锁（S锁）
意向排他锁（intention exclusive lock, IX）：事务有意向对表中的某些行加排他锁（X锁）
| 互斥性 |
共享锁（S） |
排它锁（X） |
意向共享锁IS |
意向排他锁IX |
| 共享锁（S） |
✅ |
❌ |
✅ |
❌ |
| 排它锁（X） |
❌ |
❌ |
❌ |
❌ |
| 意向共享锁IS |
✅ |
❌ |
✅ |
✅ |
| 意向排他锁IX |
❌ |
❌ |
✅ |
✅ |
6、MVCC多版本并发控制
MVCC是一种多版本并发控制机制，通过事务的可见性看到自己预期的数据，能降低其系统开销.（RC和RR级别工作）
InnoDB的MVCC,是通过在每行记录后面保存系统版本号(可以理解为事务的ID)，每开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID。这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的，防止幻读的产生。
1.MVCC手段只适用于Msyql隔离级别中的读已提交（Read committed）和可重复读（Repeatable Read）.
2.Read uncimmitted由于存在脏读，即能读到未提交事务的数据行，所以不适用MVCC.
3.简单的select快照度不会加锁，删改及select for update等需要当前读的场景会加锁
原因是MVCC的创建版本和删除版本只要在事务提交后才会产生。客观上，mysql使用的是乐观锁的一整实现方式，就是每行都有版本号，保存时根据版本号决定是否成功。Innodb的MVCC使用到的快照存储在Undo日志中，该日志通过回滚指针把一个数据行所有快照连接起来。
版本链
在InnoDB引擎表中，它的聚簇索引记录中有两个必要的隐藏列：
trx_id
这个id用来存储的每次对某条聚簇索引记录进行修改的时候的事务id。
roll_pointer
每次对哪条聚簇索引记录有修改的时候，都会把老版本写入undo日志中。这个roll_pointer就是存了一个指针，它指向这条聚簇索引记录的上一个版本的位置，通过它来获得上一个版本的记录信息。(注意插入操作的undo日志没有这个属性，因为它没有老版本)
每次修改都会在版本链中记录。SELECT可以去版本链中拿记录，这就实现了读-写，写-读的并发执行，提升了系统的性能。
1、Innodb和Myisam引擎
Myisam：支持表锁，适合读密集的场景，不支持外键，不支持事务，索引与数据在不同的文件
Innodb：支持行、表锁，默认为行锁，适合并发场景，支持外键，支持事务，索引与数据同一文件
2、哈希索引
哈希索引用索引列的值计算该值的hashCode，然后在hashCode相应的位置存执该值所在行数据的物理位置，因为使用散列算法，因此访问速度非常快，但是一个值只能对应一个hashCode，而且是散列的分布方式，因此哈希索引不支持范围查找和排序的功能
3、B+树索引
优点：
B+树的磁盘读写代价低，更少的查询次数，查询效率更加稳定，有利于对数据库的扫描
B+树是B树的升级版，B+树只有叶节点存放数据，其余节点用来索引。索引节点可以全部加入内存，增加查询效率，叶子节点可以做双向链表，从而提高范围查找的效率，增加的索引的范围
在大规模数据存储的时候，红黑树往往出现由于树的深度过大而造成磁盘IO读写过于频繁，进而导致效率低下的情况。所以，只要我们通过某种较好的树结构减少树的结构尽量减少树的高度，B树与B+树可以有多个子女，从几十到上千，可以降低树的高度。
磁盘预读原理：将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。
4、创建索引
CREATE [UNIQUE | FULLTEXT] INDEX 索引名 ON 表名(字段名) [USING 索引方法]；说明：UNIQUE:可选。表示索引为唯一性索引。FULLTEXT:可选。表示索引为全文索引。INDEX和KEY:用于指定字段为索引，两者选择其中之一就可以了，作用是一样的。索引名:可选。给创建的索引取一个新名称。字段名1:指定索引对应的字段的名称，该字段必须是前面定义好的字段。注：索引方法默认使用B+TREE。
5、聚簇索引和非聚簇索引
聚簇索引：将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据（主键索引）
非聚簇索引：将数据与索引分开存储，索引结构的叶子节点指向了数据对应的位置（辅助索引）
聚簇索引的叶子节点就是数据节点，而非聚簇索引的叶子节点仍然是索引节点，只不过有指向对应数据块的指针。
6、最左前缀问题
最左前缀原则主要使用在联合索引中，联合索引的B+Tree是按照第一个关键字进行索引排列的。
联合索引的底层是一颗B+树，只不过联合索引的B+树节点中存储的是键值。由于构建一棵B+树只能根据一个值来确定索引关系，所以数据库依赖联合索引最左的字段来构建。
采用>、<等进行匹配都会导致后面的列无法走索引，因为通过以上方式匹配到的数据是不可知的。
1、SQL语句的执行过程
查询语句：
select * from student A where A.age='18' and A.name='张三';
结合上面的说明，我们分析下这个语句的执行流程：
①通过客户端/服务器通信协议与 MySQL 建立连接。并查询是否有权限
②Mysql8.0之前开看是否开启缓存，开启了 Query Cache 且命中完全相同的 SQL 语句，则将查询结果直接返回给客户端；
③由解析器进行语法语义解析，并生成解析树。如查询是select、表名tb_student、条件是id='1'
④查询优化器生成执行计划。根据索引看看是否可以优化
⑤查询执行引擎执行 SQL 语句，根据存储引擎类型，得到查询结果。若开启了 Query Cache，则缓存，否则直接返回。
2、回表查询和覆盖索引
普通索引（唯一索引+联合索引+全文索引）需要扫描两遍索引树
（1）先通过普通索引定位到主键值id=5；
（2）在通过聚集索引定位到行记录；
这就是所谓的回表查询，先定位主键值，再定位行记录，它的性能较扫一遍索引树更低。
覆盖索引：主键索引==聚簇索引==覆盖索引
如果where条件的列和返回的数据在一个索引中，那么不需要回查表，那么就叫覆盖索引。
实现覆盖索引：常见的方法是，将被查询的字段，建立到联合索引里去。
3、Explain及优化
mysql> explain select * from staff;+----+-------------+-------+------+---------------+------+---------+------+------+-------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-------+------+---------------+------+---------+------+------+-------+| 1 | SIMPLE | staff | ALL | NULL | 索引 | NULL | NULL | 2 | NULL |+----+-------------+-------+------+---------------+------+---------+------+------+-------+1 row in set
索引优化：
①最左前缀索引：like只用于'string%'，语句中的=和in会动态调整顺序
②唯一索引：唯一键区分度在0.1以上
③无法使用索引：!= 、is null 、 or、>< 、（5.7以后根据数量自动判定）in 、not in
④联合索引：避免select * ，查询列使用覆盖索引
SELECT uid From user Where gid = 2 order by ctime asc limit 10ALTER TABLE user add index idx_gid_ctime_uid(gid,ctime,uid) #创建联合覆盖索引，避免回表查询
语句优化：
①char固定长度查询效率高，varchar第一个字节记录数据长度
②应该针对Explain中Rows增加索引
③group/order by字段均会涉及索引
④Limit中分页查询会随着start值增大而变缓慢，通过子查询+表连接解决
select * from mytbl order by id limit 100000,10 改进后的SQL语句如下：select * from mytbl where id >= ( select id from mytbl order by id limit 100000,1 ) limit 10select * from mytbl inner ori join (select id from mytbl order by id limit 100000,10) as tmp on tmp.id=ori.id;
⑤count会进行全表扫描，如果估算可以使用explain
⑥delete删除表时会增加大量undo和redo日志， 确定删除可使用trancate
表结构优化：
①单库不超过200张表
②单表不超过500w数据
③单表不超过40列
④单表索引不超过5个
数据库范式 ：
①第一范式（1NF）列不可分割
②第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ]
③第三范式（3NF）属性不依赖于其它非主属性 [ 消除传递依赖 ]
配置优化：
配置连接数、禁用Swap、增加内存、升级SSD硬盘
4、JOIN查询
left join(左联接) 返回包括左表中的所有记录和右表中关联字段相等的记录
right join(右联接) 返回包括右表中的所有记录和左表中关联字段相等的记录
inner join(等值连接) 只返回两个表中关联字段相等的行
1、主从复制过程
MySQl主从复制：
binlog记录格式：statement、row、mixed
基于语句statement的复制、基于行row的复制、基于语句和行（mix）的复制。其中基于row的复制方式更能保证主从库数据的一致性，但日志量较大，在设置时考虑磁盘的空间问题
2、数据一致性问题
"主从复制有延时"，这个延时期间读取从库，可能读到不一致的数据。
缓存记录写key法：
在cache里记录哪些记录发生过的写请求，来路由读主库还是读从库
异步复制：
在异步复制中，主库执行完操作后，写入binlog日志后，就返回客户端，这一动作就结束了，并不会验证从库有没有收到，完不完整，所以这样可能会造成数据的不一致。
半同步复制：
当主库每提交一个事务后，不会立即返回，而是等待其中一个从库接收到Binlog并成功写入Relay-log中才返回客户端，通过一份在主库的Binlog，另一份在其中一个从库的Relay-log，可以保证了数据的安全性和一致性。
全同步复制：
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
3、集群架构
Keepalived + VIP + MySQL 主从/双主
当写节点 Master db1 出现故障时，由 MMM Monitor 或 Keepalived 触发切换脚本，将 VIP 漂移到可用的 Master db2 上。当出现网络抖动或网络分区时，MMM Monitor 会误判，严重时来回切换写 VIP 导致集群双写，当数据复制延迟时，应用程序会出现数据错乱或数据冲突的故障。有效避免单点失效的架构就是采用共享存储，单点故障切换可以通过分布式哨兵系统监控。
架构选型：MMM 集群 -> MHA集群 -> MHA+Arksentinel。
4、故障转移和恢复
转移方式及恢复方法
1. 虚拟IP或DNS服务 （Keepalived +VIP/DNS 和 MMM 架构）
问题：在虚拟 IP 运维过程中，刷新ARP过程中有时会出现一个 VIP 绑定在多台服务器同时提供连接的问题。这也是为什么要避免使用 Keepalived+VIP 和 MMM 架构的原因之一，因为它处理不了这类问题而导致集群多点写入。
2. 提升备库为主库（MHA、QMHA）
尝试将原 Master 设置 read_only 为 on，避免集群多点写入。借助 binlog server 保留 Master 的 Binlog；当出现数据延迟时，再提升 Slave 为新 Master 之前需要进行数据补齐，否则会丢失数据。
分库分表
如何进行分库分表
分表用户id进行分表，每个表控制在300万数据。
分库根据业务场景和地域分库，每个库并发不超过2000
Sharding-jdbc 这种 client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是各个系统都需要耦合 Sharding-jdbc 的依赖，升级比较麻烦
Mycat 这种 proxy 层方案的缺点在于需要部署，自己运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了
水平拆分：一个表放到多个库，分担高并发，加快查询速度
垂直拆分：一个表拆成多个表，可以将一些冷数据拆分到冗余库中
不是写瓶颈优先进行分表
分库首先需考虑满足业务最核心的场景：
1、订单数据按用户分库，可以提升用户的全流程体验
2、超级客户导致数据倾斜可以使用最细粒度唯一标识进行hash拆分
3、按照最细粒度如订单号拆分以后，数据库就无法进行单库排重了
三个问题：
如何将老数据进行迁移
双写不中断迁移
系统性能的评估及扩容
和家亲目前有1亿用户：场景 10万写并发，100万读并发，60亿数据量
设计时考虑极限情况，32库*32表~64个表，一共1000 ~ 2000张表
动态扩容的步骤
如何生成自增的id主键
其中机器预留的10bit可以根据自己的业务场景配置
更新失败 | 主从同步延时
以前线上确实处理过因为主从同步延时问题而导致的线上的 bug，属于小型的生产事故。
是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据，再把它查出来，然后更新这条数据。在生产环境高峰期，写并发达到了 2000/s，这个时候，主从复制延时大概是在小几十毫秒。线上会发现，每天总有那么一些数据，我们期望更新一些重要的数据状态，但在高峰期时候却没更新。用户跟客服反馈，而客服就会反馈给我们。
我们通过 MySQL 命令：
show slave status
查看 Seconds_Behind_Master ，可以看到从库复制主库的数据落后了几 ms。
一般来说，如果主从延迟较为严重，有以下解决方案：
应用崩溃 | 分库分表优化
我们有一个线上通行记录的表，由于数据量过大，进行了分库分表，当时分库分表初期经常产生一些问题。典型的就是通行记录查询中使用了深分页，通过一些工具如MAT、Jstack追踪到是由于sharding-jdbc内部引用造成的。
通行记录数据被存放在两个库中。如果没有提供切分键，查询语句就会被分发到所有的数据库中，比如查询语句是 limit 10、offset 1000，最终结果只需要返回 10 条记录，但是数据库中间件要完成这种计算，则需要 (1000+10)*2=2020 条记录来完成这个计算过程。如果 offset 的值过大，使用的内存就会暴涨。虽然 sharding-jdbc 使用归并算法进行了一些优化，但在实际场景中，深分页仍然引起了内存和性能问题。
这种在中间节点进行归并聚合的操作，在分布式框架中非常常见。比如在 ElasticSearch 中，就存在相似的数据获取逻辑，不加限制的深分页，同样会造成 ES 的内存问题。
业界解决方案：
方法一：全局视野法
（1）将order by time offset X limit Y，改写成order by time offset 0 limit X+Y
（2）服务层对得到的N*(X+Y)条数据进行内存排序，内存排序后再取偏移量X后的Y条记录
这种方法随着翻页的进行，性能越来越低。
方法二：业务折衷法-禁止跳页查询
（1）用正常的方法取得第一页数据，并得到第一页记录的time_max
（2）每次翻页，将order by time offset X limit Y，改写成order by time where time>$time_max limit Y
以保证每次只返回一页数据，性能为常量。
方法三：业务折衷法-允许模糊数据
（1）将order by time offset X limit Y，改写成order by time offset X/N limit Y/N
方法四：二次查询法
（1）将order by time offset X limit Y，改写成order by time offset X/N limit Y
（2）找到最小值time_min
（3）between二次查询，order by time between timeminandtime_i_max
（4）设置虚拟time_min，找到time_min在各个分库的offset，从而得到time_min在全局的offset
（5）得到了time_min在全局的offset，自然得到了全局的offset X limit Y
查询异常 | SQL 调优
分库分表前，有一段用用户名来查询某个用户的 SQL 语句：
select * from user where name = "xxx" and community="other";
为了达到动态拼接的效果，这句 SQL 语句被一位同事进行了如下修改。他的本意是，当 name 或者 community 传入为空的时候，动态去掉这些查询条件。这种写法，在 MyBaits 的配置文件中，也非常常见。大多数情况下，这种写法是没有问题的，因为结果集合是可以控制的。但随着系统的运行，用户表的记录越来越多，当传入的 name 和 community 全部为空时，悲剧的事情发生了:
select * from user where 1=1
数据库中的所有记录，都会被查询出来，载入到 JVM 的内存中。由于数据库记录实在太多，直接把内存给撑爆了。由于这种原因引起的内存溢出，发生的频率非常高，比如导入Excel文件时。
通常的解决方式是强行加入分页功能，或者对一些必填的参数进行校验
Controller 层
现在很多项目都采用前后端分离架构，所以 Controller 层的方法，一般使用 @ResponseBody 注解，把查询的结果，解析成 JSON 数据返回。这在数据集非常大的情况下，会占用很多内存资源。假如结果集在解析成 JSON 之前，占用的内存是 10MB，那么在解析过程中，有可能会使用 20M 或者更多的内存
因此，保持结果集的精简，是非常有必要的，这也是 DTO（Data Transfer Object）存在的必要。互联网环境不怕小结果集的高并发请求，却非常恐惧大结果集的耗时请求，这是其中一方面的原因。
Service 层
Service 层用于处理具体的业务，更加贴合业务的功能需求。一个 Service，可能会被多个 Controller 层所使用，也可能会使用多个 dao 结构的查询结果进行计算、拼装。
int getUserSize() { List<User> users = dao.getAllUser(); return null == users ? 0 : users.size();}
代码review中发现了定时炸弹，这种在数据量达到一定程度后，才会暴露问题。
ORM 层
比如使用Mybatis时，有一个批量导入服务，在 MyBatis 执行批量插入的时候，竟然产生了内存溢出，按道理这种插入操作是不会引起额外内存占用的，最后通过源码追踪到了问题。
这是因为 MyBatis 循环处理 batch 的时候，操作对象是数组，而我们在接口定义的时候，使用的是 List；当传入一个非常大的 List 时，它需要调用 List 的 toArray 方法将列表转换成数组（浅拷贝）；在最后的拼装阶段，又使用了 StringBuilder 来拼接最终的 SQL，所以实际使用的内存要比 List 多很多。
事实证明，不论是插入操作还是查询动作，只要涉及的数据集非常大，就容易出现问题。由于项目中众多框架的引入，想要分析这些具体的内存占用，就变得非常困难。所以保持小批量操作和结果集的干净，是一个非常好的习惯。
速度快，完全基于内存，使用C语言实现，网络层使用epoll解决高并发问题，单线程模型避免了不必要的上下文切换及竞争条件；
| GuavaCache |
Tair |
EVCache |
Aerospike |
|
| 类别 |
本地JVM缓存 |
分布式缓存 |
分布式缓存 |
分布式nosql数据库 |
| 应用 |
本地缓存 |
淘宝 |
Netflix、AWS |
广告 |
| 性能 |
非常高 |
较高 |
很高 |
较高 |
| 持久化 |
无 |
有 |
有 |
有 |
| 集群 |
无 |
灵活配置 |
有 |
自动扩容 |
与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。
1、简单高效
1）完全基于内存，绝大部分请求是纯粹的内存操作。数据存在内存中，类似于 HashMap，查找和操作的时间复杂度都是O(1)；
2）数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；
3）采用单线程，避免了多线程不必要的上下文切换和竞争条件，不存在加锁释放锁操作，减少了因为锁竞争导致的性能消耗；（6.0以后多线程）
4）使用EPOLL多路 I/O 复用模型，非阻塞 IO；
5）使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；
2、Memcache
| redis |
Memcached |
| 内存高速数据库 |
高性能分布式内存缓存数据库 |
| 支持hash、list、set、zset、string结构 |
只支持key-value结构 |
| 将大部分数据放到内存 |
全部数据放到内存中 |
| 支持持久化、主从复制备份 |
不支持数据持久化及数据备份 |
| 数据丢失可通过AOF恢复 |
挂掉后，数据不可恢复 |
| 单线程（2~4万TPS） |
多线程（20-40万TPS） |
使用场景：
1、如果有持久方面的需求或对数据类型和处理有要求的应该选择redis。
2、如果简单的key/value 存储应该选择memcached。
3、Tair
Tair(Taobao Pair)是淘宝开发的分布式Key-Value存储引擎，既可以做缓存也可以做数据源（三种引擎切换）
分布式缓存
大访问少量临时数据的存储（kb左右）
用于缓存，降低对后端数据库的访问压力
session场景
高速访问某些数据结构的应用和计算（rdb）
数据源存储
快速读取数据（fdb）
持续大数据量的存入读取（ldb），交易快照
高频度的更新读取（ldb），库存
痛点：redis集群中，想借用缓存资源必须得指明redis服务器地址去要。这就增加了程序的维护复杂度。因为redis服务器很可能是需要频繁变动的。所以人家淘宝就想啊，为什么不能像操作分布式数据库或者hadoop那样。增加一个中央节点，让他去代理所有事情。在tair中程序只要跟tair中心节点交互就OK了。同时tair里还有配置服务器概念。又免去了像操作hadoop那样，还得每台hadoop一套一模一样配置文件。改配置文件得整个集群都跟着改。
4、Guava
分布式缓存一致性更好一点，用于集群环境下多节点使用同一份缓存的情况；有网络IO，吞吐率与缓存的数据大小有较大关系；
本地缓存非常高效，本地缓存会占用堆内存，影响垃圾回收、影响系统性能。
本地缓存设计：
以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况，每个实例都需要各自保存一份缓存，缓存不具有一致性。
解决缓存过期：
1、将缓存过期时间调为永久
2、将缓存失效时间分散开，不要将缓存时间长度都设置成一样；比如我们可以在原有的失效时间基础上增加一个随机值，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
解决内存溢出：
第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
第二步，检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误。
第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。
Google Guava Cache
自己设计本地缓存痛点：
Guava Cache 的场景：
Guava Cache 的优势：
在GuavaCache中可以设置Key的过期时间，包括访问过期和创建过期。GuavaCache在缓存容量达到指定大小时，采用LRU的方式，将不常使用的键值从Cache中删除
GuavaCache类似CurrentHashMap，是线程安全的。提供了设置并发级别的api，使得缓存支持并发的写入和读取，采用分离锁机制，分离锁能够减小锁力度，提升并发能力，分离锁是分拆锁定，把一个集合看分成若干partition, 每个partiton一把锁。更新锁定
一般情况下，在缓存中查询某个key，如果不存在，则查源数据，并回填缓存。（Cache Aside Pattern）在高并发下会出现，多次查源并重复回填缓存，可能会造成源的宕机（DB），性能下降 GuavaCache可以在CacheLoader的load方法中加以控制，对同一个key，只让一个请求去读源并回填缓存，其他请求阻塞等待。（相当于集成数据源，方便用户使用）
统计
问题：
OOM->设置过期时间、使用弱引用、配置过期策略
5、EVCache
EVCache是一个Netflflix（网飞）公司开源、快速的分布式缓存，是基于Memcached的内存存储实现的，用以构建超大容量、高性能、低延时、跨区域的全球可用的缓存数据层。
E：Ephemeral：数据存储是短暂的，有自身的存活时间
V：Volatile：数据可以在任何时候消失
EVCache典型地适合对强一致性没有必须要求的场合
典型用例：Netflflix向用户推荐用户感兴趣的电影
EVCache集群在峰值每秒可以处理200kb的请求，
Netflflix生产系统中部署的EVCache经常要处理超过每秒3000万个请求，存储数十亿个对象，
跨数千台memcached服务器。整个EVCache集群每天处理近2万亿个请求。
EVCache集群响应平均延时大约是1-5毫秒，最多不会超过20毫秒。
EVCache集群的缓存命中率在99%左右。
典型部署
EVCache 是线性扩展的，可以在一分钟之内完成扩容，在几分钟之内完成负载均衡和缓存预热。
1、集群启动时，EVCache向服务注册中心（Zookeeper、Eureka）注册各个实例
2、在web应用启动时，查询命名服务中的EVCache服务器列表，并建立连接。
3、客户端通过key使用一致性hash算法，将数据分片到集群上。
6、ETCD
和Zookeeper一样，CP模型追求数据一致性，越来越多的系统开始用它保存关键数据。比如，秒杀系统经常用它保存各节点信息，以便控制消费 MQ 的服务数量。还有些业务系统的配置数据，也会通过 etcd 实时同步给业务系统的各节点，比如，秒杀管理后台会使用 etcd 将秒杀活动的配置数据实时同步给秒杀 API 服务各节点。
1、redis数据类型
| 类型 |
底层 |
应用场景 |
编码类型 |
| String |
SDS数组 |
帖子、评论、热点数据、输入缓冲 |
RAW << EMBSTR << INT |
| List |
QuickList |
评论列表、商品列表、发布与订阅、慢查询、监视器 |
LINKEDLIST << ZIPLIST |
| Set |
intSet |
适合交集、并集、查集操作，例如朋友关系 |
HT << INSET |
| Zset |
跳跃表 |
去重后排序，适合排名场景 |
SKIPLIST << ZIPLIST |
| Hash |
哈希 |
结构化数据，比如存储对象 |
HT << ZIPLIST |
| Stream |
紧凑列表 |
消息队列 |
2、相关API
| String |
SET |
SETNX |
SETEX |
GET |
GETSET |
INCR |
DECR |
MSET |
MGET |
| Hash |
HSET |
HSETNX |
HGET |
HDEL |
HLEN |
HMSET |
HMGET |
HKEYS |
HGETALL |
| LIST |
LPUSH |
LPOP |
RPUSH |
RPOP |
LINDEX |
LREM |
LRANGE |
LLEN |
RPOPLPUSH |
| ZSET |
ZADD |
ZREM |
ZSCORE |
ZCARD |
ZRANGE |
ZRANK |
ZREVRANK |
ZREVRANGE |
|
| SET |
SADD |
SREM |
SISMEMBER |
SCARD |
SINTER |
SUNION |
SDIFF |
SPOP |
SMEMBERS |
| 事务 |
MULTI |
EXEC |
DISCARD |
WATCH |
UNWATCH |
3、redis底层结构
SDS数组结构，用于存储字符串和整型数据及输入缓冲。
struct sdshdr{ int len;//记录buf数组中已使用字节的数量 int free; //记录 buf 数组中未使用字节的数量 char buf[];//字符数组，用于保存字符串}
跳跃表：将有序链表中的部分节点分层，每一层都是一个有序链表。
1、可以快速查找到需要的节点 O(logn) ，额外存储了一倍的空间
2、可以在O(1)的时间复杂度下，快速获得跳跃表的头节点、尾结点、长度和高度。
字典dict: 又称散列表(hash)，是用来存储键值对的一种数据结构。
Redis整个数据库是用字典来存储的(K-V结构) —Hash+数组+链表
Redis字典实现包括:**字典(dict)、Hash表(dictht)、Hash表节点(dictEntry)**。
字典达到存储上限(阈值 0.75)，需要rehash(扩容)
1、初次申请默认容量为4个dictEntry，非初次申请为当前hash表容量的一倍。
2、rehashidx=0表示要进行rehash操作。
3、新增加的数据在新的hash表h[1] 、修改、删除、查询在老hash表h[0]
4、将老的hash表h[0]的数据重新计算索引值后全部迁移到新的hash表h[1]中，这个过程称为 rehash。
渐进式rehash
由于当数据量巨大时rehash的过程是非常缓慢的，所以需要进行优化。 可根据服务器空闲程度批量rehash部分节点
压缩列表zipList
压缩列表(ziplist)是由一系列特殊编码的连续内存块组成的顺序型数据结构，节省内容
sorted-set和hash元素个数少且是小整数或短字符串(直接使用)
list用快速链表(quicklist)数据结构存储，而快速链表是双向列表与压缩列表的组合。(间接使用)
整数集合intSet
整数集合(intset)是一个有序的(整数升序)、存储整数的连续存储结构。
当Redis集合类型的元素都是整数并且都处在64位有符号整数范围内(2^64)，使用该结构体存储。
快速列表quickList
快速列表(quicklist)是Redis底层重要的数据结构。是Redis3.2列表的底层实现。
(在Redis3.2之前，Redis采 用双向链表(adlist)和压缩列表(ziplist)实现。)
Redis Stream的底层主要使用了listpack(紧凑列表)和Rax树(基数树)。
listpack表示一个字符串列表的序列化，listpack可用于存储字符串或整数。用于存储stream的消息内 容。
Rax树是一个有序字典树 (基数树 Radix Tree)，按照 key 的字典序排列，支持快速地定位、插入和删除操 作。
4、Zset底层实现
跳表(skip List)是一种随机化的数据结构，基于并联的链表，实现简单，插入、删除、查找的复杂度均为O(logN)。简单说来跳表也是链表的一种，只不过它在链表的基础上增加了跳跃功能，正是这个跳跃的功能，使得在查找元素时，跳表能够提供O(logN)的时间复杂度
Zset数据量少的时候使用压缩链表ziplist实现，有序集合使用紧挨在一起的压缩列表节点来保存，第一个节点保存member，第二个保存score。ziplist内的集合元素按score从小到大排序，score较小的排在表头位置。 数据量大的时候使用跳跃列表skiplist和哈希表hash_map结合实现，查找删除插入的时间复杂度都是O(longN)
Redis使用跳表而不使用红黑树，是因为跳表的索引结构序列化和反序列化更加快速，方便持久化。
搜索
跳跃表按 score 从小到大保存所有集合元素，查找时间复杂度为平均 O(logN)，最坏 O(N) 。
插入
选用链表作为底层结构支持，为了高效地动态增删。因为跳表底层的单链表是有序的，为了维护这种有序性，在插入前需要遍历链表，找到该插入的位置，单链表遍历查找的时间复杂度是O(n)，同理可得，跳表的遍历也是需要遍历索引数，所以是O(logn)。
删除
如果该节点还在索引中，删除时不仅要删除单链表中的节点，还要删除索引中的节点；单链表在知道删除的节点是谁时，时间复杂度为O(1)，但针对单链表来说，删除时都需要拿到前驱节点O(logN)才可改变引用关系从而删除目标节点。
1、redis持久化
持久化就是把内存中的数据持久化到本地磁盘，防止服务器宕机了内存数据丢失
Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制，Redis4.0以后采用混合持久化，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备
RDB：是Redis DataBase缩写快照
RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。
优点：
1）只有一个文件 dump.rdb，方便持久化；
2）容灾性好，一个文件可以保存到安全的磁盘。
3）性能最大化，fork 子进程来进行持久化写操作，让主进程继续处理命令，只存在毫秒级不响应请求。
4）相对于数据集大时，比 AOF 的启动效率更高。
缺点：
数据安全性低，RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。
AOF：持久化
AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。
优点：
1）数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
2）通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
缺点：
1）AOF 文件比 RDB 文件大，且恢复速度慢。
2）数据集大的时候，比 rdb 启动效率低。
2、redis事务
事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
Redis事务的概念
Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的。当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性。
Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的
事务命令：
MULTI：用于开启一个事务，它总是返回OK。MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。当操作被打断时，返回空值 nil 。
WATCH ：是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。（秒杀场景）
DISCARD：调用该命令，客户端可以清空事务队列，并放弃执行事务，且客户端会从事务状态中退出。
UNWATCH：命令可以取消watch对所有key的监控。
3、redis失效策略
内存淘汰策略
1）全局的键空间选择性移除
noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。（字典库常用）
allkeys-lru：在键空间中，移除最近最少使用的key。（缓存常用）
allkeys-random：在键空间中，随机移除某个key。
2）设置过期时间的键空间选择性移除
volatile-lru：在设置了过期时间的键空间中，移除最近最少使用的key。
volatile-random：在设置了过期时间的键空间中，随机移除某个key。
volatile-ttl：在设置了过期时间的键空间中，有更早过期时间的key优先移除。
缓存失效策略
定时清除：针对每个设置过期时间的key都创建指定定时器
惰性清除：访问时判断，对内存不友好
定时扫描清除：定时100ms随机20个检查过期的字典，若存在25%以上则继续循环删除。
4、redis读写模式
CacheAside旁路缓存
写请求更新数据库后删除缓存数据。读请求不命中查询数据库，查询完成写入缓存
业务端处理所有数据访问细节，同时利用 Lazy 计算的思想，更新 DB 后，直接删除 cache 并通过 DB 更新，确保数据以 DB 结果为准，则可以大幅降低 cache 和 DB 中数据不一致的概率
如果没有专门的存储服务，同时是对数据一致性要求比较高的业务，或者是缓存数据更新比较复杂的业务，适合使用 Cache Aside 模式。如微博发展初期，不少业务采用这种模式
// 延迟双删，用以保证最终一致性,防止小概率旧数据读请求在第一次删除后更新数据库public void write(String key,Object data){ redis.delKey(key); db.updateData(data); Thread.sleep(1000); redis.delKey(key);}
高并发下保证绝对的一致，先删缓存再更新数据，需要用到内存队列做异步串行化。非高并发场景，先更新数据再删除缓存，延迟双删策略基本满足了
Read/Write Though（读写穿透）
先查询缓存中数据是否存在,如果存在则直接返回,如果不存在,则由缓存组件负责从数据库中同步加载数据.
先查询要写入的数据在缓存中是否已经存在,如果已经存在,则更新缓存中的数据，并且由缓存组件同步更新到数据库中。
用户读操作较多.相较于Cache aside而言更适合缓存一致的场景。使用简单屏蔽了底层数据库的操作,只是操作缓存.
场景：
微博 Feed 的 Outbox Vector（即用户最新微博列表）就采用这种模式。一些粉丝较少且不活跃的用户发表微博后，Vector 服务会首先查询 Vector Cache，如果 cache 中没有该用户的 Outbox 记录，则不写该用户的 cache 数据，直接更新 DB 后就返回，只有 cache 中存在才会通过 CAS 指令进行更新。
Write Behind Caching（异步缓存写入）
比如对一些计数业务，一条 Feed 被点赞 1万 次，如果更新 1万 次 DB 代价很大，而合并成一次请求直接加 1万，则是一个非常轻量的操作。但这种模型有个显著的缺点，即数据的一致性变差，甚至在一些极端场景下可能会丢失数据。
5、多级缓存
浏览器本地内存缓存：专题活动，一旦上线，在活动期间是不会随意变更的。
浏览器本地磁盘缓存：Logo缓存，大图片懒加载
服务端本地内存缓存：由于没有持久化，重启时必定会被穿透
服务端网络内存缓存：Redis等，针对穿透的情况下可以继续分层，必须保证数据库不被压垮
为什么不是使用服务器本地磁盘做缓存？
当系统处理大量磁盘 IO 操作的时候，由于 CPU 和内存的速度远高于磁盘，可能导致 CPU 耗费太多时间等待磁盘返回处理的结果。对于这部分 CPU 在 IO 上的开销，我们称为 iowait
1、缓存雪崩
指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案：
2、缓存穿透
Redis缓存击穿、雪崩、穿透！（超详细）_lin777lin的博客-CSDN博客_redis缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案：
1）接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
2）从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒。这样可以防止攻击用户反复用同一个id暴力攻击；
3）采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。（宁可错杀一千不可放过一人）
3、缓存击穿
这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库
解决方案：
1）设置热点数据永远不过期，异步线程处理。
2）加写回操作加互斥锁，查询失败默认值快速返回。
3）缓存预热
系统上线后，将相关可预期（例如排行榜）热点数据直接加载到缓存。
写一个缓存刷新页面，手动操作热点数据（例如广告推广）上下线。
4、数据不一致
在缓存机器的带宽被打满，或者机房网络出现波动时，缓存更新失败，新数据没有写入缓存，就会导致缓存和 DB 的数据不一致。缓存 rehash 时，某个缓存机器反复异常，多次上下线，更新请求多次 rehash。这样，一份数据存在多个节点，且每次 rehash 只更新某个节点，导致一些缓存节点产生脏数据。
5、数据并发竞争
数据并发竞争在大流量系统也比较常见，比如车票系统，如果某个火车车次缓存信息过期，但仍然有大量用户在查询该车次信息。又比如微博系统中，如果某条微博正好被缓存淘汰，但这条微博仍然有大量的转发、评论、赞。上述情况都会造成并发竞争读取的问题。
6、热点key问题
明星结婚、离婚、出轨这种特殊突发事件，比如奥运、春节这些重大活动或节日，还比如秒杀、双12、618 等线上促销活动，都很容易出现 Hot key 的情况。
如何提前发现HotKey？
解决方案：
7、BigKey问题
比如互联网系统中需要保存用户最新 1万 个粉丝的业务，比如一个用户个人信息缓存，包括基本资料、关系图谱计数、发 feed 统计等。微博的 feed 内容缓存也很容易出现，一般用户微博在 140 字以内，但很多用户也会发表 1千 字甚至更长的微博内容，这些长微博也就成了大 key
1、redis数据分区
Hash：（不稳定）
客户端分片：哈希+取余
节点伸缩：数据节点关系变化，导致数据迁移
迁移数量和添加节点数量有关：建议翻倍扩容
一个简单直观的想法是直接用Hash来计算，以Key做哈希后对节点数取模。可以看出，在key足够分散的情况下，均匀性可以获得，但一旦有节点加入或退出，所有的原有节点都会受到影响，稳定性无从谈起。
一致性Hash：（不均衡）
客户端分片：哈希+顺时针（优化取余）
节点伸缩：只影响邻近节点，但是还是有数据迁移
翻倍伸缩：保证最小迁移数据和负载均衡
一致性Hash可以很好的解决稳定问题，可以将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到先遇到的一组存储节点存放。而当有节点加入或退出时，仅影响该节点在Hash环上顺时针相邻的后续节点，将数据从该节点接收或者给予。但这又带来均匀性的问题，即使可以将存储节点等距排列，也会在存储节点个数变化时带来数据的不均匀。
Codis的Hash槽
Codis 将所有的 key 默认划分为 1024 个槽位(slot)，它首先对客户端传过来的 key 进行 crc32 运算计算 哈希值，再将 hash 后的整数值对 1024 这个整数进行取模得到一个余数，这个余数就是对应 key 的槽位。
RedisCluster
Redis-cluster把所有的物理节点映射到[0-16383]个slot上,对key采用crc16算法得到hash值后对16384取模，基本上采用平均分配和连续分配的方式。
2、主从模式=简单
主从模式最大的优点是部署简单，最少两个节点便可以构成主从模式，并且可以通过读写分离避免读和写同时不可用。不过，一旦 Master 节点出现故障，主从节点就无法自动切换，直接导致 SLA 下降。所以，主从模式一般适合业务发展初期，并发量低，运维成本低的情况
主从复制原理：
①通过从服务器发送到PSYNC命令给主服务器
②如果是首次连接，触发一次全量复制。此时主节点会启动一个后台线程，生成 RDB 快照文件
③主节点会将这个 RDB 发送给从节点，slave 会先写入本地磁盘，再从本地磁盘加载到内存中
④master会将此过程中的写命令写入缓存，从节点实时同步这些数据
⑤如果网络断开了连接，自动重连后主节点通过命令传播增量复制给从节点部分缺少的数据
缺点
所有的slave节点数据的复制和同步都由master节点来处理，会照成master节点压力太大，使用主从从结构来解决，redis4.0中引入psync2 解决了slave重启后仍然可以增量同步。
3、哨兵模式=读多
由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。哨兵模式适合读请求远多于写请求的业务场景，比如在秒杀系统中用来缓存活动信息。 如果写请求较多，当集群 Slave 节点数量多了后，Master 节点同步数据的压力会非常大。
当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。
检测主观下线状态
Sentinel每秒一次向所有与它建立了命令连接的实例(主服务器、从服务器和其他Sentinel)发送PING命 令
实例在down-after-milliseconds毫秒内返回无效回复Sentinel就会认为该实例主观下线(SDown)
检查客观下线状态
当一个Sentinel将一个主服务器判断为主观下线后 ，Sentinel会向监控这个主服务器的所有其他Sentinel发送查询主机状态的命令
如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。
选举Leader Sentinel
当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法(raft)，选出一个Leader Sentinel去执行**failover(故障转移)**操作。
Raft算法
Raft协议是用来解决分布式系统一致性问题的协议。 Raft协议描述的节点共有三种状态:Leader, Follower, Candidate。 Raft协议将时间切分为一个个的Term(任期)，可以认为是一种“逻辑时间”。 选举流程:
①Raft采用心跳机制触发Leader选举系统启动后，全部节点初始化为Follower，term为0
②节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份
③节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。 一旦转化为Candidate，该节点立即开始下面几件事情:
--增加自己的term，启动一个新的定时器
--给自己投一票，向所有其他节点发送RequestVote，并等待其他节点的回复。
④如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时通过 AppendEntries，向其他节点发送通知。
⑤每个节点在一个term内只能投一票，采取先到先得的策略，Candidate投自己， Follower会投给第一个收到RequestVote的节点。
⑥Raft协议的定时器采取随机超时时间（选举的关键），先转为Candidate的节点会先发起投票，从而获得多数票。
主服务器的选择
当选举出Leader Sentinel后，Leader Sentinel会根据以下规则去从服务器中选择出新的主服务器。
故障转移
当Leader Sentinel完成新的主服务器选择后，Leader Sentinel会对下线的主服务器执行故障转移操作，主要有三个步骤:
1、它会将失效 Master 的其中一个 Slave 升级为新的 Master , 并让失效 Master 的其他 Slave 改为复制新的 Master ;
2、当客户端试图连接失效的 Master 时，集群会向客户端返回新 Master 的地址，使得集群当前状态只有一个Master。
3、Master 和 Slave 服务器切换后， Master 的 redis.conf 、 Slave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变，即 Master 主服务器的 redis.conf配置文件中会多一行 replicaof 的配置， sentinel.conf 的监控目标会随之调换。
4、集群模式=写多
为了避免单一节点负载过高导致不稳定，集群模式采用一致性哈希算法或者哈希槽的方法将 Key 分布到各个节点上。其中，每个 Master 节点后跟若干个 Slave 节点，用于出现故障时做主备切换，客户端可以连接任意 Master 节点，集群内部会按照不同 key 将请求转发到不同的 Master 节点
集群模式是如何实现高可用的呢？集群内部节点之间会互相定时探测对方是否存活，如果多数节点判断某个节点挂了，则会将其踢出集群，然后从 Slave 节点中选举出一个节点替补挂掉的 Master 节点。整个原理基本和哨兵模式一致
虽然集群模式避免了 Master 单节点的问题，但集群内同步数据时会占用一定的带宽。所以，只有在写操作比较多的情况下人们才使用集群模式，其他大多数情况，使用哨兵模式都能满足需求
5、分布式锁
利用Watch实现Redis乐观锁
乐观锁基于CAS(Compare And Swap)比较并替换思想，不会产生锁等待而消耗资源，但是需要反复的重试，但也是因为重试的机制，能比较快的响应。因此我们可以利用redis来实现乐观锁（秒杀）。具体思路如下:
1、利用redis的watch功能，监控这个redisKey的状态值
2、获取redisKey的值，创建redis事务，给这个key的值+1
3、执行这个事务，如果key的值被修改过则回滚，key不加1
利用setnx防止库存超卖
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。 利用Redis的单线程特性对共享资源进行串行化处理
// 获取锁推荐使用set的方式String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);String result = jedis.setnx(lockKey, requestId); //如线程死掉，其他线程无法获取到锁
// 释放锁，非原子操作，可能会释放其他线程刚加上的锁if (requestId.equals(jedis.get(lockKey))) { jedis.del(lockKey);}// 推荐使用redis+lua脚本String lua = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";Object result = jedis.eval(lua, Collections.singletonList(lockKey),
分布式锁存在的问题：
计算时间内异步启动另外一个线程去检查的问题，这个key是否超时，当锁超时时间快到期且逻辑未执行完，延长锁超时时间。
与zookeeper分布式锁对比
Redission生产环境的分布式锁
Redisson是基于NIO的Netty框架上的一个Java驻内存数据网格(In-Memory Data Grid)分布式锁开源组件。
但当业务必须要数据的强一致性，即不允许重复获得锁，比如金融场景(重复下单，重复转账)，请不要使用redis分布式锁。可以使用CP模型实现，比如:zookeeper和etcd。
| Redis |
zookeeper |
etcd |
|
| 一致性算法 |
无 |
paxos(ZAB) |
raft |
| CAP |
AP |
CP |
CP |
| 高可用 |
主从集群 |
n+1 |
n+1 |
| 实现 |
setNX |
createNode |
restfulAPI |
6、redis心跳检测
在命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送ACK命令:
1、检测主从的连接状态 检测主从服务器的网络连接状态
lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有 故障。
2、辅助实现min-slaves,Redis可以通过配置防止主服务器在不安全的情况下执行写命令
min-slaves-to-write 3 (min-replicas-to-write 3 )min-slaves-max-lag 10 (min-replicas-max-lag 10)
上面的配置表示:从服务器的数量少于3个，或者三个从服务器的延迟(lag)值都大于或等于10 秒时，主服务器将拒绝执行写命令。
3、检测命令丢失，增加重传机制
如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发 送REPLCONF ACK命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量， 然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。
1、Redis优化
读写方式
简单来说就是不用keys等，用range、contains之类。比如，用户粉丝数，大 V 的粉丝更是高达几千万甚至过亿，因此，获取粉丝列表只能部分获取。另外在判断某用户是否关注了另外一个用户时，也只需要关注列表上进行检查判断，然后返回 True/False 或 0/1 的方式更为高效。
KV size
如果单个业务的 KV size 过大，需要分拆成多个 KV 来缓存。拆分时应考虑访问频率
key 的数量
如果数据量巨大，则在缓存中尽可能只保留频繁访问的热数据，对于冷数据直接访问 DB。
读写峰值
如果小于 10万 级别，简单分拆到独立 Cache 池即可
如果达到 100万 级的QPS，则需要对 Cache 进行分层处理，可以同时使用 Local-Cache 配合远程 cache，甚至远程缓存内部继续分层叠加分池进行处理。（多级缓存）
命中率
缓存的命中率对整个服务体系的性能影响甚大。对于核心高并发访问的业务，需要预留足够的容量，确保核心业务缓存维持较高的命中率。比如微博中的 Feed Vector Cache（热点资讯），常年的命中率高达 99.5% 以上。为了持续保持缓存的命中率，缓存体系需要持续监控，及时进行故障处理或故障转移。同时在部分缓存节点异常、命中率下降时，故障转移方案，需要考虑是采用一致性 Hash 分布的访问漂移策略，还是采用数据多层备份策略。
过期策略
可以设置较短的过期时间，让冷 key 自动过期；也可以让 key 带上时间戳，同时设置较长的过期时间，比如很多业务系统内部有这样一些 key：key_20190801。
缓存穿透时间
平均缓存穿透加载时间在某些业务场景下也很重要，对于一些缓存穿透后，加载时间特别长或者需要复杂计算的数据，而且访问量还比较大的业务数据，要配置更多容量，维持更高的命中率，从而减少穿透到 DB 的概率，来确保整个系统的访问性能。
缓存可运维性
对于缓存的可运维性考虑，则需要考虑缓存体系的集群管理，如何进行一键扩缩容，如何进行缓存组件的升级和变更，如何快速发现并定位问题，如何持续监控报警，最好有一个完善的运维平台，将各种运维工具进行集成。
缓存安全性
对于缓存的安全性考虑，一方面可以限制来源 IP，只允许内网访问，同时加密鉴权访问。
2、Redis热升级
在 Redis 需要升级版本或修复 bug 时，如果直接重启变更，由于需要数据恢复，这个过程需要近 10 分钟的时间，时间过长，会严重影响系统的可用性。面对这种问题，可以对 Redis 扩展热升级功能，从而在毫秒级完成升级操作，完全不影响业务访问。
热升级方案如下，首先构建一个 Redis 壳程序，将 redisServer 的所有属性（包括redisDb、client等）保存为全局变量。然后将 Redis 的处理逻辑代码全部封装到动态连接库 so 文件中。Redis 第一次启动，从磁盘加载恢复数据，在后续升级时，通过指令，壳程序重新加载 Redis 新的 redis-4.so 到 redis-5.so 文件，即可完成功能升级，毫秒级完成 Redis 的版本升级。而且整个过程中，所有 Client 连接仍然保留，在升级成功后，原有 Client 可以继续进行读写操作，整个过程对业务完全透明。
消息队列的作用：异步、削峰填谷、解耦
中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ （开源、社区活跃）是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ（Java二次开发） 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
RabbitMQ
RabbitMQ开始是用在电信业务的可靠通信的，也是少有的几款支持AMQP协议的产品之一。
优点：
缺点：
RocketMQ
借鉴了Kafka的设计并做了很多改进，几乎具备了消息队列应该具备的所有特性和功能。
缺点：
跟周边系统的整合和兼容不是很好。
Kafka
高可用，几乎所有相关的开源软件都支持，满足大多数的应用场景，尤其是大数据和流计算领域，
消息Message
Kafka的数据单元称为消息。可以把消息看成是数据库里的一个“数据行”或一条“记录”。
批次
为了提高效率，消息被分批写入Kafka。提高吞吐量却加大了响应时间
主题Topic
通过主题进行分类，类似数据库中的表，
分区Partition
Topic可以被分成若干分区分布于kafka集群中，方便扩容
单个分区内是有序的，partition设置为一才能保证全局有序
副本Replicas
每个主题被分为若干个分区，每个分区有多个副本。
生产者Producer
生产者在默认情况下把消息均衡地分布到主题的所有分区上：
消费者Comsumer
消费者通过偏移量来区分已经读过的消息，从而消费消息。把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。
消费组ComsumerGroup
消费组保证每个分区只能被一个消费者使用，避免重复消费。如果群组内一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作再平衡，重新分区
节点Broker
连接生产者和消费者，单个broker可以轻松处理数千个分区以及每秒百万级的消息量。
集群
每隔分区都有一个首领，当分区被分配给多个broker时，会通过首领进行分区复制。
生产者Offset
消息写入的时候，每一个分区都有一个offset，即每个分区的最新最大的offset。
消费者Offset
不同消费组中的消费者可以针对一个分区存储不同的Offset，互不影响
LogSegment
优点
应用场景
Leader选举
副本消息同步
首先，Follower 发送 FETCH 请求给 Leader。接着，Leader 会读取底层日志文件中的消 息数据，再更新它内存中的 Follower 副本的 LEO 值，更新为 FETCH 请求中的 fetchOffset 值。最后，尝试更新分区高水位值。Follower 接收到 FETCH 响应之后，会把消息写入到底层日志，接着更新 LEO 和 HW 值。
相关概念：LEO和HW。
Rebalance
leader选举完成后，当以上三种情况发生时，Leader根据配置的RangeAssignor开始分配消费方案，即哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案封装进SyncGroup请求中发给coordinator，非leader也会发SyncGroup请求，只是内容为空。coordinator接收到分配方案之后会把方案塞进SyncGroup的response中发给各个consumer。这样组内的所有成员就都知道自己应该消费哪些分区了。
分区分配算法RangeAssignor
增删改查
kafka-topics.sh --zookeeper localhost:2181/myKafka --create --topic topic_x --partitions 1 --replication-factor 1kafka-topics.sh --zookeeper localhost:2181/myKafka --delete --topic topic_xkafka-topics.sh --zookeeper localhost:2181/myKafka --alter --topic topic_x --config max.message.bytes=1048576kafka-topics.sh --zookeeper localhost:2181/myKafka --describe --topic topic_x
如何查看偏移量为23的消息？
通过查询跳跃表ConcurrentSkipListMap，定位到在00000000000000000000.index ，通过二分法在偏移量索引文件中找到不大于 23 的最大索引项，即offset 20 那栏，然后从日志分段文件中的物理位置为320 开始顺序查找偏移量为 23 的消息。
切分文件
幂等性
保证在消息重发的时候，消费者不会重复处理。即使在消费者收到重复消息的时候，重复处理，也
要保证最终结果的一致性。所谓幂等性，数学概念就是： f(f(x)) = f(x)
如何实现？
添加唯一ID，类似于数据库的主键，用于唯一标记一个消息。
ProducerID：#在每个新的Producer初始化时，会被分配一个唯一的PIDSequenceNumber：#对于每个PID发送数据的每个Topic都对应一个从0开始单调递增的SN值
如何选举
线上问题rebalance
因集群架构变动导致的消费组内重平衡，如果kafka集内节点较多，比如数百个，那重平衡可能会耗时导致数分钟到数小时，此时kafka基本处于不可用状态，对kafka的TPS影响极大
产生的原因：
解决方案：
加大超时时间 session.timout.ms=6s加大心跳频率 heartbeat.interval.ms=2s增长推送间隔 max.poll.interval.ms=t+1 minutes
ZooKeeper 的作用
目前，Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务。之后，等 KIP-500 提案完成后，Kafka 将完全不再依赖于 ZooKeeper。
一言以蔽之:KIP-500 ，是使用社区自研的基于 Raft 的共识算法，实现 Controller 自选举。
同样是存储元数据，这几年基于Raft算法的etcd认可度越来越高
越来越多的系统开始用它保存关键数据。比如，秒杀系统经常用它保存各节点信息，以便控制消费 MQ 的服务数量。还有些业务系统的配置数据，也会通过 etcd 实时同步给业务系统的各节点，比如，秒杀管理后台会使用 etcd 将秒杀活动的配置数据实时同步给秒杀 API 服务各节点。
Replica副本的作用
Kafka 只有 Leader 副本才能 对外提供读写服务，响应 Clients 端的请求。Follower 副本只是采用拉(PULL)的方 式，被动地同步 Leader 副本中的数据，并且在 Leader 副本所在的 Broker 宕机后，随时准备应聘 Leader 副本。
为什么不支持读写分离?
如何防止重复消费
如何保证数据不会丢失
如何保证顺序消费
【线上】如何解决积压消费
如何避免消息积压
if (maxOffset - curOffset > 100000) { // TODO 消息堆积情况的优先处理逻辑 // 未处理的消息可以选择丢弃或者打日志 return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;}// TODO 正常消费过程return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
如何设计消息队列
需要支持快速水平扩容，broker+partition，partition放不同的机器上，增加机器时将数据根据topic做迁移，分布式需要考虑一致性、可用性、分区容错性
性能上，可以借鉴时间轮、零拷贝、IO多路复用、顺序读写、压缩批处理
1、IOC 控制反转
IoC（Inverse of Control:控制反转）是⼀种设计思想，就是将原本在程序中⼿动创建对象的控制权，交由Spring框架来管理。 IoC 在其他语⾔中也有应⽤，并⾮ Spring 特有。
IoC 容器是 Spring⽤来实现 IoC 的载体， IoC 容器实际上就是个Map（key，value）,Map 中存放的是各种对象。将对象之间的相互依赖关系交给 IoC 容器来管理，并由 IoC 容器完成对象的注⼊。这样可以很⼤程度上简化应⽤的开发，把应⽤从复杂的依赖关系中解放出来。 IoC 容器就像是⼀个⼯⼚⼀样，当我们需要创建⼀个对象的时候，只需要配置好配置⽂件/注解即可，完全不⽤考虑对象是如何被创建出来的。
DI 依赖注入
DI:（Dependancy Injection：依赖注入)站在容器的角度，将对象创建依赖的其他对象注入到对象中。
2、AOP 动态代理
AOP(Aspect-Oriented Programming:⾯向切⾯编程)能够将那些与业务⽆关，却为业务模块所共同调⽤的逻辑或责任（例如事务处理、⽇志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。
Spring AOP就是基于动态代理的，如果要代理的对象，实现了某个接⼝，那么Spring AOP会使⽤JDKProxy，去创建代理对象，⽽对于没有实现接⼝的对象，就⽆法使⽤ JDK Proxy 去进⾏代理了，这时候Spring AOP会使⽤基于asm框架字节流的Cglib动态代理 ，这时候Spring AOP会使⽤ Cglib ⽣成⼀个被代理对象的⼦类来作为代理。
3、Bean生命周期
单例对象： singleton
总结：单例对象的生命周期和容器相同
多例对象： prototype
出生：使用对象时spring框架为我们创建
活着：对象只要是在使用过程中就一直活着
死亡：当对象长时间不用且没有其它对象引用时，由java的垃圾回收机制回收
IOC容器初始化加载Bean流程：
@Overridepublic void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // 第一步:刷新前的预处理 prepareRefresh(); //第二步: 获取BeanFactory并注册到 BeanDefitionRegistry ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // 第三步:加载BeanFactory的预准备工作(BeanFactory进行一些设置，比如context的类加载器等) prepareBeanFactory(beanFactory); try { // 第四步:完成BeanFactory准备工作后的前置处理工作 postProcessBeanFactory(beanFactory); // 第五步:实例化BeanFactoryPostProcessor接口的Bean invokeBeanFactoryPostProcessors(beanFactory); // 第六步:注册BeanPostProcessor后置处理器，在创建bean的后执行 registerBeanPostProcessors(beanFactory); // 第七步:初始化MessageSource组件(做国际化功能;消息绑定，消息解析); initMessageSource(); // 第八步:注册初始化事件派发器 initApplicationEventMulticaster(); // 第九步:子类重写这个方法，在容器刷新的时候可以自定义逻辑 onRefresh(); // 第十步:注册应用的监听器。就是注册实现了ApplicationListener接口的监听器 registerListeners(); //第十一步:初始化所有剩下的非懒加载的单例bean 初始化创建非懒加载方式的单例Bean实例(未设置属性) finishBeanFactoryInitialization(beanFactory); //第十二步: 完成context的刷新。主要是调用LifecycleProcessor的onRefresh()方法，完成创建 finishRefresh(); } ……}
总结：
四个阶段
多个扩展点
完整流程
4、Bean作用域
| 名称 |
作用域 |
| singleton |
单例对象，默认值的作用域 |
| prototype |
每次获取都会创建⼀个新的 bean 实例 |
| request |
每⼀次HTTP请求都会产⽣⼀个新的bean，该bean仅在当前HTTP request内有效。 |
| session |
在一次 HTTP session 中，容器将返回同一个实例 |
| global-session |
将对象存入到web项目集群的session域中,若不存在集群,则global session相当于session |
默认作用域是singleton，多个线程访问同一个bean时会存在线程不安全问题
保障线程安全方法：
ThreadLocal：
每个线程中都有一个自己的ThreadLocalMap类对象，可以将线程自己的对象保持到其中，各管各的，线程可以正确的访问到自己的对象。
将一个共用的ThreadLocal静态实例作为key，将不同对象的引用保存到不同线程的ThreadLocalMap中，然后在线程执行的各处通过这个静态ThreadLocal实例的get()方法取得自己线程保存的那个对象，避免了将这个对象作为参数传递的麻烦。
5、循环依赖
循环依赖其实就是循环引用，也就是两个或者两个以上的 Bean 互相持有对方，最终形成闭环。比如A 依赖于B，B又依赖于A
Spring中循环依赖场景有:
懒加载@Lazy解决循环依赖问题
Spring 启动的时候会把所有bean信息(包括XML和注解)解析转化成Spring能够识别的BeanDefinition并存到Hashmap里供下面的初始化时用，然后对每个 BeanDefinition 进行处理。普通 Bean 的初始化是在容器启动初始化阶段执行的，而被lazy-init=true修饰的 bean 则是在从容器里第一次进行context.getBean() 时进行触发。
三级缓存解决循环依赖问题
1、@SpringBoot
声明bean的注解
@Component 通⽤的注解，可标注任意类为 Spring 组件
@Service 在业务逻辑层使用（service层）
@Repository 在数据访问层使用（dao层）
@Controller 在展现层使用，控制器的声明（controller层）
注入bean的注解
@Autowired：默认按照类型来装配注入，**@Qualifier**：可以改成名称
@Resource：默认按照名称来装配注入，JDK的注解，新版本已经弃用
@Autowired注解原理
@Autowired的使用简化了我们的开发，
实现 AutowiredAnnotationBeanPostProcessor 类，该类实现了 Spring 框架的一些扩展接口。
实现 BeanFactoryAware 接口使其内部持有了 BeanFactory（可轻松的获取需要依赖的的 Bean）。
实现 MergedBeanDefinitionPostProcessor 接口，实例化Bean 前获取到 里面的 @Autowired 信息并缓存下来；
实现 postProcessPropertyValues 接口， 实例化Bean 后从缓存取出注解信息，通过反射将依赖对象设置到 Bean 属性里面。
@SpringBootApplication
@SpringBootApplicationpublic class JpaApplication { public static void main(String[] args) { SpringApplication.run(JpaApplication.class, args); }}
@SpringBootApplication注解等同于下面三个注解：
其中@EnableAutoConfiguration是关键(启用自动配置)，内部实际上就去加载META-INF/spring.factories文件的信息，然后筛选出以EnableAutoConfiguration为key的数据，加载到IOC容器中，实现自动配置功能！
它主要加载了@SpringBootApplication注解主配置类，这个@SpringBootApplication注解主配置类里边最主要的功能就是SpringBoot开启了一个@EnableAutoConfiguration注解的自动配置功能。
@EnableAutoConfiguration作用：
它主要利用了一个
EnableAutoConfigurationImportSelector选择器给Spring容器中来导入一些组件。
@Import(EnableAutoConfigurationImportSelector.class)public @interface EnableAutoConfiguration
2、@SpringMVC
@Controller 声明该类为SpringMVC中的Controller@RequestMapping 用于映射Web请求@ResponseBody 支持将返回值放在response内，而不是一个页面，通常用户返回json数据@RequestBody 允许request的参数在request体中，而不是在直接连接在地址后面。@PathVariable 用于接收路径参数@RequestMapping("/hello/{name}")申明的路径，将注解放在参数中前，即可获取该值，通常作为Restful的接口实现方法。
SpringMVC原理
3、@SpringMybatis
@Insert ： 插入sql ,和xml insert sql语法完全一样@Select ： 查询sql, 和xml select sql语法完全一样@Update ： 更新sql, 和xml update sql语法完全一样@Delete ： 删除sql, 和xml delete sql语法完全一样@Param ： 入参@Results ： 设置结果集合@Result ： 结果@ResultMap ： 引用结果集合@SelectKey ： 获取最新插入id
mybatis如何防止sql注入？
简单的说就是#{}是经过预编译的，是安全的，****{}是未经过预编译的，仅仅是取变量的值，是非安全的，存在SQL注入。在编写mybatis的映射语句时，尽量采用**“#{xxx}”**这样的格式。如果需要实现动态传入表名、列名，还需要做如下修改：添加属性**statementType="STATEMENT"**，同时sql里的属有变量取值都改成****{}是未经过预编译的，仅仅是取变量的值，是非安全的，存在SQL注入。在编写mybatis的映射语句时，尽量采用**“#{xxx}”**这样的格式。如果需要实现动态传入表名、列名，还需要做如下修改：添加属性**statementType="STATEMENT"**，同时sql里的属有变量取值都改成**{xxxx}**
Mybatis和Hibernate的区别
Hibernate 框架：
Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,建立对象与数据库表的映射。是一个全自动的、完全面向对象的持久层框架。
Mybatis框架：
Mybatis是一个开源对象关系映射框架，原名：ibatis,2010年由谷歌接管以后更名。是一个半自动化的持久层框架。
区别：
开发方面
在项目开发过程当中，就速度而言：
hibernate开发中，sql语句已经被封装，直接可以使用，加快系统开发；
Mybatis 属于半自动化，sql需要手工完成，稍微繁琐；
但是，凡事都不是绝对的，如果对于庞大复杂的系统项目来说，复杂语句较多，hibernate 就不是好方案。
sql优化方面
Hibernate 自动生成sql,有些语句较为繁琐，会多消耗一些性能；
Mybatis 手动编写sql，可以避免不需要的查询，提高系统性能；
对象管理比对
Hibernate 是完整的对象-关系映射的框架，开发工程中，无需过多关注底层实现，只要去管理对象即可；
Mybatis 需要自行管理映射关系；
4、@Transactional
@EnableTransactionManagement @Transactional
注意事项：
①事务函数中不要处理耗时任务，会导致长期占有数据库连接。
②事务函数中不要处理无关业务，防止产生异常导致事务回滚。
事务传播属性
1) REQUIRED（默认属性） 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。
7) NESTED （局部回滚） 支持当前事务，新增Savepoint点，与当前事务同步提交或回滚。 嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。
1、Spring中的设计模式
参考：spring中的设计模式
单例设计模式 : Spring 中的 Bean 默认都是单例的。
⼯⼚设计模式 : Spring使⽤⼯⼚模式通过 BeanFactory 、 ApplicationContext 创建bean 对象。
代理设计模式 : Spring AOP 功能的实现。
观察者模式： Spring 事件驱动模型就是观察者模式很经典的⼀个应⽤。
适配器模式：Spring AOP 的增强或通知(Advice)使⽤到了适配器模式、spring MVC 中也是⽤到了适配器模式适配 Controller 。
Why SpringCloud
Spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。
| SpringCloud（微服务解决方案） |
Dubbo（分布式服务治理框架） |
| Rest API （轻量、灵活、swagger） |
RPC远程调用（高效、耦合） |
| Eureka、Nacos |
Zookeeper |
| 使用方便 |
性能好 |
| 即将推出SpringCloud2.0 |
断档5年后17年重启 |
SpringBoot是Spring推出用于解决传统框架配置文件冗余,装配组件繁杂的基于Maven的解决方案,旨在快速搭建单个微服务，SpringCloud是依赖于SpringBoot的,而SpringBoot并不是依赖与SpringCloud,甚至还可以和Dubbo进行优秀的整合开发
MartinFlower 提出的微服务之间是通过RestFulApi进行通信，具体实现
Spring Boot
Spring Boot 通过简单的步骤就可以创建一个 Spring 应用。
Spring Boot 为 Spring 整合第三方框架提供了开箱即用功能。
Spring Boot 的核心思想是约定大于配置。
Spring Boot 解决的问题
Spring Boot 优点
自动装配：Spring Boot 会根据某些规则对所有配置的 Bean 进行初始化。可以减少了很多重复性的工作。
比如使用 MongoDB 时，只需加入 MongoDB 的 Starter 包，然后配置 的连接信息，就可以直接使用 MongoTemplate 自动装配来操作数据库了。简化了 Maven Jar 包的依赖，降低了烦琐配置的出错几率。
内嵌容器：Spring Boot 应用程序可以不用部署到外部容器中，比如 Tomcat。
应用程序可以直接通过 Maven 命令编译成可执行的 jar 包，通过 java-jar 命令启动即可，非常方便。
应用监控：Spring Boot 中自带监控功能 Actuator，可以实现对程序内部运行情况进行监控，
比如 Bean 加载情况、环境变量、日志信息、线程信息等。当然也可以自定义跟业务相关的监控，通过Actuator 的端点信息进行暴露。
spring-boot-starter-web //用于快速构建基于 Spring MVC 的 Web 项目。spring-boot-starter-data-redis //用于快速整合并操作 Redis。spring-boot-starter-data-mongodb //用于对 MongoDB 的集成。spring-boot-starter-data-jpa //用于操作 MySQL。
自定义一个Starter
Spring Boot Admin（将 actuator 提供的数据进行可视化）
GateWay / Zuul
GateWay⽬标是取代Netflflix Zuul，它基于Spring5.0+SpringBoot2.0+WebFlux等技术开发，提供统⼀的路由⽅式（反向代理）并且基于 Filter(定义过滤器对请求过滤，完成⼀些功能) 链的⽅式提供了⽹关基本的功能，例如：鉴权、流量控制、熔断、路径重写、⽇志监控。
组成：
GateWayFilter 应⽤到单个路由路由上 、GlobalFilter 应⽤到所有的路由上
Eureka / Zookeeper
服务注册中⼼本质上是为了解耦服务提供者和服务消费者，为了⽀持弹性扩缩容特性，⼀个微服务的提供者的数量和分布往往是动态变化的。
| 区别 |
Zookeeper |
Eureka |
Nacos |
| CAP |
CP |
AP |
CP/AP切换 |
| 可用性 |
选举期间不可用 |
自我保护机制，数据不是最新的 |
|
| 组成 |
Leader和Follower |
节点平等 |
|
| 优势 |
分布式协调 |
注册与发现 |
注册中心和配置中心 |
| 底层 |
进程 |
服务 |
Jar包 |
Eureka通过⼼跳检测、健康检查和客户端缓存等机制，提⾼系统的灵活性、可伸缩性和可⽤性。
Eureka缓存
新服务上线后，服务消费者不能立即访问到刚上线的新服务，需要过⼀段时间后才能访问？或是将服务下线后，服务还是会被调⽤到，⼀段时候后才彻底停⽌服务，访问前期会导致频繁报错！
服务注册到注册中⼼后，服务实例信息是存储在Registry表中的，也就是内存中。但Eureka为了提⾼响应速度，在内部做了优化，加⼊了两层的缓存结构，将Client需要的实例信息，直接缓存起来，获取的时候直接从缓存中拿数据然后响应给 Client。
解决方案
自我保护机制开启条件
健康检查
Feign / Ribbon
Feign最佳使用技巧
Ribbon
使用方式
负载均衡算法
自定义负载均衡算法
自定义负载均衡使用场景（核心）
Hystrix / Sentinel
服务雪崩场景
自己即是服务消费者，同时也是服务提供者，同步调用等待结果导致资源耗尽
解决方案
服务方：扩容、限流，排查代码问题，增加硬件监控
消费方：使用Hystrix资源隔离，熔断降级，快速失败
Hystrix断路保护器的作用
Hystrix使用上遇到的坑
[^常见问题]: Hystrix的超时时间要⼤于Ribbon的超时时间，因为Hystrix将请求包装了起来，特别需要注意的是，如果Ribbon开启了重试机制，⽐如重试3 次，Ribbon 的超时为 1 秒，那么Hystrix 的超时时间应该⼤于 3 秒，否则就会出现 Ribbon 还在重试中，⽽ Hystrix 已经超时的现象。
Sentinel
Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。
替代Hystrix，针对问题：服务雪崩、服务降级、服务熔断、服务限流
Hystrix区别：
丰富的应⽤场景：Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景，例如秒杀、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。
完备的实时监控：可以看到500 台以下规模的集群的汇总也可以看到单机的秒级数据。
⼴泛的开源⽣态：与 SpringCloud、Dubbo的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊ Sentinel。
区别：
| # |
Sentinel |
Hystrix |
| 隔离策略 |
信号量隔离 |
线程池隔离/信号量隔离 |
| 熔断降级策略 |
基于响应时间或失败比率 |
基于失败比率 |
| 实时指标实现 |
滑动窗口 |
滑动窗口（基于 RxJava） |
| 扩展性 |
多个扩展点 |
插件的形式 |
| 限流 |
基于 QPS，支持基于调用关系的限流 |
不支持 |
| 流量整形 |
支持慢启动、匀速器模式 |
不支持 |
| 系统负载保护 |
支持 |
不支持 |
| 控制台 |
开箱即用，可配置规则、查看秒级监控、机器发现等 |
不完善 |
| 常见框架的适配 |
Servlet、Spring Cloud、Dubbo、gRPC |
Servlet、Spring Cloud Netflix |
Config / Nacos
Nacos是阿⾥巴巴开源的⼀个针对微服务架构中服务发现、配置管理和服务管理平台。
Nacos就是注册中⼼+配置中⼼的组合（Nacos=Eureka+Confifig+Bus）
Nacos功能特性
保护阈值：
当服务A健康实例数/总实例数 < 保护阈值 的时候，说明健康实例真的不多了，这个时候保护阈值会被触发（状态true），nacos将会把该服务所有的实例信息（健康的+不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样也⽐造成雪崩要好，牺牲了⼀些请求，保证了整个系统的⼀个可⽤。
Nacos 数据模型（领域模型）
可以通过 Spring Cloud 原⽣注解 @RefreshScope 实现配置⾃动更新
Bus / Stream
Spring Cloud Stream 消息驱动组件帮助我们更快速，更⽅便的去构建消息驱动微服务的
本质：屏蔽掉了底层不同MQ消息中间件之间的差异，统⼀了MQ的编程模型，降低了学习、开发、维护MQ的成本，⽬前⽀持Rabbit、Kafka两种消息
Sleuth / Zipkin
全链路追踪
Trace ID：当请求发送到分布式系统的⼊⼝端点时，Sleuth为该请求创建⼀个唯⼀的跟踪标识Trace ID，在分布式系统内部流转的时候，框架始终保持该唯⼀标识，直到返回给请求⽅
Span ID：为了统计各处理单元的时间延迟，当请求到达各个服务组件时，也是通过⼀个唯⼀标识SpanID来标记它的开始，具体过程以及结束。
Spring Cloud Sleuth （追踪服务框架）可以追踪服务之间的调⽤，Sleuth可以记录⼀个服务请求经过哪些服务、服务处理时⻓等，根据这些，我们能够理清各微服务间的调⽤关系及进⾏问题追踪分析。
耗时分析：通过 Sleuth 了解采样请求的耗时，分析服务性能问题（哪些服务调⽤⽐较耗时）
链路优化：发现频繁调⽤的服务，针对性优化等
聚合展示：数据信息发送给 Zipkin 进⾏聚合，利⽤ Zipkin 存储并展示数据。
JWT（JSON Web Token）用户提供用户名和密码给认证服务器，服务器验证用户提交信息的合法性；如果验证成功，会产生并返回一个 Token，用户可以使用这个 Token 访问服务器上受保护的资源。
Token最佳实践
痛点：
可以通过Ribbon的负载均衡策略进行灰度发布，可以使用更可靠的Discovery
Discovery
基于Discovery 服务注册发现、Ribbon 负载均衡、Feign 和 RestTemplate 调用等组件的企业级微服务开源解决方案，包括灰度发布、灰度路由、服务隔离等功能
grayVersions = {"discovery-article-service":["1.01"]}
本地复用测试服务-Eureka Zone亮点
region 地理上的分区，比如北京、上海等
zone 可以简单理解为 region 内的具体机房
在调用的过程中会优先选择相同的 zone 发起调用，当找不到相同名称的 zone 时会选择其他的 zone 进行调用，我们可以利用这个特性来解决本地需要启动多个服务的问题。
[^]: 当你访问修改的服务 A 时，这个服务依赖了 B、C 两个服务，B 和 C 本地没有启动，B 和 C 找不到相同的 zone 就会选择其他的 zone 进行调用，也就是会调用到测试环境部署的 B 和 C 服务，这样一来就解决了本地部署多个服务的问题。
各组件调优
当你对网关进行压测时，会发现并发量一直上不去，错误率也很高。因为你用的是默认配置，这个时候我们就需要去调整配置以达到最优的效果。
首先我们可以对容器进行调优，最常见的就是内置的 Tomcat 容器了，
server.tomcat.accept-count //请求队列排队数server.tomcat.max-threads //最大线程数server.tomcat.max-connections //最大连接数
Hystrix 的信号量（semaphore）隔离模式，并发量上不去很大的原因都在这里，信号量默认值是 100，也就是最大并发只有 100，超过 100 就得等待。
//信号量zuul.semaphore.max-semaphores //信号量：最大并发数//线程池hystrix.threadpool.default.coreSize //最大线程数hystrix.threadpool.default.maximumSize //队列的大hystrix.threadpool.default.maxQueueSize //等参数
配置Gateway并发信息，
gateway.host.max-per-route-connections //每个路由的连接数 gateway.host.max-total-connections //总连接数
调整Ribbon 的并发配置，
ribbon.MaxConnectionsPerHost //单服务并发数ribbon.MaxTotalConnections //总并发数
修改Feign默认的HttpURLConnection 替换成 httpclient 来提高性能
feign.httpclient.max-connections-per-route//每个路由的连接数feign.httpclient.max-connections //总连接数
Gateway+配置中心实现动态路由
Feign+配置中心实现动态日志
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
XA方案
2PC协议：两阶段提交协议，P是指准备阶段，C是指提交阶段
3PC协议：将提交阶段分为CanCommit、PreCommit、DoCommit三个阶段
CanCommit：发送canCommit请求，并开始等待
PreCommit：收到全部Yes，写Undo、Redo日志。超时或者No，则中断
DoCommit：执行Redo日志进行Commit，执行Undo日志进行Rollback
区别是第二步，参与者自身增加了超时，如果失败可以及时释放资源
Paxos算法
如何在一个发生异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致
参与者（例如Kafka）的一致性可以由协调者（例如Zookeeper）来保证，协调者的一致性就只能由Paxos保证了
Paxos算法中的角色：
//算法约束P1:一个Acceptor必须接受它收到的第一个提案。//考虑到半数以上才作数，一个Accpter得接受多个相同v的提案P2a:如果某个v的提案被accept，那么被Acceptor接受编号更高的提案必须也是vP2b:如果某个v的提案被accept，那么从Proposal提出编号更高的提案必须也是v//如何确保v的提案Accpter被选定后，Proposal都能提出编号更高的提案呢针对任意的[Mid,Vid]，有半数以上的Accepter集合S，满足以下二选一： S中接受的提案都大于Mid S中接受的提案若小于Mid，编号最大的那个值为Vid
面试题：如何保证Paxos算法活性
假设存在这样一种极端情况，有两个Proposer依次提出了一系列编号递增的提案，导致最终陷入死循环，没有value被选定
ZAB算法
Raft算法
Raft 是一种为了管理复制日志的一致性算法
Raft使用心跳机制来触发选举。当server启动时，初始状态都是follower。每一个server都有一个定时器，超时时间为election timeout（一般为150-300ms），如果某server没有超时的情况下收到来自领导者或者候选者的任何消息，定时器重启，如果超时，它就开始一次选举。
Leader异常：异常期间Follower会超时选举，完成后Leader比较彼此步长
Follower异常：恢复后直接同步至Leader当前状态
多个Candidate：选举时失败，失败后超时继续选举
数据库和Redis的一致性
全量缓存保证高效读取
所有数据都存储在缓存里，读服务在查询时不会再降级到数据库里，所有的请求都完全依赖缓存。此时，因降级到数据库导致的毛刺问题就解决了。但全量缓存并没有解决更新时的分布式事务问题，反而把问题放大了。因为全量缓存对数据更新要求更加严格，要求所有数据库已有数据和实时更新的数据必须完全同步至缓存，不能有遗漏。对于此问题，一种有效的方案是采用订阅数据库的 Binlog 实现数据同步
现在很多开源工具（如阿里的 Canal等）可以模拟主从复制的协议。通过模拟协议读取主数据库的 Binlog 文件，从而获取主库的所有变更。对于这些变更，它们开放了各种接口供业务服务获取数据。
将 Binlog 的中间件挂载至目标数据库上，就可以实时获取该数据库的所有变更数据。对这些变更数据解析后，便可直接写入缓存里。优点还有：
缺点不可避免：1、增加复杂度 2、消耗缓存资源 3、需要筛选和压缩数据 4、极端情况数据丢失
可以通过异步校准方案进行补齐，但是会损耗数据库性能。但是此方案会隐藏中间件使用错误的细节，线上环境前期更重要的是记录日志排查在做后续优化，不能本末倒置。
心跳检测
以固定的频率向其他节点汇报当前节点状态的方式。收到心跳，说明网络和节点的状态是健康的。心跳汇报时，一般会携带一些附加的状态、元数据，以便管理
周期检测心跳机制：超时未返回
累计失效检测机制：重试超次数
多机房实时热备
两套缓存集群可以分别部署到不同城市的机房。读服务也相应地部署到不同城市或不同分区。在承接请求时，不同机房或分区的读服务只依赖同样属性的缓存集群。此方案有两个好处。
此方案虽然带来了性能和可用性的提升，但代价是资源成本的上升。
分布式系统对于错误包容的能力
通过限流、降级、兜底、重试、负载均衡等方式增强系统的健壮性
日志复制
主备（Master-Slave）
主机宕机时，备机接管主机的一切工作，主机恢复正常后，以自动（热备）或手动（冷备）方式将服务切换到主机上运行，Mysql和Redis中常用。
MySQL之间数据复制的基础是二进制日志文件（binary log fifile）。它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制
互备（Active-Active）
指两台主机同时运行各自的服务工作且相互监测情况。在数据库高可用部分，常见的互备是MM模式。MM模式即Multi-Master模式，指一个系统存在多个master，每个master都具有read-write能力，会根据时间戳或业务逻辑合并版本。
集群（Cluster）模式
是指有多个节点在运行，同时可以通过主控节点分担服务请求。如Zookeeper。集群模式需要解决主控节点本身的高可用问题，一般采用主备模式。
XA方案
两阶段提交 | 三阶段提交
TCC方案
Try Confirm Cancel / 短事务
Saga方案
事务性补偿 / 长事务
本地消息表（eBay）
MQ最终一致性
比如阿里的 RocketMQ 就支持消息事务（核心：双端确认，重试幂等）
最大努力通知方案（订单 -> 积分）
你找一个严格资金要求绝对不能错的场景，你可以说你是用的 TCC 方案；
如果是一般的分布式事务场景，例如积分数据，可以用可靠消息最终一致性方案
如果分布式场景允许不一致，可以使用最大努力通知方案
分布式Session实现方案
Elasticsearch可以实现秒级的搜索，cluster是一种分布式的部署，极易扩展(scale )这样很容易使它处理PB级的数据库容量。最重要的是Elasticsearch是它搜索的结果可以按照分数进行排序，它能提供我们最相关的搜索结果（relevance) 。
Lucene
Java编写的信息搜索工具包（Jar包），Lucene只是一个框架，熟练运用Lucene非常复杂。
Solr
基于Lucene的HTTP接口查询服务器，是一个封装了很多Lucene细节搜索引擎系统
Elasticsearch
基于Lucene分布式海量数据近实时搜索引擎。采用的策略是将每一个字段都编入索引，使其可以被搜索。
1）Solr利用Zookeeper进行分布式管理，而Elasticsearch自身带有分布式协调管理功能
2）Solr比Elasticsearch实现更加全面，而Elasticsearch本身更注重于核心功能， 高级功能多由第三方插件提供
3）Solr在传统的搜索应用中表现好于Elasticsearch，而Elasticsearch在实时搜索应用方面比Solr表现好
目前主流依然是Elasticsearch7.x 最新的是7.8
优化：默认集成JDK、升级Lucene8大幅提升TopK性能、引入熔断机制避免OOM发生
IKAnalyzer是一个开源的，基于java语言开发的轻量级的中文分词工具包。新版本的IKAnalyzer3.0则发展为 面向Java的公用分词组件，独立于Lucene项目，同时提供了对Lucene的默认优化实现。
IK分词器3.0的特性如下：
settings：设置索引库，定义索引库的分片数副本数等
地理坐标点数据类型
地理坐标点是指地球表面可以用经纬度描述的一个点。 地理坐标点可以用来计算两个坐标间的距离，还可以判断一个坐标是否在一个区域中。地理坐标点需要显式声明对应字段类型为 geo_point
动态映射
使用dynamic mapping 来确定字段的数据类型并自动把新的字段添加到类型映射
聚合分析是数据库中重要的功能特性，完成对一个查询的数据集中数据的聚合计算，如：找出某字段（或计算表达式的结果）的最大值、最小值，计算和、平均值等
如果Completion Suggester已经到了零匹配，可以猜测用户有输入错误，这时候可以尝试一下Phrase Suggester。如果还是未匹配则尝试Term Suggester。
精准程度上(Precision)看： Completion > Phrase > Term， 而召回率上(Recall)则反之。
从性能上看，Completion Suggester是最快的，如果能满足业务需求，只用Completion Suggester做前缀匹配是最理想的。 Phrase和Term由于是做倒排索引的搜索，相比较而言性能应该要低不少，应尽量控制Suggester用到的索引的数据量，最理想的状况是经过一定时间预热后，索引可以全量map到内存。
参与度 & 灵活性：自研 > scroll+bulk > reindex
稳定性 & 可靠性：自研 < scroll+bulk < reindex
比如超级管理员，要给某个省份用户发送公告或者广告，最容易想到的就是利用 from + size 来实现，但这是不现实的
chroot 是在 Unix 和 Linux 系统的一个操作，针对正在运作的软件行程和它的子进程，改变它外显的根目录。一个运行在这个环境下，经由 chroot 设置根目录的程序，它不能够对这个指定根目录之外的文件进行访问动作，不能读取，也不能更改它的内容。
虚拟化技术_VMware 、VirtualBox、KVM
虚拟化技术就是在操作系统上多加了一个虚拟化层（Hypervisor），可以将物理机的CPU、内存、硬盘、网络等资源进行虚拟化，再通过虚拟化出来的空间上安装操作系统，构建虚拟的应用程序执行环境。这就是我们通常说的虚拟机。
虚拟机的优点：
虚拟机的缺点：
场景
需求
快速，一致地交付应用程序、镜像打包环境，避免了环境不一致的问题，简化开发的生命周期，适合于快速迭代敏捷开发的场景
Docker引擎-守护进程
Docker使用C / S架构 ：用户通过Docker客户端与Docker守护进程（Docker引擎）通过Unix套接字或者RESTAPI进行通信，Docker引擎完成了构建，运行和分发Docker容器的繁重工作
Docker镜像-Dockerfile
Docker镜像类似于虚拟机镜像，是一个只读的模板，是创建Docker容器的基础
镜像是基于联合（Union）文件系统的一种层式的结构，由一系列指令一步一步构建出来。
比如：拷贝文件、执行命令
Docker仓库-Hub
Docker仓库可以分为公开仓库 （Public）和私有仓库（Private）两种形式。
最大的公开仓库是官方提供的Docker Hub，其中存放了数量庞大的镜像供用户下载。
镜像
[root@localhost ~]# docker pull mysql:5.7.30 5.7.30: Pulling from library/mysql …… [root@localhost ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE mysql 5.7.30 9cfcce23593a 6 weeks ago 448MB [root@localhost ~]# docker tag mysql:5.7.30 mysql5 [root@localhost ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE mysql5 latest 9cfcce23593a 6 weeks ago 448MB mysql 5.7.30 9cfcce23593a 6 weeks ago 448MB [root@localhost ~]# docker inspect mysql:5.7.30 [{显示docker 详细信息}] [root@localhost ~]# docker search mysql [root@localhost ~]# docker rmi mysql:5.7.30 [root@localhost ~]# docker push mysql[:TAG]
容器
[root@localhost ~]# docker create -it nginx [root@localhost ~]# docker start 9cfcce23593a #查看运行的容器 [root@localhost ~]# docker ps #查看所有容器 [root@localhost ~]# docker ps -a #新建并启动容器 [root@localhost ~]# docker run -it --rm --network host tomcat:8.5.56-jdk8-openjdk
挂载在容器 /test 目录内创建。 Docker 不支持容器内安装点的相对路径。 多个容器可以在同一时间段内使用相同的卷。如果两个容器需要访问共享数据，例如，如果一个容器写入而另一个容器读取数据。 卷名 在驱动程序test必须唯一。这意味着不能将相同的卷名与两个不同的驱动程序一起使用。 如果我们指定了当前test_volume程序上已在使用的卷名，则Docker会假定我们要重用现有卷，并且不会返回错误。如果开始无 test_volume 则会创建这个卷当然除了使用卷，也可以使用将宿主机的文件映射到容器的卷，命令类似，只不过不用提前创建卷，而且数据会映射到宿主机上注意如果宿主机上的目录可以不存在，会在启动容器的时候创建
1、整体结构
Core 核心层
Core 核心层是 Netty 最精华的内容，它提供了底层网络通信的通用抽象和实现，包括事件模型、通用API、支持零拷贝的 ByteBuf 等。
Protocol Support 协议支持层
协议支持层基本上覆盖了主流协议的编解码实现，如 HTTP、Protobuf、WebSocket、二进制等主流协议，此外 Netty 还支持自定义应用层协议。Netty 丰富的协议支持降低了用户的开发成本，基于 Netty 我们可以快速开发 HTTP、WebSocket 等服务。
Transport Service 传输服务层
传输服务层提供了网络传输能力的定义和实现方法。它支持 Socket、HTTP 隧道、虚拟机管道等传输方式。Netty 对 TCP、UDP 等数据传输做了抽象和封装，用户可以更聚焦在业务逻辑实现上，而不必关系底层数据传输的细节。
2、逻辑架构
网络通信层
网络通信层的职责是执行网络 I/O 的操作。它支持多种网络协议和 I/O 模型的连接操作。当网络数据读取到内核缓冲区后，会触发各种网络事件，这些网络事件会分发给事件调度层进行处理。
网络通信层的核心组件包含BootStrap、ServerBootStrap、Channel三个组件。
Bootstrap 是“引导”的意思，负责 Netty 客户端程序的启动、初始化、服务器连接等过程，串联了 Netty 的其他核心组件。
ServerBootStrap 用于服务端启动绑定本地端口，会绑定Boss 和 Worker两个 EventLoopGroup。
Channel 的是“通道”，Netty Channel提供了基于NIO更高层次的抽象，如 register、bind、connect、read、write、flush 等。
事件调度层
事件调度层的职责是通过 Reactor 线程模型对各类事件进行聚合处理，通过 Selector 主循环线程集成多种事件（ I/O 事件、信号事件、定时事件等），实际的业务处理逻辑是交由服务编排层中相关的 Handler 完成。
事件调度层的核心组件包括 EventLoopGroup、EventLoop。
EventLoop 负责处理 Channel 生命周期内的所有 I/O 事件，如 accept、connect、read、write 等 I/O 事件
①一个 EventLoopGroup 往往包含一个或者多个 EventLoop。
②EventLoop 同一时间会与一个Channel绑定，每个 EventLoop 负责处理一种类型 Channel。
③Channel 在生命周期内可以对和多个 EventLoop 进行多次绑定和解绑。
EventLoopGroup 是Netty 的核心处理引擎，本质是一个线程池，主要负责接收 I/O 请求，并分配线程执行处理请求。通过创建不同的 EventLoopGroup 参数配置，就可以支持 Reactor 的三种线程模型：
单线程模型：EventLoopGroup 只包含一个 EventLoop，Boss 和 Worker 使用同一个EventLoopGroup；
多线程模型：EventLoopGroup 包含多个 EventLoop，Boss 和 Worker 使用同一个EventLoopGroup；
主从多线程模型：EventLoopGroup 包含多个 EventLoop，Boss 是主 Reactor，Worker 是从 Reactor，它们分别使用不同的 EventLoopGroup，主 Reactor 负责新的网络连接 Channel 创建，然后把 Channel 注册到从 Reactor。
服务编排层
服务编排层的职责是负责组装各类服务，它是 Netty 的核心处理链，用以实现网络事件的动态编排和有序传播。
服务编排层的核心组件包括 ChannelPipeline、ChannelHandler、ChannelHandlerContext。
ChannelPipeline 是 Netty 的核心编排组件，负责组装各种 ChannelHandler，ChannelPipeline 内部通过双向链表将不同的 ChannelHandler 链接在一起。当 I/O 读写事件触发时，Pipeline 会依次调用 Handler 列表对 Channel 的数据进行拦截和处理。
客户端和服务端都有各自的 ChannelPipeline。客户端和服务端一次完整的请求：客户端出站（Encoder 请求数据）、服务端入站（Decoder接收数据并执行业务逻辑）、服务端出站（Encoder响应结果）。
ChannelHandler 完成数据的编解码以及处理工作。
ChannelHandlerContext 用于保存Handler 上下文，通过 HandlerContext 我们可以知道 Pipeline 和 Handler 的关联关系。HandlerContext 可以实现 Handler 之间的交互，HandlerContext 包含了 Handler 生命周期的所有事件，如 connect、bind、read、flush、write、close 等。同时，HandlerContext 实现了Handler通用的逻辑的模型抽象。
1、五种IO模型的区别
阻塞I/O：（BIO）
应用进程向内核发起 I/O 请求，发起调用的线程一直等待内核返回结果。一次完整的 I/O 请求称为BIO（Blocking IO，阻塞 I/O），所以 BIO 在实现异步操作时，只能使用多线程模型，一个请求对应一个线程。但是，线程的资源是有限且宝贵的，创建过多的线程会增加线程切换的开销。
同步非阻塞I/O（NIO）：
应用进程向内核发起 I/O 请求后不再会同步等待结果，而是会立即返回，通过轮询的方式获取请求结果。NIO 相比 BIO 虽然大幅提升了性能，但是轮询过程中大量的系统调用导致上下文切换开销很大。所以，单独使用非阻塞 I/O 时效率并不高，而且随着并发量的提升，非阻塞 I/O 会存在严重的性能浪费。
多路复用I/O（select和poll）：
多路复用实现了一个线程处理多个 I/O 句柄的操作。多路指的是多个数据通道，复用指的是使用一个或多个固定线程来处理每一个 Socket。select、poll、epoll 都是 I/O 多路复用的具体实现，线程一次 select 调用可以获取内核态中多个数据通道的数据状态。其中，select只负责等，recvfrom只负责拷贝，阻塞IO中可以对多个文件描述符进行阻塞监听，是一种非常高效的 I/O 模型。
信号驱动I/O（SIGIO）：
信号驱动IO模型，应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGIO信号进行捕捉，并且调用我的信号处理函数来获取数据报。
异步I/O（Posix.1的aio_系列函数）：
当应用程序调用aio_read时，内核一方面去取数据报内容返回，另一方面将程序控制权还给应用进程，应用进程继续处理其他事情，是一种非阻塞的状态。当内核中有数据报就绪时，由内核将数据报拷贝到应用程序中，返回aio_read中定义好的函数处理程序。
2、Reactor多线程模型
Netty 的 I/O 模型是基于非阻塞 I/O 实现的，底层依赖的是 NIO 框架的多路复用器 Selector。采用 epoll 模式后，只需要一个线程负责 Selector 的轮询。当有数据处于就绪状态后，需要一个事件分发器（Event Dispather），它负责将读写事件分发给对应的读写事件处理器（Event Handler）。事件分发器有两种设计模式：Reactor 和 Proactor，Reactor 采用同步 I/O， Proactor 采用异步 I/O。
Reactor 实现相对简单，适合处理耗时短的场景，对于耗时长的 I/O 操作容易造成阻塞。Proactor 性能更高，但是实现逻辑非常复杂，适合图片或视频流分析服务器，目前主流的事件驱动模型还是依赖 select 或 epoll 来实现。
3、拆包粘包问题
拆包TCP 传输协议是面向流的，没有数据包界限。
MTU（Maxitum Transmission Unit） 是链路层一次最大传输数据的大小。MTU 一般来说大小为 1500 byte。MSS（Maximum Segement Size） 是指 TCP 最大报文段长度，它是传输层一次发送最大数据的大小。
如上图所示，如果 MSS + TCP 首部 + IP 首部 > MTU，那么数据包将会被拆分为多个发送。这就是拆包现象。
Nagle 算法
Nagle 算法可以理解为批量发送，也是我们平时编程中经常用到的优化思路，它是在数据未得到确认之前先写入缓冲区，等待数据确认或者缓冲区积攒到一定大小再把数据包发送出去。Netty 中为了使数据传输延迟最小化，就默认禁用了 Nagle 算法。
拆包/粘包的解决方案
在客户端和服务端通信的过程中，服务端一次读到的数据大小是不确定的。需要确定边界：
消息长度固定
特定分隔符
消息长度 + 消息内容(Netty)
4、自定义协议
Netty 常用编码器类型：
MessageToByteEncoder //对象编码成字节流； MessageToMessageEncoder //一种消息类型编码成另外一种消息类型。
Netty 常用解码器类型：
ByteToMessageDecoder/ReplayingDecoder //将字节流解码为消息对象； MessageToMessageDecoder //将一种消息类型解码为另外一种消息类型。
编解码器可以分为一次解码器和二次解码器，一次解码器用于解决 TCP 拆包/粘包问题，按协议解析后得到的字节数据。如果你需要对解析后的字节数据做对象模型的转换，这时候便需要用到二次解码器，同理编码器的过程是反过来的。
Netty自定义协议内容：
/* +---------------------------------------------------------------+ | 魔数 2byte | 协议版本号 1byte | 序列化算法 1byte | 报文类型 1byte | +---------------------------------------------------------------+ | 状态 1byte | 保留字段 4byte | 数据长度 4byte | +---------------------------------------------------------------+ | 数据内容 （长度不定） | +---------------------------------------------------------------+ */
如何判断 ByteBuf 是否存在完整的报文？最常用的做法就是通过读取消息长度 dataLength 进行判断。如果 ByteBuf 的可读数据长度小于 dataLength，说明 ByteBuf 还不够获取一个完整的报文。
5、WriteAndFlush
①writeAndFlush 属于出站操作，它是从 Pipeline 的 Tail 节点开始进行事件传播，一直向前传播到 Head 节点。不管在 write 还是 flush 过程，Head 节点都中扮演着重要的角色。
②write 方法并没有将数据写入 Socket 缓冲区，只是将数据写入到 ChannelOutboundBuffer 缓存中，ChannelOutboundBuffer 缓存内部是由单向链表实现的。
③flush 方法才最终将数据写入到 Socket 缓冲区。
1、堆外内存
在 Java 中对象都是在堆内分配的，通常我们说的JVM 内存也就指的堆内内存，堆内内存完全被JVM 虚拟机所管理，JVM 有自己的垃圾回收算法，对于使用者来说不必关心对象的内存如何回收。堆外内存与堆内内存相对应，对于整个机器内存而言，除堆内内存以外部分即为堆外内存。堆外内存不受 JVM 虚拟机管理，直接由操作系统管理。使用堆外内存有如下几个优点：
在堆内存放的 DirectByteBuffer 对象并不大，仅仅包含堆外内存的地址、大小等属性，同时还会创建对应的 Cleaner 对象，通过 ByteBuffer 分配的堆外内存不需要手动回收，它可以被 JVM 自动回收。当堆内的 DirectByteBuffer 对象被 GC 回收时，Cleaner 就会用于回收对应的堆外内存。
从 DirectByteBuffer 的构造函数中可以看出，真正分配堆外内存的逻辑还是通过 unsafe.allocateMemory(size)，Unsafe 是一个非常不安全的类，它用于执行内存访问、分配、修改等敏感操作，可以越过 JVM 限制的枷锁。Unsafe 最初并不是为开发者设计的，使用它时虽然可以获取对底层资源的控制权，但也失去了安全性的保证，使用 Unsafe 一定要慎重（Java 中是不能直接使用 Unsafe 的，但是可以通过反射获取 Unsafe 实例）。Netty 中依赖了 Unsafe 工具类，是因为 Netty 需要与底层 Socket 进行交互，Unsafe 提升 Netty 的性能
因为DirectByteBuffer 对象的回收需要依赖 Old GC 或者 Full GC 才能触发清理，如果长时间没有 GC执行，那么堆外内存即使不再使用，也会一直在占用内存不释放，很容易将机器的物理内存耗尽。-XX:MaxDirectMemorySize 指定堆外内存的上限大小，超出时触发GC，仍无法释放抛出OOM异常。
当初始化堆外内存时，内存中的对象引用情况如下图所示，first 是 Cleaner 类中的静态变量，Cleaner 对象在初始化时会加入 Cleaner 链表中。DirectByteBuffer 对象包含堆外内存的地址、大小以及 Cleaner 对象的引用，ReferenceQueue 用于保存需要回收的 Cleaner 对象。
2、数据载体ByteBuf
JDK NIO 的 ByteBuffer
第一，ByteBuffer 分配的长度是固定的，无法动态扩缩容，每次在存放数据的时候对容量大小做校验，扩容需要将已有的数据迁移。
第二，ByteBuffer 只能通过 position 获取当前可操作的位置，因为读写共用的 position 指针，所以需要频繁调用 flip、rewind 方法切换读写状态。
Netty中的ByteBuf
引用计数
当byteBuf当引用计数为 0，该 ByteBuf 可以被放入到对象池中，避免每次使用 ByteBuf 都重复创建。
JVM 并不知道 Netty 的引用计数是如何实现的，当 ByteBuf 对象不可达时，一样会被 GC 回收掉，但是如果此时 ByteBuf 的引用计数不为 0，那么该对象就不会释放或者被放入对象池，从而发生了内存泄漏。Netty 会对分配的 ByteBuf 进行抽样分析，检测 ByteBuf 是否已经不可达且引用计数大于 0，判定内存泄漏的位置并输出到日志中，通过关注日志中 LEAK 关键字可以找到内存泄漏的具体对象。
3、内存分配jemalloc
为了减少分配时产生的内部碎片和外部碎片，常见的内存分配算法动态内存分配、伙伴算法和Slab 算法
动态内存分配（DMA）
⾸次适应算法（first fit），空闲分区链以地址递增的顺序将空闲分区以双向链表的形式连接在一起，从空闲分区链中找到第一个满足分配条件的空闲分区，然后从空闲分区中划分出一块可用内存给请求进程，剩余的空闲分区仍然保留在空闲分区链中。
循环首次适应算法（next fit）不再是每次从链表的开始进行查找，而是从上次找到的空闲分区的以后开始查找。查找效率提升，会产生更多的碎片。
最佳适应算法（best fit），空闲分区链以空闲分区大小递增的顺序将空闲分区以双向链表的形式连接在一起，每次从空闲分区链的开头进行查找。
伙伴算法（外部碎片少，内部碎片多）
是一种非常经典的内存分配算法，它采用了分离适配的设计思想，将物理内存按照 2 的次幂进行划分，内存分配时也是按照 2 的次幂大小进行按需分配
Slab 算法（解决伙伴算法内部碎片问题）
Slab 算法在伙伴算法的基础上，对小内存的场景专门做了优化，采用了内存池的方案，解决内部碎片问题。
在 Slab 算法中维护着大小不同的 Slab 集合，将这块内存划分为大小相同的 slot，不会对内存块再进行合并，同时使用位图 bitmap 记录每个 slot 的使用情况。
kmem_cache 中包含三个 Slab 链表：完全分配使用 slab_full、部分分配使用 slab_partial和完全空闲 slabs_empty，这三个链表负责内存的分配和释放。Slab 算法是基于对象进行内存管理的，它把相同类型的对象分为一类。当分配内存时，从 Slab 链表中划分相应的内存单元；单个 Slab 可以在不同的链表之间移动，例如当一个 Slab 被分配完，就会从 slab_partial 移动到 slabs_full，当一个 Slab 中有对象被释放后，就会从 slab_full 再次回到 slab_partial，所有对象都被释放完的话，就会从 slab_partial 移动到 slab_empty。当释放内存时，Slab 算法并不会丢弃已经分配的对象，而是将它保存在缓存中，当下次再为对象分配内存时，直接会使用最近释放的内存块。
4、jemalloc 架构
内存管理Arena ，内存由一定数量的 arenas 负责管理。每个用户线程采用 round-robin 轮询的方式选择可用的 arena 进行内存分配。
分级管理Bin，每个 bin 管理的内存大小是按分类依次递增。jemalloc 中小内存的分配是基于 Slab 算法完成的，会产生不同类别的内存块。
Page集合chunk，chunk 以 Page 为单位管理内存。每个 chunk 可被用于多次小内存的申请，但是在大内存分配的场景下只能分配一次。
实际分配单位run，run 结构具体的大小由不同的 bin 决定，例如 8 字节的 bin 对应的 run 只有一个 Page，可以从中选取 8 字节的块进行分配。
run 细分region，每个 run 会将划分为若干个等长的 region，每次内存分配也是按照 region 进行分发。
tcache 是每个线程私有的缓存，tcache 每次从 arena 申请一批内存，在分配内存时首先在 tcache 查找，避免锁竞争，分配失败才会通过 run 执行内存分配。
Small 场景，如果请求分配内存的大小小于 arena 中的最小的 bin，那么优先从线程中对应的 tcache 中进行分配。首先确定查找对应的 tbin 中是否存在缓存的内存块，如果存在则分配成功，否则找到 tbin 对应的 arena，从 arena 中对应的 bin 中分配 region 保存在 tbin 的 avail 数组中，最终从 availl 数组中选取一个地址进行内存分配，当内存释放时也会将被回收的内存块进行缓存。
Large 场景的内存分配与 Smalll 类似，如果请求分配内存的大小大于 arena 中的最小的 bin，但是不大于 tcache 中能够缓存的最大块，依然会通过 tcache 进行分配，但是不同的是此时会分配 chunk 以及所对应的 run，从 chunk 中找到相应的内存空间进行分配。内存释放时也跟 samll 场景类似，会把释放的内存块缓存在 tacache 的 tbin 中。此外还有一种情况，当请求分配内存的大小大于tcache 中能够缓存的最大块，但是不大于 chunk 的大小，那么将不会采用 tcache 机制，直接在 chunk 中进行内存分配。
Huge 场景，如果请求分配内存的大小大于 chunk 的大小，那么直接通过 mmap 进行分配，调用 munmap 进行回收。
5、内存池设计（待补充）
6、Recycle对象池（待补充）
7、零拷贝技术
在 Linux 中系统调用 sendfile() 可以实现将数据从一个文件描述符传输到另一个文件描述符，从而实现了零拷贝技术。
在 Java 中也使用了零拷贝技术，它就是 NIO FileChannel 类中的 transferTo() 方法，它可以将数据从 FileChannel 直接传输到另外一个 Channel。
Netty 中的零拷贝技术除了操作系统级别的功能封装，更多的是面向用户态的数据操作优化，主要体现在以下 5 个方面：
1、FastThreadLocal
ThreadLocal 可以理解为线程本地变量。ThreadLocal 为变量在每个线程中都创建了一个副本，该副本只能被当前线程访问，多线程之间是隔离的，变量不能在多线程之间共享。这样每个线程修改变量副本时，不会对其他线程产生影响。
既然多线程访问 ThreadLocal 变量时都会有自己独立的实例副本，那么很容易想到的方案就是在 ThreadLocal 中维护一个 Map，记录线程与实例之间的映射关系。当新增线程和销毁线程时都需要更新 Map 中的映射关系，因为会存在多线程并发修改，所以需要保证 Map 是线程安全的。但是在高并发的场景并发修改 Map 需要加锁，势必会降低性能。
JDK 为了避免加锁，采用了相反的设计思路。以 Thread 入手，在 Thread 中维护一个 Map，记录 ThreadLocal 与实例之间的映射关系，这样在同一个线程内，Map 就不需要加锁了。
ThreadLocalMap 是一种使用线性探测法实现的哈希表，底层采用数组存储数据，通过魔数0x61c88647来使散列更加平衡。ThreadLocalMap 初始化一个长度为 16 的 Entry 数组。与 HashMap 不同的是，Entry 的 key 就是 ThreadLocal对象本身，value 就是用户具体需要存储的值。
Entry 继承自弱引用类 WeakReference，Entry 的 key 是弱引用，value 是强引用。在 JVM 垃圾回收时，只要发现了弱引用的对象，不管内存是否充足，都会被回收。那么为什么 Entry 的 key 要设计成弱引用呢？如果 key 都是强引用，当线 ThreadLocal 不再使用时，然而 ThreadLocalMap 中还是存在对 ThreadLocal 的强引用，那么 GC 是无法回收的，从而造成内存泄漏。
虽然 Entry 的 key 设计成了弱引用，但是当 ThreadLocal不再使用(业务逻辑走完，但是由于线程复用导致线程并没有结束)被 GC 回收后，ThreadLocalMap 中可能出现 Entry 的 key 为 NULL，那么 Entry 的 value 一直会强引用数据而得不到释放，只能等待线程销毁。那么应该如何避免 ThreadLocalMap 内存泄漏呢？ThreadLocal 已经帮助我们做了一定的保护措施，在执行 ThreadLocal.set()/get() 方法时，ThreadLocal 会清除 ThreadLocalMap 中 key 为 NULL 的 Entry 对象，让它还能够被 GC 回收。除此之外，当线程中某个 ThreadLocal 对象不再使用时，立即调用 remove() 方法删除 Entry 对象。如果是在异常的场景中，应在 finally 代码块中进行清理，保持良好的编码意识。在Netty中，可以方便的使用FashThreadLocal来防止内存泄漏
FastThreadLocal
FastThreadLocal 使用 Object 数组替代了 Entry 数组，Object[0] 存储的是一个Set<FastThreadLocal<?>> 集合，从数组下标 1 开始都是直接存储的 value 数据，不再采用 ThreadLocal 的键值对形式进行存储。主要是针对set方法，增加了两个额外的行为。
2、HashedTimerWheel
生成月统计报表、每日得分结算、邮件定时推送
定时任务三种形式：
1、按固定周期定时执行
2、延迟一定时间后执行
3、指定某个时刻执行
定时任务的三个关键方法：
Schedule 新增任务至任务集合；
Cancel 取消某个任务；
Run 执行到期的任务
JDK自带的三种定时器：Timer、DelayedQueue 和 ScheduledThreadPoolExecutor
Timer小根堆队列，deadline 任务位于堆顶端，弹出的始终是最优先被执行的任务。Run 操作时间复杂度 O(1)，Schedule 和Cancel 操作的时间复杂度都是 O(logn)。
不论有多少任务被加入数组，始终由 异步线程TimerThread 负责处理。TimerThread 会定时轮询 TaskQueue 中的任务，如果堆顶的任务的 deadline 已到，那么执行任务；如果是周期性任务，执行完成后重新计算下一次任务的 deadline，并再次放入小根堆；如果是单次执行的任务，执行结束后会从 TaskQueue 中删除。
DelayedQueue 采用优先级队列 PriorityQueue延迟获取对象的阻塞队列。DelayQueue中的每个对象都必须实现Delayed 接口，并重写 compareTo 和 getDelay 方法。
DelayQueue 提供了 put() 和 take() 的阻塞方法，可以向队列中添加对象和取出对象。对象被添加到 DelayQueue 后，会根据 compareTo() 方法进行优先级排序。getDelay() 方法用于计算消息延迟的剩余时间，只有 getDelay <=0 时，该对象才能从 DelayQueue 中取出。
DelayQueue 在日常开发中最常用的场景就是实现重试机制。例如，接口调用失败或者请求超时后，可以将当前请求对象放入 DelayQueue，通过一个异步线程 take() 取出对象然后继续进行重试。如果还是请求失败，继续放回 DelayQueue。可以设置重试的最大次数以及采用指数退避算法设置对象的 deadline，如 2s、4s、8s、16s ……以此类推。DelayQueue的时间复杂度和Timer基本一致。
为了解决 Timer 的设计缺陷，JDK 提供了功能更加丰富的 ScheduledThreadPoolExecutor，多线程、相对时间、对异常
Timer 是单线程模式。如果某个 TimerTask 执行时间很久，会影响其他任务的调度。
Timer 的任务调度是基于系统绝对时间的，如果系统时间不正确，可能会出现问题。
TimerTask 如果执行出现异常，Timer 并不会捕获，会导致线程终止，其他任务永远不会执行。
时间轮原理分析
根据任务的到期时间进行取余和取模，然后根据取余结果将任务分布到不同的 slot 中，每个slot中根据round值决定是否操作，每次轮询到指定slot时，总时遍历最少round的对象进行执行，这样新增、执行两个操作的时间复杂度都近似O(1)。如果冲突较大可以增加数组长度，或者采用多级时间轮的方式处理。
public HashedWheelTimer( ThreadFactory threadFactory, //线程池，但是只创建了一个线程 long tickDuration, //时针每次 tick 的时间，相当于时针间隔多久走到下一个 slot TimeUnit unit, //表示 tickDuration 的时间单位，tickDuration * unit int ticksPerWheel, //时间轮上一共有多少个 slot，默认 512 个。 boolean leakDetection, long maxPendingTimeouts) {//最大允许等待任务数 // 省略其他代码 wheel = createWheel(ticksPerWheel); // 创建时间轮的环形数组结构 mask = wheel.length - 1; // 用于快速取模的掩码 long duration = unit.toNanos(tickDuration); // 转换成纳秒处理 workerThread = threadFactory.newThread(worker); // 创建工作线程 leak = leakDetection || !workerThread.isDaemon() ? leakDetector.track(this) : null; // 是否开启内存泄漏检测 this.maxPendingTimeouts = maxPendingTimeouts; // 最大允许等待任务数，HashedWheelTimer 中任务超出该阈值时会抛出异常}
时间轮空推进问题
Netty 中的时间轮是通过固定的时间间隔 tickDuration 进行推动的，如果长时间没有到期任务，那么会存在时间轮空推进的现象，从而造成一定的性能损耗。此外，如果任务的到期时间跨度很大，例如 A 任务 1s 后执行，B 任务 6 小时之后执行，也会造成空推进的问题。
Kafka解决方案
为了解决空推进的问题，Kafka 借助 JDK 的 DelayQueue 来负责推进时间轮。DelayQueue 保存了时间轮中的每个 Bucket，并且根据 Bucket 的到期时间进行排序，最近的到期时间被放在 DelayQueue 的队头。Kafka 中会有一个线程来读取 DelayQueue 中的任务列表，如果时间没有到，那么 DelayQueue 会一直处于阻塞状态，从而解决空推进的问题。虽然DelayQueue 插入和删除的性能不是很好，但这其实就是一种权衡的策略，但是DelayQueue 只存放了 Bucket，Bucket 的数量并不多，相比空推进带来的影响是利大于弊的。
为了解决任务时间跨度很大的问题，Kafka 引入了层级时间轮，如下图所示。当任务的 deadline 超出当前所在层的时间轮表示范围时，就会尝试将任务添加到上一层时间轮中，跟钟表的时针、分针、秒针的转动规则是同一个道理。
3、MpscQueue
4、select、poll、epoll的区别
select （windows）**poll **(linux)本质上和select没有区别，查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。
**epoll **支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。
Epoll空轮询漏洞
在 JDK 中， Epoll 的实现是存在漏洞的，即使 Selector 轮询的事件列表为空，NIO 线程一样可以被唤醒，导致 CPU 100% 占用。实际上 Netty 并没有从根源上解决该问题，而是巧妙地规避了这个问题。
long time = System.nanoTime();if (/*事件轮询的持续时间大于等于 timeoutMillis*/) { selectCnt = 1;} else if (/*不正常的次数 selectCnt 达到阈值 512*/) { //重建Select并且SelectionKey重新注册到新Selector上 selector = selectRebuildSelector(selectCnt);}
NioEventLoop 线程的可靠性至关重要，一旦 NioEventLoop 发生阻塞或者陷入空轮询，就会导致整个系统不可用。
reduce(function, iterable[, initializer]) reduce(lambda x,y:x * y,ns) # 数组之乘积 (ns[0] * ns[1]) * ns[2] reduce(lambda x,y:x + y,ns) # 数组之和 # 记忆化搜索 @functools.lru_cache(None) res = helper(0,N,0) helper.cache_clear() tuple(ns) 可以hash做参数 # 大根堆 q = list(map(lambda x:-x,ns)) heapq.heapify(q) key = -heapq.heappop(q) # 过滤函数 filter(function, iterable) filter(lambda x: 2 < x < 10 and x % 2 == 0, range(18)) filter(dfs, range(len(graph))) # 除数 div, mod = divmod(sum(ns), 4) random.randint(i,len(self.ns)-1) #第一个降序，第二个升序 sorted(pss,key = lambda x:[x[0],-x[1]]) # 不可变str 常见函数 split(sep=None, maxsplit=-1) # 以sep来分割字符串 strip([chars]) # 去除首末两端的字符, 默认是 \r,\n," " join(iterable) # 将iterable内的元素拼接成字符串,如','.join(['leet', 'code'])="leet,code" replace(old, new[, count]) # 字符串替换, old to new count(sub[, start[, end]]) # 统计子字符串sub的个数 startswith(prefix[, start[, end]]) # 以prefix开始的字符串 endswith(suffix[, start[, end]]) # 以suffix结束的字符串 cs in chrs: # chrs 中包含 cs # deque 常见函数 queue = deque([iterable[, maxlen]]) queue.append(val) # 往右边添加一个元素 queue.appendleft(val) # 往左边添加一个元素 queue.clear() # 清空队列 queue.count(val) # 返回指定元素的出现次数 queue.insert(val[, start[, stop]]) # 在指定位置插入元素 queue.pop() # 获取最右边一个元素，并在队列中删除 queue.popleft() # 获取最左边一个元素，并在队列中删除 queue.reverse() # 队列反转 queue.remove(val) # 删除指定元素 queue.rotate(n=1) # 把右边元素放到左边 # list 常见函数 lst.sort(*, key=None, reverse=False) lst.append(val) # 也可以 lst = lst + [val] lst.clear() # 清空列表 lst.count(val) # val个数 lst.pop(val=lst[-1]) # (默认)从末端移除一个值 lst.remove(val) # 移除 val lst.reverse() # 反转 lst.insert(i, val) # 在 i 处插入 val # 字典dict 常见函数 d = defaultdict(lambda : value) # 取到不存在的值时不会报错，用{}时、需要设置get的default值 pop(key[, default]) # 通过键去删除键值对(若没有该键则返回default(没有设置default则报错)) setdefault(key[, default]) # 设置默认值 update([other]) # 批量添加 get(key[, default]) # 通过键获取值(若没有该键可设置默认值, 预防报错) clear() # 清空字典 keys() # 将字典的键组成新的可迭代对象 values() # 将字典中的值组成新的可迭代对象 items() # 将字典的键值对凑成一个个元组, 组成新的可迭代对象 dict1 = dict2 #两个字典完全相等，滑窗时可用 # 集合set 常见函数 s = set(lambda : value) add(elem) # 向集合中添加数据 update(*others) # 迭代着增加 clear() # 清空集合 discard(elem) # 删除集合中指定的值(不存在则不删除) # 堆heapq 常见函数 heap = [] # 建堆 heapq.heappush(heap,item) # 往堆中插入新值 heapq.heappop(heap) # 弹出最小的值 heap[0] # 查看堆中最小的值, 不弹出 heapq.heapify(x) # 以线性时间将一个列表转为堆 heapq.heappoppush(heap, item) # 弹出最小的值.并且将新的值插入其中. heapq.merge(*iterables, key=None, reverse=False) # 将多个堆进行合并 heapq.nlargest(n, iterable, key=None) # 从堆中找出最大的 n 个数，key的作用和sorted( )方法里面的key类似, 用列表元素的某个属性和函数作为关键字 heapq.nsmallest(n, iterable, key=None) # 从堆中找出最小的 n 个数, 与 nlargest 相反 # 二分查找函数 bisect.bisect_left(ps, T, L=0, R=len(ns)) #二分左边界 bisect.bisect_right(ps, T, L=0, R=len(ns)) #二分右边界 bisect.insort_left(a, x, lo=0, hi=len(a)) # 二分插入到左侧 bisect.insort_right(a, x, lo=0, hi=len(a)) # 二分插入到右侧 # bit操作 & 符号，x & y ，会将两个十进制数在二进制下进行与运算 | 符号，x | y ，会将两个十进制数在二进制下进行或运算 ^ 符号，x ^ y ，会将两个十进制数在二进制下进行异或运算 << 符号，x << y 左移操作，最右边用 0 填充 >> 符号，x >> y 右移操作，最左边用 0 填充 ~ 符号，~x ，按位取反操作，将 x 在二进制下的每一位取反 # 整数集合set位运算 # 整数集合做标志时，可以做参数加速运算 vstd 访问 i ：vstd | (1 << i) vstd 离开 i ：vstd & ~(1 << i) vstd 不包含 i : not vstd & (1 << i) 并集 ：A | B 交集 ：A & B 全集 ：(1 << n) - 1 补集 ：((1 << n) - 1) ^ A 子集 ：(A & B) == B 判断是否是 2 的幂 ：A & (A - 1) == 0 最低位的 1 变为 0 ：n &= (n - 1) while n: n &= n - 1 ret += 1 最低位的 1：A & (-A)，最低位的 1 一般记为 lowbit(A) # ^ ：匹配字符串开头 # [\+\-]：代表一个+字符或-字符 # ? ：前面一个字符可有可无 # \d ：一个数字 # + ：前面一个字符的一个或多个 # \D ：一个非数字字符 # * ：前面一个字符的0个或多个 matches = re.match('[ ]*([+-]?\d+)', s)
「力扣」上的 0-1 背包问题：
「力扣」第 879 题：盈利计划（困难）；
「力扣」第 1449 题：数位成本和为目标值的最大数字（困难）。
# 回溯算法，复杂度较高2^n或者N！，因为回溯算法就是暴力穷举，可用lru剪枝 @functools.lru_cache(None) def backtrack(路径, 选择列表): if 满足结束条件: 结果.append(路径) return for 选择 in 选择列表: # 核心代码段 if vst[i]: # 辅助数组，减枝 continue 做出选择 递归执行backtrack 撤销选择
「剪枝」第 46 题 全排列 第 47 题 全排列②
# 剪枝 def backtrack(temp_list, length): if length == n: res.append(temp_list) for i in range(n): if not visited[i]: visited[i] = 1 backtrack(temp_list + [nums[i]], length + 1) visited[i] = 0
「索引遍历」第 78 题 子集 | 第 47 题 子集② | 第 131 题 分割字符串
第 **39 **题 组合 | 第 **40** 题 组合② | 第 **216** 题 组合③
# 索引遍历 def helper1(idx, n, temp_list): if temp_list not in res: res.append(temp_list) for i in range(idx, n): helper1(i + 1, n, temp_list + [nums[i]])
「 资源消耗」第 22 题 夸号生成
# 资源消耗 def backtrack(S, L, R): if not L and not R: ans.append(''.join(S)) return if L : backtrack(S + ['('], L-1, R) if R > L : backtrack(S + [')'], L, R-1)
「资源消耗」第 93 题 复原IP
资源消耗 def backtrack(i, tmp, flag): if i == n and flag == 0: res.append(tmp[:-1]) elif i<n and s[i] == '0': backtrack(i + 1, tmp + s[i] + ".", flag - 1) elif flag : for j in range(i, min(n,i + 3)): if 0 < int(s[i:j + 1]) <= 255: backtrack(j + 1, tmp + s[i:j + 1] + ".", flag - 1)
「资源消耗」第 17 题 电话号码
# 资源消耗 def dfs(path, remains): if not remains: res.append(path[:]) return for i in range(len(remains)): dfs(path + [remains[i]], remains[:i] + remains[i+1:]) # 套模板 def dfs(pth,idx): if idx == len(ds): res.append(pth) return for c in dic[ds[idx]]: dfs(pth + c, idx + 1)
「多重限制」第 37 题 解数独 | 第 51 题 N皇后
# 多重限制 def backtrack(pos): if pos == n: return True i, j = empty[pos] for num in row[i] & col[j] & block[bidx(i, j)]: row[i].remove(num) col[j].remove(num) block[bidx(i, j)].remove(num) board[i][j] = str(num) if backtrack(pos + 1): return True row[i].add(num) col[j].add(num) block[bidx(i, j)].add(num)
「递归」第 10 题 正则匹配
# 递归 def isMatch(self, s: str, p: str) -> bool: if not p: return not s f = bool(s and p[0] in {s[0],'.'}) if len(p) >= 2 and p[1] == "*": return self.isMatch(s, p[2:]) or f and self.isMatch(s[1:], p) else: return f and self.isMatch(s[1:], p[1:])
#虚拟节点用以连接某一特征的全部节点，类似于链表的preHead dummy parent = {} size = collections.defaultdict(lambda:1) cnt = 0 def find(x): parent.setdefault(x,x) while x != parent[x]: x = parent[x] #路径压缩 parent[x] = parent[parent[x]]; return x def union(x,y): nonlocal cnt if connected(x,y): return # 小的树挂到大的树上， 使树尽量平衡 xP = find(x) yP = find(y) if size[hP] < size[yP]: parent[xP] = yP else: parent[yP] = xP size[xP] += size[yP] # 优化结束 parent[find(x)] = find(y) # 不优化 cnt -= 1 return size[xP] def connected(x, y): return find(x) == find(y) def add(self,x): if x not in parent: parent[x] = None cnt += 1 # 检查是否有环 for a, b in edges: if connected(a, b): return True union(a, b) # 将每个集合组成以头为key的字典 res = collections.defaultdict(list) for e in e2n: res[uf.find(e)].append(e)
# 【拓扑排序模板】 ins = [0] * n ous = collections.defaultdict(list) for cur, pre in ps: ins[cur] += 1 #入度 ous[pre].append(cur) #出度 res = list(filter(lambda x:ins[x]==0, range(n))) q = collections.deque(res) while q: pre = q.popleft() for cur in ous[pre]: #释放出度队列 ins[cur] -= 1 if not ins[cur]: q.append(cur) #入度为0解锁 res.append(cur)
# s中一般存索引 for i in range(len(ns): while stack and ns[stack[-1]] <= ns[i]: # 单调递减栈 stack.pop() # 业务逻辑 stack.append(i)
「单调递增」第 84 题 求最大矩形
# 第 **84** 题 求最大矩形 for i in range(len(hs)): while s and hs[i] < hs[s[-1]]: base = s.pop() if s: H = hs[base] W = i - s[-1] - 1 # 当前弹出的做高，当前与次小做宽 res = max(res, H * W) s.append(i)
「单调递增,考虑剩余」第 316 题 去除重复字符
# 第 **316** 题 去除重复字符 for i,c in enumerate(ss): if c not in s: while s and c < s[-1] and s[-1] in ss[i:]: s.pop() s.append(c)
「单调递减」第 42 题 接雨水
# 第 **42** 题 接雨水 for i in range(len(hgt)): while stack and hgt[i] > hgt[stack[-1]]: #递减栈 base = stack.pop() if stack: LH = hgt[stack[-1]] W = i - stack[-1] - 1 H = min(LH,hgt[i]) - hgt[base] res += W * H stack.append(i)
「单调递减」第 739 题 每日温度
# 第 **739** 题 每日温度 for i in range(len(T)-1,-1,-1): while s and T[s[-1]] <= T[i] : #递减栈 s.pop() res[i] = s[-1] - i if s else 0 s.append(i)
# 1355579 T=5 => 13(5)55579 返回2 # ps[i-1] < ps[i] <= ps[i+1] bisect.bisect_left(ps, T, L=0, R=len(ns)) # 1355579 T=5 => 13555(5)79 返回5 # ps[i-1] <= ps[i] < ps[i+1] bisect.bisect_right(ps, T, L=0, R=len(ns)) bisect.bisect(ps, T, L=0, R=len(ns))
「中位返回」第 33 题 搜索旋转排序数组 | 第374题 猜数字大小 | 第69题 x平方根
# 中位返回 while L <= R: M = (L + R) // 2 if nums[M] == T: return M elif nums[M] < T: L = M + 1 else: R = M - 1
「区域压缩」第278题 第一个错误版本| 第162题 寻找峰值 | 第153题 寻找数组最小值
# 区域压缩 while L < R: M = (L + R) // 2 if need in s[L:M]: R = M else: L = M + 1
「单串问题」
# 依赖前单个元素 dp[i] = dp[i-1] + ns[i] # 依赖前部区域元素 for i in range(n) for j in range(i) dp[i] = min(dp[i], f(dp[j])
「单串加状态问题」
「经典双串LCS问题」
# 经典双串LCS问题 dp = [[0] * (M+1) for _ in range(N+1)] for i in range(N): for j in range(M): if t1[i] == t2[j] : dp[i+1][j+1] = dp[i][j] + 1 else : dp[i+1][j+1] = max(dp[i][j+1],dp[i+1][j])
「区间动态规划」
# dp[i][j] 代表从 i 到 j 的最长子串满足条件的数量 # i-- < j++ ==> i 在 0~j 范围内 -- dp = [[0] * (N) for _ in range(N)] for j in range(N): dp[j][j] = 1 for i in range(j-1,-1,-1): if ss[i] == ss[j]: dp[i][j] = dp[i+1][j-1] +2 else : dp[i][j] = max(dp[i+1][j],dp[i][j-1])
「区间分治动态规划」
# 区间分治动态规划 def helper(self, ns: List[int]) : N = len(ns) dp = [[0] * N for _ in range(N+1)] for l in range(N): # 长度从小到大 for i in range(N-l): # 以 i 为 开头 j = i + l # 以 j 为 终点 for k in range(i,j): # 以 k 为分割点，进行分治 // Todo 业务逻辑
「卡特兰数」
# 卡特兰数 g(n) = g(0)*g(n-1) + g(1)*g(n-2) ...g(n-1)*g(0) dp=[1] + [0] * n for i in range(1,n+1): for j in range(1,i+1): dp[i] += dp[j-1] * dp[i-j]
"""给定待查串s和目标串t""" nd, wd = {}, {} nd = collections.Counter(s1) L, R = 0, 0 cnt = 0 # 满足条件个数 while R < len(s): # 窗口右边界不断扩大，本质是搜索问题的可能解 c = s[R] # 即将加入到窗口中的字符 R += 1 更新窗口中的数据 while 满足窗口收缩条件： # 窗口的左边界收缩，本质是优化可行解 记录或返回结果 d = s[L] # 即将从窗口中删除的字符 L += 1 更新窗口中的数据 return 结果 # 固定窗口 ,比滑动窗口更快一些 i = j = cnt = 0 for j in range(len(A)): if A[j] == 0: cnt += 1 if cnt > K: #不满足时 平移 if A[i] == 0: cnt -= 1 i += 1 return j - i + 1 for j in range(len(A)): if A[j] == 0: cnt += 1 while cnt > K: if A[i] == 0: cnt -= 1 i += 1 res = max(res, j - i + 1) return res
「累加和存位置」
1371 最长偶数元音子数组
525 最长相等01子数组
325 最长和为k 子数组
# 前缀和初始化 psd = {0: -1} for i in range(len(s)): t ^= cd.get(s[i], 0) # 业务逻辑 if t not in psd: psd[t] = i # 第一次存入数组 else: ans = max(ans, i - psd[t]) #已存入则开始计算
「累加和存数量」
560 和为K的子数组数量
统计优美子数组
# 累加和存数量 psd = {0:1} for i in range(len(ns)): s += ns[i] if s - T in psd: ans += psd[s - T] # 存数量 psd[s] = psd.get(s,0) + 1
「模K状态前缀和」
523 连续和为 k 倍 的子数组（存索引）
974 和被k 整除 子数组数量（存数量）
# 模K状态前缀和 psd = {0:-1} ans = s = 0 for i in range(len(ns)): s += ns[i] # 业务逻辑 if T != 0: s %= abs(T) # 模k状态做key，索引做值 if s not in psd: psd[s] = i elif i - psd[s] > 1: return True
「矩阵前缀和」
# 矩阵前缀和 for i in range(m): #固定左边界 ps = [0] * n for j in range(i, m): #固定右边界 psS = 0 dct = {0:1} #初始只有一种可能 for k in range(n): # 以高做前缀和 ps[k] += mtx[j][k] # 每行前缀和 psS += ps[k] # n行前缀和 cnt += dct.get(psS - T, 0) # 满足条件cnt dct[psS] = dct.get(psS,0) + 1 # 保存当前状态 return cnt
# 双指针 def removeElement(self, ns: List[int], val: int) -> int: slow = 0 n = len(ns) for fast in range(n): if ns[fast] != val: ns[slow] = ns[fast] slow += 1 return slow
「二叉树遍历模板」
# 递归 # 时间复杂度：O(n)，n为节点数，访问每个节点恰好一次。 # 空间复杂度：空间复杂度：O(h)，h为树的高度。最坏情况下需要空间O(n)，平均情况为O(logn) # 递归1：二叉树遍历最易理解和实现版本 class Solution: def preOrd(self, root: TreeNode) -> List[int]: if not root: return [] # 前序递归 return [root.val] + self.preOrd(root.left) + self.preOrd(root.right) # # 中序递归 # return self.inOrd(root.left) + [root.val] + self.inOrd(root.right) # # 后序递归 # return self.postOrd(root.left) + self.postOrd(root.right) + [root.val] # 递归2：通用模板，可以适应不同的题目，添加参数、增加返回条件、修改进入递归条件、自定义返回值 class Solution: def preOrd(self, root: TreeNode) -> List[int]: def dfs(cur): if not cur: return # 前序递归 res.append(cur.val) dfs(cur.left) dfs(cur.right) # # 中序递归 # dfs(cur.left) # res.append(cur.val) # dfs(cur.right) # # 后序递归 # dfs(cur.left) # dfs(cur.right) # res.append(cur.val) res = [] dfs(root) return res # 迭代 # 时间复杂度：O(n)，n为节点数，访问每个节点恰好一次。 # 空间复杂度：O(h)，h为树的高度。取决于树的结构，最坏情况存储整棵树，即O(n) # 迭代1：前序遍历最常用模板（后序同样可以用） class Solution: def preOrd(self, root: TreeNode) -> List[int]: if not root: return [] res = [] stack = [root] # # 前序迭代模板：最常用的二叉树DFS迭代遍历模板 while stack: cur = stack.pop() res.append(cur.val) if cur.right: stack.append(cur.right) if cur.left: stack.append(cur.left) return res # # 后序迭代，相同模板：将前序迭代进栈顺序稍作修改，最后得到的结果反转 # while stack: # cur = stack.pop() # if cur.left: # stack.append(cur.left) # if cur.right: # stack.append(cur.right) # res.append(cur.val) # return res[::-1] # 迭代1：层序遍历最常用模板 class Solution: def levelOrder(self, root: TreeNode) -> List[List[int]]: if not root: return [] q = deque([root]) res = [] while q : l = [] for i in range(len(q)) : t = q.popleft() l.append(t.val) if t.left : q.append(t.left) if t.right : q.append(t.right) res.append(l) return res # 迭代2：前、中、后序遍历通用模板（只需一个栈的空间） class Solution: def inOrd(self, root: TreeNode) -> List[int]: res = [] stack = [] cur = root # 中序，模板：先用指针找到每颗子树的最左下角，然后进行进出栈操作 while stack or cur: while cur: stack.append(cur) cur = cur.left cur = stack.pop() res.append(cur.val) cur = cur.right return res # # 前序，相同模板 # while stack or cur: # while cur: # res.append(cur.val) # stack.append(cur) # cur = cur.left # cur = stack.pop() # cur = cur.right # return res # # 后序，相同模板 # while stack or cur: # while cur: # res.append(cur.val) # stack.append(cur) # cur = cur.right # cur = stack.pop() # cur = cur.left # return res[::-1] # 迭代3：标记法迭代（需要双倍的空间来存储访问状态）： # 前、中、后、层序通用模板，只需改变进栈顺序或即可实现前后中序遍历， # 而层序遍历则使用队列先进先出。0表示当前未访问，1表示已访问。 class Solution: def preOrd(self, root: TreeNode) -> List[int]: res = [] stack = [(0, root)] while stack: flag, cur = stack.pop() if not cur: continue if flag == 0: # 前序，标记法 stack.append((0, cur.right)) stack.append((0, cur.left)) stack.append((1, cur)) # # 后序，标记法 # stack.append((1, cur)) # stack.append((0, cur.right)) # stack.append((0, cur.left)) # # 中序，标记法 # stack.append((0, cur.right)) # stack.append((1, cur)) # stack.append((0, cur.left)) else: res.append(cur.val) return res # # 层序，标记法 # res = [] # queue = [(0, root)] # while queue: # flag, cur = queue.pop(0) # 注意是队列，先进先出 # if not cur: continue # if flag == 0: # 层序遍历这三个的顺序无所谓，因为是队列，只弹出队首元素 # queue.append((1, cur)) # queue.append((0, cur.left)) # queue.append((0, cur.right)) # else: # res.append(cur.val) # return res # 莫里斯遍历 # 时间复杂度：O(n)，n为节点数，看似超过O(n)，有的节点可能要访问两次，实际分析还是O(n) # 空间复杂度：O(1)，如果在遍历过程中就输出节点值，则只需常数空间就能得到中序遍历结果，空间只需两个指针。 # 如果将结果储存最后输出，则空间复杂度还是O(n)。 # PS：莫里斯遍历实际上是在原有二叉树的结构基础上，构造了线索二叉树， # 线索二叉树定义为：原本为空的右子节点指向了中序遍历顺序之后的那个节点，把所有原本为空的左子节点都指向了中序遍历之前的那个节点 # 此处只给出中序遍历，前序遍历只需修改输出顺序即可 # 而后序遍历，由于遍历是从根开始的，而线索二叉树是将为空的左右子节点连接到相应的顺序上，使其能够按照相应准则输出 # 但是后序遍历的根节点却已经没有额外的空间来标记自己下一个应该访问的节点， # 所以这里需要建立一个临时节点dump，令其左孩子是root。并且还需要一个子过程，就是倒序输出某两个节点之间路径上的各个节点。 # 莫里斯遍历，借助线索二叉树中序遍历（附前序遍历） class Solution: def inOrd(self, root: TreeNode) -> List[int]: res = [] # cur = pre = TreeNode(None) cur = root while cur: if not cur.left: res.append(cur.val) # print(cur.val) cur = cur.right else: pre = cur.left while pre.right and pre.right != cur: pre = pre.right if not pre.right: # print(cur.val) 这里是前序遍历的代码，前序与中序的唯一差别 pre.right = cur cur = cur.left else: pre.right = None res.append(cur.val) # print(cur.val) cur = cur.right return res # N叉树遍历 # 时间复杂度：时间复杂度：O(M)，其中 M 是 N 叉树中的节点个数。每个节点只会入栈和出栈各一次。 # 空间复杂度：O(M)。在最坏的情况下，这棵 N 叉树只有 2 层，所有第 2 层的节点都是根节点的孩子。 # 将根节点推出栈后，需要将这些节点都放入栈，共有 M−1个节点，因此栈的大小为 O(M)。 # N叉树简洁递归 class Solution: def preorder(self, root: 'Node') -> List[int]: if not root: return [] res = [root.val] for node in root.children: res.extend(self.preorder(node)) return res # N叉树通用递归模板 class Solution: def preorder(self, root: 'Node') -> List[int]: res = [] def helper(root): if not root: return res.append(root.val) for child in root.children: helper(child) helper(root) return res # N叉树迭代方法 class Solution: def preorder(self, root: 'Node') -> List[int]: if not root: return [] s = [root] # s.append(root) res = [] while s: node = s.pop() res.append(node.val) # for child in node.children[::-1]: # s.append(child) s.extend(node.children[::-1]) return res
# 「**无向图的遍历**」 q = collections.deque([i]) while q: cur = q.popleft() for nxt in dt[cur]: if not vst[nxt]: vstd[nxt] = True q.append(nxt)
# 「**二叉树层序遍历**」 q = deque([root]) res = [] while q : l = [] for i in range(len(q)) : t = q.popleft() l.append(t.val) if t.left : q.append(t.left) if t.right : q.append(t.right) res.append(l) return res
#「Dijkstra最短路径」 dic = collections.defaultdict(list) for u, v, w in edges: dic[u].append([v, w]) dic[v].append([u, w]) q = [(0, n)] dist = [-1] * (n + 1) while q: dis, cur = heapq.heappop(q) if dist[cur] < 0: dist[cur] = dis for nxt, wi in dic[cur]: heapq.heappush(q, [dis + wi, nxt])
「Floyd 求图中路径」
# Floyd算法 求图中任意2点距离 ds = defaultdict(int) st = set() for i, (x, y) in enumerate(ess): ds[(x, y)] = vs[i] ds[(y, x)] = 1 / vs[i] st.update({x,y}) arr = list(st) for k in arr: for i in arr: for j in arr: if ds[(i, k)] and ds[(k, j)]: ds[(i, j)] = ds[(i, k)] * ds[(k, j)]
100亿黑名单URL，每个64B，问这个黑名单要怎么存？判断一个URL是否在黑名单中
散列表：
如果把黑名单看成一个集合，将其存在 hashmap 中，貌似太大了，需要 640G，明显不科学。
布隆过滤器：
它实际上是一个很长的二进制矢量和一系列随机映射函数。
它可以用来判断一个元素是否在一个集合中。它的优势是只需要占用很小的内存空间以及有着高效的查询效率。对于布隆过滤器而言，它的本质是一个位数组：位数组就是数组的每个元素都只占用 1 bit ，并且每个元素只能是 0 或者 1。
在数组中的每一位都是二进制位。布隆过滤器除了一个位数组，还有 K 个哈希函数。当一个元素加入布隆过滤器中的时候，会进行如下操作：
2GB内存在20亿整数中找到出现次数最多的数
通常做法是使用哈希表对出现的每一个数做词频统计，哈希表的key是某个整数，value记录整数出现的次数。本题的数据量是20亿，有可能一个数出现20亿次，则为了避免溢出，哈希表的key是32位（4B）,value也是 32位（4B），那么一条哈希表的记录就需要占用8B。
当哈希表记录数为2亿个时，需要16亿个字节数（8*2亿），需要至少1.6GB内存(16亿/2^30,1GB== 2 ^30个字节 == 10亿)。则20亿个记录，至少需要16GB的内存，不符合题目要求。
解决办法是将20亿个数的大文件利用哈希函数分成16个小文件，根据哈希函数可以把20亿条数据均匀分布到16个文件上，同一种数不可能被哈希函数分到不同的小文件上，假设哈希函数够好。然后对每一个小文件用哈希函数来统计其中每种数出现的次数，这样我们就得到16个文件中出现次数最多的数，接着从16个数中选出次数最大的那个key即可。
40亿个非负整数中找到没有出现的数
对于原问题，如果使用哈希表来保存出现过的数，那么最坏情况下是40亿个数都不相同，那么哈希表则需要保存40亿条数据，一个32位整数需要4B，那么40亿*4B = 160亿个字节，一般大概10亿个字节的数据需要1G的空间，那么大概需要16G的空间，这不符合要求。
我们换一种方式，申请一个bit数组，数组大小为4294967295，大概为40亿bit，40亿/8 = 5亿字节，那么需要0.5G空间， bit数组的每个位置有两种状态0和1，那么怎么使用这个bit数组呢？呵呵，数组的长度刚好满足我们整数的个数范围，那么数组的每个下标值对应4294967295中的一个数，逐个遍历40亿个无符号数，例如，遇到20，则bitArray[20] = 1；遇到666，则bitArray[666] = 1,遍历完所有的数，将数组相应位置变为1。
40亿个非负整数中找到一个没有出现的数，内存限制10MB
10亿个字节的数据大概需要1GB空间处理，那么10MB内存换算过来就是可以处理1千万字节的数据，也就是8千万bit，对于40亿非负整数如果申请bit数组的话，40亿bit / 0.8亿bit = 50，那么这样最少也得分50块来处理，下面就以64块来进行分析解答吧。
总结一下进阶的解法：
1．根据10MB的内存限制，确定统计区间的大小，就是第二次遍历时的bitArr大小。
2．利用区间计数的方式，找到那个计数不足的区间，这个区间上肯定有没出现的数。
3．对这个区间上的数做bit map映射，再遍历bit map，找到一个没出现的数即可。
自己的想法
如果只是找一个数，可以高位模运算，写到64个不同的文件，然后在最小的文件中通过bitArray一次处理掉。
40亿个无符号整数，1GB内存，找到所有出现两次的数
对于原问题，可以用bit map的方式来表示数出现的情况。具体地说，是申请一个长度为4294967295×2的bit类型的数组bitArr，用2个位置表示一个数出现的词频，1B占用8个bit，所以长度为4294967295×2的bit类型的数组占用1GB空间。怎么使用这个bitArr数组呢？遍历这40亿个无符号数，如果初次遇到num，就把bitArr[num2 + 1]和bitArr[num2]设置为01，如果第二次遇到num，就把bitArr[num2+1]和bitArr[num2]设置为10，如果第三次遇到num，就把bitArr[num2+1]和bitArr[num2]设置为11。以后再遇到num，发现此时bitArr[num2+1]和bitArr[num2]已经被设置为11，就不再做任何设置。遍历完成后，再依次遍历bitArr，如果发现bitArr[i2+1]和bitArr[i2]设置为10，那么i 就是出现了两次的数。
找到100亿个URL中重复的URL
原问题的解法使用解决大数据问题的一种常规方法：把大文件通过哈希函数分配到机器，或者通过哈希函数把大文件拆成小文件。一直进行这种划分，直到划分的结果满足资源限制的要求。首先，你要向面试官询问在资源上的限制有哪些，包括内存、计算时间等要求。在明确了限制要求之后，可以将每条URL通过哈希函数分配到若干机器或者拆分成若干小文件，这里的“若干”由具体的资源限制来计算出精确的数量。
例如，将100亿字节的大文件通过哈希函数分配到100台机器上，然后每一台机器分别统计分给自己的URL中是否有重复的URL，同时哈希函数的性质决定了同一条URL不可能分给不同的机器；或者在单机上将大文件通过哈希函数拆成1000个小文件，对每一个小文件再利用哈希表遍历，找出重复的URL；或者在分给机器或拆完文件之后，进行排序，排序过后再看是否有重复的URL出现。总之，牢记一点，很多大数据问题都离不开分流，要么是哈希函数把大文件的内容分配给不同的机器，要么是哈希函数把大文件拆成小文件，然后处理每一个小数量的集合。
海量搜索词汇，找到最热TOP100词汇的方法
最开始还是用哈希分流的思路来处理，把包含百亿数据量的词汇文件分流到不同的机器上，具体多少台机器由面试官规定或者由更多的限制来决定。对每一台机器来说，如果分到的数据量依然很大，比如，内存不够或其他问题，可以再用哈希函数把每台机器的分流文件拆成更小的文件处理。
处理每一个小文件的时候，哈希表统计每种词及其词频，哈希表记录建立完成后，再遍历哈希表，遍历哈希表的过程中使用大小为100的小根堆来选出每一个小文件的top 100（整体未排序的top 100）。每一个小文件都有自己词频的小根堆（整体未排序的top 100），将小根堆里的词按照词频排序，就得到了每个小文件的排序后top 100。然后把各个小文件排序后的top 100进行外排序或者继续利用小根堆，就可以选出每台机器上的top 100。不同机器之间的top100再进行外排序或者继续利用小根堆，最终求出整个百亿数据量中的top 100。对于top K 的问题，除哈希函数分流和用哈希表做词频统计之外，还经常用堆结构和外排序的手段进行处理。
10MB内存，找到100亿整数的中位数
①内存够：内存够还慌什么啊，直接把100亿个全部排序了，你用冒泡都可以...然后找到中间那个就可以了。但是你以为面试官会给你内存？？
②内存不够：题目说是整数，我们认为是带符号的int,所以4字节，占32位。
假设100亿个数字保存在一个大文件中，依次读一部分文件到内存(不超过内存的限制)，将每个数字用二进制表示，比较二进制的最高位(第32位，符号位，0是正，1是负)，如果数字的最高位为0，则将这个数字写入 file_0文件中；如果最高位为 1，则将该数字写入file_1文件中。
从而将100亿个数字分成了两个文件，假设 file_0文件中有 60亿 个数字，file_1文件中有 40亿 个数字。那么中位数就在 file_0 文件中，并且是 file_0 文件中所有数字排序之后的第 10亿 个数字。（file_1中的数都是负数，file_0中的数都是正数，也即这里一共只有40亿个负数，那么排序之后的第50亿个数一定位于file_0中）
现在，我们只需要处理 file_0 文件了（不需要再考虑file_1文件）。对于 file_0 文件，同样采取上面的措施处理：将file_0文件依次读一部分到内存(不超内存限制)，将每个数字用二进制表示，比较二进制的 次高位（第31位），如果数字的次高位为0，写入file_0_0文件中；如果次高位为1，写入file_0_1文件 中。
现假设 file_0_0文件中有30亿个数字，file_0_1中也有30亿个数字，则中位数就是：file_0_0文件中的数字从小到大排序之后的第10亿个数字。
抛弃file_0_1文件，继续对 file_0_0文件 根据 次次高位(第30位) 划分，假设此次划分的两个文件为：file_0_0_0中有5亿个数字，file_0_0_1中有25亿个数字，那么中位数就是 file_0_0_1文件中的所有数字排序之后的 第 5亿 个数。
按照上述思路，直到划分的文件可直接加载进内存时，就可以直接对数字进行快速排序，找出中位数了。
设计短域名系统，将长URL转化成短的URL.
（1）利用放号器，初始值为0，对于每一个短链接生成请求，都递增放号器的值，再将此值转换为62进制（a-zA-Z0-9），比如第一次请求时放号器的值为0，对应62进制为a，第二次请求时放号器的值为1，对应62进制为b，第10001次请求时放号器的值为10000，对应62进制为sBc。
（2）将短链接服务器域名与放号器的62进制值进行字符串连接，即为短链接的URL，比如：t.cn/sBc。
（3）重定向过程：生成短链接之后，需要存储短链接到长链接的映射关系，即sBc -> URL，浏览器访问短链接服务器时，根据URL Path取到原始的链接，然后进行302重定向。映射关系可使用K-V存储，比如Redis或Memcache。
假设有这么一个场景，有一条新闻，新闻的评论量可能很大，如何设计评论的读和写
前端页面直接给用户展示、通过消息队列异步方式入库
读可以进行读写分离、同时热点评论定时加载到缓存
显示网站的用户在线数的解决思路
维护在线用户表
使用Redis统计
显示网站并发用户数
假设目前有 1000w 个记录（这些查询串的重复度比较高，虽然总数是 1000w，但如果除去重复后，则不超过 300w 个）。请统计最热门的 10 个查询串，要求使用的内存不能超过 1G。（一个查询串的重复度越高，说明查询它的用户越多，也就越热门。）
HashMap 法
虽然字符串总数比较多，但去重后不超过 300w，因此，可以考虑把所有字符串及出现次数保存在一个 HashMap 中，所占用的空间为 300w*(255+4)≈777M（其中，4 表示整数占用的 4 个字节）。由此可见，1G 的内存空间完全够用。
思路如下：
首先，遍历字符串，若不在 map 中，直接存入 map，value 记为 1；若在 map 中，则把对应的 value 加 1，这一步时间复杂度 O(N) 。
接着遍历 map，构建一个 10 个元素的小顶堆，若遍历到的字符串的出现次数大于堆顶字符串的出现次数，则进行替换，并将堆调整为小顶堆。
遍历结束后，堆中 10 个字符串就是出现次数最多的字符串。这一步时间复杂度 O(Nlog10) 。
前缀树法
当这些字符串有大量相同前缀时，可以考虑使用前缀树来统计字符串出现的次数，树的结点保存字符串出现次数，0 表示没有出现。
思路如下：
在遍历字符串时，在前缀树中查找，如果找到，则把结点中保存的字符串次数加 1，否则为这个字符串构建新结点，构建完成后把叶子结点中字符串的出现次数置为 1。
最后依然使用小顶堆来对字符串的出现次数进行排序。
线性切割法，一个区间切N-1刀。越早越多
二倍均值法，【0 ~ 剩余金额 / 剩余人数 * 2】中随机，相对均匀
public class QuickSort { public static void swap(int[] arr, int i, int j) { int tmp = arr[i]; arr[i] = arr[j]; arr[j] = tmp; } /* 常规快排 */ public static void quickSort1(int[] arr, int L , int R) { if (L > R) return; int M = partition(arr, L, R); quickSort1(arr, L, M - 1); quickSort1(arr, M + 1, R); } public static int partition(int[] arr, int L, int R) { if (L > R) return -1; if (L == R) return L; int lessEqual = L - 1; int index = L; while (index < R) { if (arr[index] <= arr[R]) swap(arr, index, ++lessEqual); index++; } swap(arr, ++lessEqual, R); return lessEqual; } /* 荷兰国旗 */ public static void quickSort2(int[] arr, int L, int R) { if (L > R) return; int[] equalArea = netherlandsFlag(arr, L, R); quickSort2(arr, L, equalArea[0] - 1); quickSort2(arr, equalArea[1] + 1, R); } public static int[] netherlandsFlag(int[] arr, int L, int R) { if (L > R) return new int[] { -1, -1 }; if (L == R) return new int[] { L, R }; int less = L - 1; int more = R; int index = L; while (index < more) { if (arr[index] == arr[R]) { index++; } else if (arr[index] < arr[R]) { swap(arr, index++, ++less); } else { swap(arr, index, --more); } } swap(arr, more, R); return new int[] { less + 1, more }; } // for test public static void main(String[] args) { int testTime = 1; int maxSize = 10000000; int maxValue = 100000; boolean succeed = true; long T1=0,T2=0; for (int i = 0; i < testTime; i++) { int[] arr1 = generateRandomArray(maxSize, maxValue); int[] arr2 = copyArray(arr1); int[] arr3 = copyArray(arr1); // int[] arr1 = {9,8,7,6,5,4,3,2,1}; long t1 = System.currentTimeMillis(); quickSort1(arr1,0,arr1.length-1); long t2 = System.currentTimeMillis(); quickSort2(arr2,0,arr2.length-1); long t3 = System.currentTimeMillis(); T1 += (t2-t1); T2 += (t3-t2); if (!isEqual(arr1, arr2) || !isEqual(arr2, arr3)) { succeed = false; break; } } System.out.println(T1+" "+T2); // System.out.println(succeed ? "Nice!" : "Oops!"); } private static int[] generateRandomArray(int maxSize, int maxValue) { int[] arr = new int[(int) ((maxSize + 1) * Math.random())]; for (int i = 0; i < arr.length; i++) { arr[i] = (int) ((maxValue + 1) * Math.random()) - (int) (maxValue * Math.random()); } return arr; } private static int[] copyArray(int[] arr) { if (arr == null) return null; int[] res = new int[arr.length]; for (int i = 0; i < arr.length; i++) { res[i] = arr[i]; } return res; } private static boolean isEqual(int[] arr1, int[] arr2) { if ((arr1 == null && arr2 != null) || (arr1 != null && arr2 == null)) return false; if (arr1 == null && arr2 == null) return true; if (arr1.length != arr2.length) return false; for (int i = 0; i < arr1.length; i++) if (arr1[i] != arr2[i]) return false; return true; } private static void printArray(int[] arr) { if (arr == null) return; for (int i = 0; i < arr.length; i++) System.out.print(arr[i] + " "); System.out.println(); } }
public static void merge(int[] arr, int L, int M, int R) { int[] help = new int[R - L + 1]; int i = 0; int p1 = L; int p2 = M + 1; while (p1 <= M && p2 <= R) help[i++] = arr[p1] <= arr[p2] ? arr[p1++] : arr[p2++]; while (p1 <= M) help[i++] = arr[p1++]; while (p2 <= R) help[i++] = arr[p2++]; for (i = 0; i < help.length; i++) arr[L + i] = help[i]; } public static void mergeSort(int[] arr, int L, int R) { if (L == R) return; int mid = L + ((R - L) >> 1); process(arr, L, mid); process(arr, mid + 1, R); merge(arr, L, mid, R); } public static void main(String[] args) { int[] arr1 = {9,8,7,6,5,4,3,2,1}; mergeSort(arr, 0, arr.length - 1); printArray(arr); }
// 堆排序额外空间复杂度O(1) public static void heapSort(int[] arr) { if (arr == null || arr.length < 2) return; for (int i = arr.length - 1; i >= 0; i--) heapify(arr, i, arr.length); int heapSize = arr.length; swap(arr, 0, --heapSize); // O(N*logN) while (heapSize > 0) { // O(N) heapify(arr, 0, heapSize); // O(logN) swap(arr, 0, --heapSize); // O(1) } } // arr[index]刚来的数，往上 public static void heapInsert(int[] arr, int index) { while (arr[index] > arr[(index - 1) / 2]) { swap(arr, index, (index - 1) / 2); index = (index - 1) / 2; } } // arr[index]位置的数，能否往下移动 public static void heapify(int[] arr, int index, int heapSize) { int left = index * 2 + 1; // 左孩子的下标 while (left < heapSize) { // 下方还有孩子的时候 // 两个孩子中，谁的值大，把下标给largest // 1）只有左孩子，left -> largest // 2) 同时有左孩子和右孩子，右孩子的值<= 左孩子的值，left -> largest // 3) 同时有左孩子和右孩子并且右孩子的值> 左孩子的值， right -> largest int largest = left+1 < heapSize && arr[left+1]> arr[left] ? left+1 : left; // 父和较大的孩子之间，谁的值大，把下标给largest largest = arr[largest] > arr[index] ? largest : index; if (largest == index) break; swap(arr, largest, index); index = largest; left = index * 2 + 1; } } public static void swap(int[] arr, int i, int j) { int tmp = arr[i]; arr[i] = arr[j]; arr[j] = tmp; } public static void main(String[] args) { int[] arr1 = {9,8,7,6,5,4,3,2,1}; heapSort(arr1); printArray(arr1); }
public class Singleton { private volatile static Singleton singleton; private Singleton() {} public static Singleton getSingleton() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } }
// 基于linkedHashMap public class LRUCache { private LinkedHashMap<Integer,Integer> cache; private int capacity; //容量大小 public LRUCache(int capacity) { cache = new LinkedHashMap<>(capacity); this.capacity = capacity; } public int get(int key) { //缓存中不存在此key，直接返回 if(!cache.containsKey(key)) { return -1; } int res = cache.get(key); cache.remove(key); //先从链表中删除 cache.put(key,res); //再把该节点放到链表末尾处 return res; } public void put(int key,int value) { if(cache.containsKey(key)) { cache.remove(key); //已经存在，在当前链表移除 } if(capacity == cache.size()) { //cache已满，删除链表头位置 Set<Integer> keySet = cache.keySet(); Iterator<Integer> iterator = keySet.iterator(); cache.remove(iterator.next()); } cache.put(key,value); //插入到链表末尾 } }
//手写双向链表 class LRUCache { class DNode { DNode prev; DNode next; int val; int key; } Map<Integer, DNode> map = new HashMap<>(); DNode head, tail; int cap; public LRUCache(int capacity) { head = new DNode(); tail = new DNode(); head.next = tail; tail.prev = head; cap = capacity; } public int get(int key) { if (map.containsKey(key)) { DNode node = map.get(key); removeNode(node); addToHead(node); return node.val; } else { return -1; } } public void put(int key, int value) { if (map.containsKey(key)) { DNode node = map.get(key); node.val = value; removeNode(node); addToHead(node); } else { DNode newNode = new DNode(); newNode.val = value; newNode.key = key; addToHead(newNode); map.put(key, newNode); if (map.size() > cap) { map.remove(tail.prev.key); removeNode(tail.prev); } } } public void removeNode(DNode node) { DNode prevNode = node.prev; DNode nextNode = node.next; prevNode.next = nextNode; nextNode.prev = prevNode; } public void addToHead(DNode node) { DNode firstNode = head.next; head.next = node; node.prev = head; node.next = firstNode; firstNode.prev = node; } }
package com.concurrent.pool; import java.util.HashSet; import java.util.Set; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.BlockingQueue; public class MySelfThreadPool { //默认线程池中的线程的数量 private static final int WORK_NUM = 5; //默认处理任务的数量 private static final int TASK_NUM = 100; private int workNum;//线程数量 private int taskNum;//任务数量 private final Set<WorkThread> workThreads;//保存线程的集合 private final BlockingQueue<Runnable> taskQueue;//阻塞有序队列存放任务 public MySelfThreadPool() { this(WORK_NUM, TASK_NUM); } public MySelfThreadPool(int workNum, int taskNum) { if (workNum <= 0) workNum = WORK_NUM; if (taskNum <= 0) taskNum = TASK_NUM; taskQueue = new ArrayBlockingQueue<>(taskNum); this.workNum = workNum; this.taskNum = taskNum; workThreads = new HashSet<>(); //启动一定数量的线程数，从队列中获取任务处理 for (int i=0;i<workNum;i++) { WorkThread workThread = new WorkThread("thead_"+i); workThread.start(); workThreads.add(workThread); } } public void execute(Runnable task) { try { taskQueue.put(task); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } public void destroy() { System.out.println("ready close thread pool..."); if (workThreads == null || workThreads.isEmpty()) return ; for (WorkThread workThread : workThreads) { workThread.stopWork(); workThread = null;//help gc } workThreads.clear(); } private class WorkThread extends Thread{ public WorkThread(String name) { super(); setName(name); } @Override public void run() { while (!interrupted()) { try { Runnable runnable = taskQueue.take();//获取任务 if (runnable !=null) { System.out.println(getName()+" readyexecute:"+runnable.toString()); runnable.run();//执行任务 } runnable = null;//help gc } catch (Exception e) { interrupt(); e.printStackTrace(); } } } public void stopWork() { interrupt(); } } } package com.concurrent.pool; public class TestMySelfThreadPool { private static final int TASK_NUM = 50;//任务的个数 public static void main(String[] args) { MySelfThreadPool myPool = new MySelfThreadPool(3,50); for (int i=0;i<TASK_NUM;i++) { myPool.execute(new MyTask("task_"+i)); } } static class MyTask implements Runnable{ private String name; public MyTask(String name) { this.name = name; } public String getName() { return name; } public void setName(String name) { this.name = name; } @Override public void run() { try { Thread.sleep(1000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } System.out.println("task :"+name+" end..."); } @Override public String toString() { // TODO Auto-generated method stub return "name = "+name; } } }
public class Storage { private static int MAX_VALUE = 100; private List<Object> list = new ArrayList<>(); public void produce(int num) { synchronized (list) { while (list.size() + num > MAX_VALUE) { System.out.println("暂时不能执行生产任务"); try { list.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } for (int i = 0; i < num; i++) { list.add(new Object()); } System.out.println("已生产产品数"+num+" 仓库容量"+list.size()); list.notifyAll(); } } public void consume(int num) { synchronized (list) { while (list.size() < num) { System.out.println("暂时不能执行消费任务"); try { list.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } for (int i = 0; i < num; i++) { list.remove(0); } System.out.println("已消费产品数"+num+" 仓库容量" + list.size()); list.notifyAll(); } } } public class Producer extends Thread { private int num; private Storage storage; public Producer(Storage storage) { this.storage = storage; } public void setNum(int num) { this.num = num; } public void run() { storage.produce(this.num); } } public class Customer extends Thread { private int num; private Storage storage; public Customer(Storage storage) { this.storage = storage; } public void setNum(int num) { this.num = num; } public void run() { storage.consume(this.num); } } public class Test { public static void main(String[] args) { Storage storage = new Storage(); Producer p1 = new Producer(storage); Producer p2 = new Producer(storage); Producer p3 = new Producer(storage); Producer p4 = new Producer(storage); Customer c1 = new Customer(storage); Customer c2 = new Customer(storage); Customer c3 = new Customer(storage); p1.setNum(10); p2.setNum(20); p3.setNum(80); c1.setNum(50); c2.setNum(20); c3.setNum(20); c1.start(); c2.start(); c3.start(); p1.start(); p2.start(); p3.start(); } }
public class blockQueue { private List<Integer> container = new ArrayList<>(); private volatile int size; private volatile int capacity; private Lock lock = new ReentrantLock(); private final Condition isNull = lock.newCondition(); private final Condition isFull = lock.newCondition(); blockQueue(int capacity) { this.capacity = capacity; } public void add(int data) { try { lock.lock(); try { while (size >= capacity) { System.out.println("阻塞队列满了"); isFull.await(); } } catch (Exception e) { isFull.signal(); e.printStackTrace(); } ++size; container.add(data); isNull.signal(); } finally { lock.unlock(); } } public int take() { try { lock.lock(); try { while (size == 0) { System.out.println("阻塞队列空了"); isNull.await(); } } catch (Exception e) { isNull.signal(); e.printStackTrace(); } --size; int res = container.get(0); container.remove(0); isFull.signal(); return res; } finally { lock.unlock(); } } } public static void main(String[] args) { AxinBlockQueue queue = new AxinBlockQueue(5); Thread t1 = new Thread(() -> { for (int i = 0; i < 100; i++) { queue.add(i); System.out.println("塞入" + i); try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } } }); Thread t2 = new Thread(() -> { for (; ; ) { System.out.println("消费"+queue.take()); try { Thread.sleep(800); } catch (InterruptedException e) { e.printStackTrace(); } } }); t1.start(); t2.start(); }
package com.demo.test; import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.ReentrantLock; public class syncPrinter implements Runnable{ // 打印次数 private static final int PRINT_COUNT = 10; private final ReentrantLock reentrantLock; private final Condition thisCondtion; private final Condition nextCondtion; private final char printChar; public syncPrinter(ReentrantLock reentrantLock, Condition thisCondtion, Condition nextCondition, char printChar) { this.reentrantLock = reentrantLock; this.nextCondtion = nextCondition; this.thisCondtion = thisCondtion; this.printChar = printChar; } @Override public void run() { // 获取打印锁 进入临界区 reentrantLock.lock(); try { // 连续打印PRINT_COUNT次 for (int i = 0; i < PRINT_COUNT; i++) { //打印字符 System.out.print(printChar); // 使用nextCondition唤醒下一个线程 // 因为只有一个线程在等待，所以signal或者signalAll都可以 nextCondtion.signal(); // 不是最后一次则通过thisCondtion等待被唤醒 // 必须要加判断，不然虽然能够打印10次，但10次后就会直接死锁 if (i < PRINT_COUNT - 1) { try { // 本线程让出锁并等待唤醒 thisCondtion.await(); } catch (InterruptedException e) { e.printStackTrace(); } } } } finally { reentrantLock.unlock(); } } public static void main(String[] args) throws InterruptedException { ReentrantLock lock = new ReentrantLock(); Condition conditionA = lock.newCondition(); Condition conditionB = lock.newCondition(); Condition conditionC = lock.newCondition(); Thread printA = new Thread(new syncPrinter(lock, conditionA, conditionB,'A')); Thread printB = new Thread(new syncPrinter(lock, conditionB, conditionC,'B')); Thread printC = new Thread(new syncPrinter(lock, conditionC, conditionA,'C')); printA.start(); Thread.sleep(100); printB.start(); Thread.sleep(100); printC.start(); } }
//手太阴肺经 BLOCKING Queue public class FooBar { private int n; private BlockingQueue<Integer> bar = new LinkedBlockingQueue<>(1); private BlockingQueue<Integer> foo = new LinkedBlockingQueue<>(1); public FooBar(int n) { this.n = n; } public void foo(Runnable printFoo) throws InterruptedException { for (int i = 0; i < n; i++) { foo.put(i); printFoo.run(); bar.put(i); } } public void bar(Runnable printBar) throws InterruptedException { for (int i = 0; i < n; i++) { bar.take(); printBar.run(); foo.take(); } } } //手阳明大肠经CyclicBarrier 控制先后 class FooBar6 { private int n; public FooBar6(int n) { this.n = n; } CyclicBarrier cb = new CyclicBarrier(2); volatile boolean fin = true; public void foo(Runnable printFoo) throws InterruptedException { for (int i = 0; i < n; i++) { while(!fin); printFoo.run(); fin = false; try { cb.await(); } catch (BrokenBarrierException e) {} } } public void bar(Runnable printBar) throws InterruptedException { for (int i = 0; i < n; i++) { try { cb.await(); } catch (BrokenBarrierException e) {} printBar.run(); fin = true; } } } //手少阴心经 自旋 + 让出CPU class FooBar5 { private int n; public FooBar5(int n) { this.n = n; } volatile boolean permitFoo = true; public void foo(Runnable printFoo) throws InterruptedException { for (int i = 0; i < n; ) { if(permitFoo) { printFoo.run(); i++; permitFoo = false; }else{ Thread.yield(); } } } public void bar(Runnable printBar) throws InterruptedException { for (int i = 0; i < n; ) { if(!permitFoo) { printBar.run(); i++; permitFoo = true; }else{ Thread.yield(); } } } } //手少阳三焦经 可重入锁 + Condition class FooBar4 { private int n; public FooBar4(int n) { this.n = n; } Lock lock = new ReentrantLock(true); private final Condition foo = lock.newCondition(); volatile boolean flag = true; public void foo(Runnable printFoo) throws InterruptedException { for (int i = 0; i < n; i++) { lock.lock(); try { while(!flag) { foo.await(); } printFoo.run(); flag = false; foo.signal(); }finally { lock.unlock(); } } } public void bar(Runnable printBar) throws InterruptedException { for (int i = 0; i < n;i++) { lock.lock(); try { while(flag) { foo.await(); } printBar.run(); flag = true; foo.signal(); }finally { lock.unlock(); } } } } //手厥阴心包经 synchronized + 标志位 + 唤醒 class FooBar3 { private int n; // 标志位，控制执行顺序，true执行printFoo，false执行printBar private volatile boolean type = true; private final Object foo= new Object(); // 锁标志 public FooBar3(int n) { this.n = n; } public void foo(Runnable printFoo) throws InterruptedException { for (int i = 0; i < n; i++) { synchronized (foo) { while(!type){ foo.wait(); } printFoo.run(); type = false; foo.notifyAll(); } } } public void bar(Runnable printBar) throws InterruptedException { for (int i = 0; i < n; i++) { synchronized (foo) { while(type){ foo.wait(); } printBar.run(); type = true; foo.notifyAll(); } } } } //手太阳小肠经 信号量 适合控制顺序 class FooBar2 { private int n; private Semaphore foo = new Semaphore(1); private Semaphore bar = new Semaphore(0); public FooBar2(int n) { this.n = n; } public void foo(Runnable printFoo) throws InterruptedException { for (int i = 0; i < n; i++) { foo.acquire(); printFoo.run(); bar.release(); } } public void bar(Runnable printBar) throws InterruptedException { for (int i = 0; i < n; i++) { bar.acquire(); printBar.run(); foo.release(); } } }
采用SpringBoot构建项目，主要通过分布式缓存、队列、限流保证系统高可用，Netty、缓存、反向代理保证高并发。
双人对战答题、公司对战抢答
性能优化过程
第一条需求很简单，使用了Redis的Zset实现不过这里总得分采用了基于分数、时间、次数和正确率的混合加权。考虑到数据的持久化，以及关系数据库和缓存的一致性导致的设计的复杂性，使用了谷歌开源的JamsRanking
优点是可以直接使用现成的setScores和getRanking接口封装了Redis和Mysql和消息队列的完成事务和一致性的使用细节。缺点是并发比较低使用Jmeter进行压测，单机只有20左右的TPS**
后来看了下源码，主要是它针对每一次设置都进行了分布式事务处理，并且会返回事务提交或回滚的结果。了解了底层实现以后就去谷歌的开源社区去查阅了相关的解决方案，当时官方对这个问题并没有通过配置能直接解决问题的快捷方式，不过推荐了使用者自身如果对响应时间不高的场景下可以采用批量合并事务的方式进行优化。基于这个思路，我们把写操作进行了封装并放入了队列，然后在消费者端批量取得数据后进行事务的批量处理，压测环境下整体性能达到了500TPS。已经基本满足了线上更新的需求，但是当时压测的过程中，队列偶尔的吞吐量会大范围波动，经常会持续数十秒，然后业务一次性处理完再响应，导致局部响应时间大幅度增长
后来也是在官网上查询，了解到谷歌开源组件使用的队列服务底层是使用BigTable作为持久层，但是当BigTable分片过大时，会触发再分片的过程，再分片的过程中，是不会进行任务分发的，所以就会导致先前的问题。针对这个问题，谷歌官方的建议是提前配置队列的数量、负载策略和最大容量等信息，保证所有队列不同时触发再分片
进行两次优化后，压测环境已经基本可以满足预期了，在实际生产环境的部署中，发现对于事务更新失败时，JamsRanking会对失败的事务进行切分和重试，整个过程对于研发人员是透明的，不利于线上问题排查，所以我们当时特地写了一个watchdog的工具，监控事务回滚达到十次以上的事务，查明原因后通过后台管理系统进行相应补偿，保证最终一致性
最终结果：
针对这个缺点谷歌官方也是给出了使用分片树和近似排名的解决方案，当然复杂的方案有更高的运维成本，所以我们优化工作也就到此为止
方案优化过程
方案1：每日一个滚动榜，当日汇聚（费时间）
首先记录每天的排行榜和一个滚动榜，加分时同时写入这两个榜单，每日零点后跑工具将前几天数据累加写入当日滚动榜，该方案缺点是时间复杂度高，7天榜还好，只需要读过去6天数据，如果是100天榜，该方案需要读过去99天榜，显然不可接受
方案2：全局N个滚动榜同时写（费空间）
要做到每日零点后榜单实时生效，而不需要等待离线作业的完成，一种方案是预写未来的榜单。可以写当天的滚动榜的同时，写往后N-1天的滚动榜一起写入该方案不仅能脱离离线作业做到实时更新，且可以省略每天的日榜。但缺点也不难看出，对于7天滚动榜，每次写操作需要更新7个榜单，但是对于百日榜，空间消耗无法接受，1000万榜单大约消耗1G内存
方案3：实时更新，常数次写操作
有不有办法做到既能实时更新，写榜数量也不随N的增加而增加呢？
仍然是记录每天的排行榜和一个滚动榜，加分操作也还是同时操作当日榜和全局榜，但每日零点的离线作业改为从全局榜中减去之前过期的数据，从而实现先滚动更新。 此方案每次只需读取一个日榜做减法，时间复杂度为O(1)；但是无法做到实时更新。 这个方案的优点是在十二点前提前准备好差分榜，到了十二点直接加上当天数据就是滚动榜内容 ，这样就在常数次写操作的前提下，实现了滚动榜的实时更新
利用setnx防止重复答题
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。 利用Redis的单线程特性对共享资源进行串行化处理
// 获取锁推荐使用set的方式String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);
// 推荐使用redis+lua脚本String lua = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";Object result = jedis.eval(lua, Collections.singletonList(lockKey)
利用redis来实现乐观锁（抢答），好处是答错的人不影响状态，第一个秒杀答对的人才能得分。
1、利用redis的watch功能，监控这个 Corp:Activ:Qust: 的状态值
2、获取Corp:Activ:Qust: 的值，创建redis事务，给这个key的值-1
3、执行这个事务，如果key的值被修改过则回滚，key不变
使用布隆过滤器：
它实际上是一个很长的二进制矢量数组和 K 个哈希函数。当一个昵称加入布隆过滤器中的时候，会进行如下操作：
用户新增昵称时需要首先计算K个哈希值，如果K个哈希值有一个不为0则通过，否则不通过，不通过时通过加随机字符串再次检验，检测通过后返回给前端，帮助用户自动填写。
布隆过滤器的好处是它可以用来判断一个元素是否在一个集合中。它的优势是只需要占用很小的内存空间以及有着高效的查询效率。对于布隆过滤器而言，它的本质是一个位数组：位数组就是数组的每个元素都只占用 1 bit ，并且每个元素只能是 0 或者 1。
BloomFilter 的优势是，全内存操作，性能很高。另外空间效率非常高，要达到 1% 的误判率，平均单条记录占用 1.2 字节即可。而且，平均单条记录每增加 0.6 字节，还可让误判率继续变为之前的 1/10，即平均单条记录占用 1.8 字节，误判率可以达到 1/1000；平均单条记录占用 2.4 字节，误判率可以到 1/10000，以此类推。这里的误判率是指，BloomFilter 判断某个 key 存在，但它实际不存在的概率，因为它存的是 key 的 Hash 值，而非 key 的值，所以有概率存在这样的 key，它们内容不同，但多次 Hash 后的 Hash 值都相同。对于 BloomFilter 判断不存在的 key ，则是 100% 不存在的，反证法，如果这个 key 存在，那它每次 Hash 后对应的 Hash 值位置肯定是 1，而不会是 0
压测环境中服务器通过Netty的主从Reactor多路复用NIO事件模型，单机可以轻松应对十万长连接，但是每个业务中，由于每个用户登录系统后需要按照指定顺序答题，例如一共要答十道，那么服务器针对这一个用户就会产生十个定时任务，所以对于系统来说，定时器的数量就是百万级别的。
通过压测结果发现：JDK自带的Timer，在大概三万并发时性能就急剧下降了。也是此时根据业务场景的需要，将定时任务改成了Netty自带的HashedWheelTimer时间轮方案，通过压测单机在50万级别下依然能够平滑的执行。
也是这个强烈的反差，使我在强烈的好奇心促使下，阅读源码了解到常规的JDK 的Timer 和 DelayedQueue 等工具类，可实现简单的定时任务，单底层用的是堆数据结构，存取复杂度都是 O(NlogN)，无法支撑海量定时任务。Netty经典的时间轮方案，正是通过将任务存取及取消操作时间复杂度降为 O(1)，而广泛应用在定时任务量大、性能要求高的场景中。
基于Netty的Websocket底层，服务器端维护一个高效批量管理定时任务的调度模型。时间轮一般会实现成一个环形数组结构，类似一个时钟，分为很多槽，一个槽代表一个时间间隔，每个槽使用双向链表存储定时任务。指针周期性地跳动，跳动到一个槽位，就执行该槽位的定时任务。
单层时间轮的容量和精度都是有限的，对于精度要求特别高、时间跨度特别大或是海量定时任务需要调度的场景，可以考虑使用多级时间轮以及持久化存储与时间轮结合的方案。时间轮的定时任务处理逻辑如下：
使用Netty的重连检测狗ConnectionWatchdog
服务端定义refreshTime，当我们从channel中read到了服务端发来的心跳响应消息的话，就刷新refreshTime为当前时间
客户端在state是WRITER_IDLE的时候每隔一秒就发送一个心跳包到sever端，告诉server端我还活着。
当重连成功时，会触发channelActive方法，在这里我们开启了一个定时任务去判断refreshTime和当前时间的时间差，超过5秒说明断线了，要进行重连，最后计算重连次数，尝试连接2次以上连不上就会修改header信息强制重连去连另一个服务器。
秒杀用到的基础组件，主要有框架、KV 存储、关系型数据库、MQ。
框架主要有 Web 框架和 RPC 框架。
其中，Web 框架主要用于提供 HTTP 接口给浏览器访问，所以 Web 框架的选型在秒杀服务中非常重要。在这里，我推荐Gin，它的性能和易用性都不错，在 GitHub 上的 Star 达到了 44k。对比性能最好的 fasthttp，虽然 fasthttp 在请求延迟低于 10ms 时性能优势明显，但其底层使用的对象池容易让人踩坑，导致其易用性较差，所以没必要过于追求性能而忽略了稳定性
至于 RPC 框架，我推荐选用 gRPC，因为它的扩展性和性能都非常不错。在秒杀系统中，Redis 中的数据主要是给秒杀接口服务使用，以便将配置从管理后台同步到 Redis 缓存中。
KV 存储方面，秒杀系统中主要是用 Redis 缓存活动配置，用 etcd 存储集群信息。
关系型数据库中，MySQL 技术成熟且稳定可靠，秒杀系统用它存储活动配置数据很合适。主要 原因还是秒杀活动信息和库存数据都缓存在 Redis 中，活动过程中秒杀服务不操作数据库， 使用 MySQL 完全能够满足需求。
MQ 有很多种，其中 Kafka 在业界认可度最高，技术也非常成熟，性能很不错，非常适合用在秒杀系统中。Kafka 支持自动创建队列，秒杀服务各个节点可以用它自动创建属于自己的队列
背景
现象
秒杀系统设计
首先，要尽力将请求拦截在系统上游，层层设阻拦截，过滤掉无效或超量的请求。因为访问量远远大于商品数量，所有的请求打到后端服务的最后一步，其实并没有必要，反而会严重拖慢真正能成交的请求，降低用户体验。
秒杀系统专为秒杀活动服务，售卖商品确定，因此可以在设计秒杀商品页面时，将商品信息提前设计为静态信息，将静态的商品信息以及常规的 CSS、JS、宣传图片等静态资源，一起独立存放到 CDN 节点，加速访问，且降低系统访问压力，在访问前端也可以制定种种限制策略，比如活动没开始时，抢购按钮置灰，避免抢先访问，用户抢购一次后，也将按钮置灰，让用户排队等待，避免反复刷新。
其次，要充分利用缓存，提升系统的性能和可用性。
用户所有的请求进入秒杀系统前，通过负载均衡策略均匀分发到不同 Web 服务器，避免节点过载。在 Web 服务器中，首先检查用户的访问权限，识别并发刷订单的行为。如果发现售出数量已经达到秒杀数量，则直接返回结束，要将秒杀业务系统和其他业务系统进行功能分拆，尽量将秒杀系统及依赖服务独立分拆部署，避免影响其他核心业务系统。
秒杀系统需要构建访问记录缓存，记录访问 IP、用户的访问行为，发现异常访问，提前进行阻断及返回。同时还需要构建用户缓存，并针对历史数据分析，提前缓存僵尸强刷专业户，方便在秒杀期间对其进行策略限制。这些访问记录、用户数据，通过缓存进行存储，可以加速访问，另外，对用户数据还进行缓存预热，避免活动期间大量穿透。
mysql乐观锁+redis预减库存+redis缓存卖完标记
第一是基于数据库乐观锁的方式保证数据并发扣减的强一致性；
第二是基于数据库的事务实现批量扣减部分失败时的数据回滚。
在扣减指定数量前应先做一次前置数量校验的读请求（参考读写分离 + 全缓存方案）
纯数据库乐观锁+事务的方式性能比较差，但是如果不计成本和考虑场景的话也完全够用，因为任何没有机器配置的指标，都是耍流氓。如果我采用 Oracle 的数据库、100 多核的刀锋服务器、SSD 的硬盘，即使是纯数据库的扣减方案，也是可以达到单机上万的 TPS 的。
单线程Redis 的 lua 脚本实现批量扣减
当用户调用扣减接口时，将扣减的 对应数量 + 脚本标示传递至 Redis 即可，所有的扣减判断逻辑均在 Redis 中的 lua 脚本中执行，lua 脚本执行完成之后返还是否成功给客户端。
Redis 中的 lua 脚本执行时，首先会使用 get 命令查询 uuid 进行查重。当防重通过后，会批量获取对应的剩余库存状态并进行判断，如果一个扣减的数量大于剩余数量，则返回错误并提示数量不足。
Redis 的单线程模型，确保不会出现当所有扣减数量在判断均满足后，在实际扣减时却数量不够。同时，单线程保证判断数量的步骤和后续扣减步骤之间，没有其他任何线程出现并发的执行。
当 Redis 扣减成功后，扣减接口会异步的将此次扣减内容保存至数据库。异步保存数据库的目的是防止出现极端情况—— Redis 宕机后数据未持久化到磁盘，此时我们可以使用数据库恢复或者校准数据
最后，运营后台直连数据库，是运营和商家修改库存的入口。商家在运营后台进货物进行补充。同时，运营后台的实现需要将此数量同步的增加至 Redis，因为当前方案的所有实际扣减都在 Redis 中
纯缓存方案虽不会导致超卖，但因缓存不具备事务特性，极端情况下会存在缓存里的数据无法回滚，导致出现少卖的情况。且架构中的异步写库，也可能发生失败，导致多扣的数据丢失
可以借助顺序写的特性，将扣减任务同步插入任务表，发现异常时，将任务表作为undolog进行回滚
可以解决由于网络不通、调用缓存扣减超时、在扣减到一半时缓存突然宕机（故障 failover）了。针对上述请求，都有相应的异常抛出，根据异常进行数据库回滚即可，最终任务库里的数据都是准的
更进一步：由于任务库是无状态的，可以进行水平分库，提升整体性能
mysql唯一索引+分布式锁
IP限流 | 验证码 | 单用户 | 单设备 | IMEI | 源IP |均设置规则
redis集群+本地缓存+限流+key加随机值分布在多个实例中
1、缓存集群可以单节点进行主从复制和垂直扩容
2、利用应用内的前置缓存，但是需注意需要设置上限
3、延迟不敏感，定时刷新，实时感知用主动刷新
4、和缓存穿透一样，限制逃逸流量，单请求进行数据回源并刷新前置
5、无论如何设计，最后都要写一个兜底逻辑，千万级流量说来就来
使用缓存策略将请求挡在上层中的缓存中
使用CDN，能静态化的数据尽量做到静态化，
加入限流（比如对短时间之内来自某一个用户，某一个IP、某个设备的重复请求做丢弃处理）
资源隔离限流会将对应的资源按照指定的类型进行隔离，比如线程池和信号量。
对于一段时间内的秒杀活动，需要保证写成功，我们可以使用 消息队列。
削去秒杀场景下的峰值写流量
通过异步处理简化秒杀请求中的业务流程
先处理主要的业务，异步处理次要的业务。
解耦
实现秒杀系统模块之间松耦合将秒杀数据同步给数据团队，有两种思路：
CacheAside旁路缓存读请求不命中查询数据库，查询完成写入缓存，写请求更新数据库后删除缓存数据。
// 延迟双删，用以保证最终一致性,防止小概率旧数据读请求在第一次删除后更新数据库public void write(String key,Object data){ redis.delKey(key); db.updateData(data); Thread.sleep(1000); redis.delKey(key);}
为防缓存失效这一信息丢失，可用消息队列确保。
订阅binlog程序在mysql中有现成的中间件叫canal，重试机制，主要采用的是消息队列的方式。
终极方案：请求串行化
真正靠谱非秒杀的方案：将访问操作串行化
需要解决的问题：
由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。哨兵模式适合读请求远多于写请求的业务场景，比如在秒杀系统中用来缓存活动信息。 如果写请求较多，当集群 Slave 节点数量多了后，Master 节点同步数据的压力会非常大。
当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。
秒杀服务单节点需要处理的请求 QPS 可能达到 10 万以上。一个请求从进入秒杀服务到处理失败或者成功，至少会产生两条日志。也就是说，高峰期间，一个秒杀节点每秒产生的日志可能达到 30 万条以上
一块性能比较好的固态硬盘，每秒写的IOPS 大概在 3 万左右。也就是说，一个秒杀节点的每秒日志条数是固态硬盘 IOPS 的 10 倍，磁盘都扛不住，更别说通过网络写入到监控系统中。
解决方案
10、池化技术
通常可以采用循环队列来保存空闲连接。使用的时候，可以从队列头部取出连接，用完后将空闲连接放到队列尾部。Netty中利用带缓冲区的 channel 来充当队列。
TCP保证消息可靠传输三板斧：超时、重传、确认。服务端和客户端通信MSG和ACK的共计6个报文
在线消息流程：
A 消息请求 MSG:R => S 消息应答 MSG:A => S 消息通知B MSG:N
S 确认通知 ACK:N <= S 确认应答 ACK:A <= B确认请求S ACK:R
超时与重传、确认和去重：
A发出了 MSG:R ，收到了MSG:A之后，在一个期待的时间内，如果没有收到ACK:N，A会尝试将 MSG:R 重发。可能A同时发出了很多消息，所以A需要在本地维护一个等待ack队列，并配合timer超时机制，来记录哪些消息没有收到ACK:N，定时重发。确认ACK保证必达，去重保证唯一
离线消息流程
原方案：根据离线好友的标识，交互拉取指定的消息
优化的方案：
在线的群友能第一时间收到消息；
离线的群友能在登陆后收到消息。
对于同一份群消息的内容，多个离线用户存储了很多份。假设群中有200个用户离线，离线消息则冗余了200份，这极大的增加了数据库的存储压力
方案：
优化：
历史方案：
“消息风暴扩散系数”是指一个消息发出时，变成N个消息的扩散系数，这个系数与业务及数据相关，一定程度上它的大小决定了技术采用推送还是拉取。
优化方案：
Neo4j 图谱数据库
18年初，针对我们Dubbo框架的智慧楼宇项目的单体服务显得十分笨重，需要采用微服务的形式进行架构的重新设计，当时，我阅读了Eric Evans 写的《领域驱动设计：软件核心复杂性应对之道》和Martin fowler的《微服务架构：Microservice》两本重量级书籍，书中了解到转型微服务的重要原因之一就是利用分治的思想减少系统的复杂性，是一种针对复杂问题的宏观设计，来应对系统后来规模越来越大，维护越来越困难的问题。然而，拆分成微服务以后，并不意味着每个微服务都是各自独立地运行，而是彼此协作地组织在一起。这就好像一个团队，规模越大越需要一些方法来组织，这正是我们需要DDD模型为我们的架构设计提供理论并实践的方法。
当时每次版本更新迭代动辄十几个微服务同时修改，有时一个简单的数据库字段变更，也需要同时变更多个微服务，引起了团队的反思：微服务化看上去并没有减少我们的工作量。《企业架构设计》中对于微服务的定义是小而专，但在起初的设计时，我们只片面的理解了小却忽视了专，此时我们才意识到拆分的关键是要保证微服务内高内聚，微服务间低耦合。
物联网是互联网的外延。将用户端延伸和扩展到物与人的连接。物联网模式中，所有物品与网络连接，并进行通信和场景联动。互联网通过电脑、移动终端等设备将参与者联系起来，形成的一种全新的信息互换方式
DCM系统架构
三要素
云 / 边 / 端协同
云端计算、终端计算和边缘计算是一个协同的系统，根据用户场景、资源约束程度、业务实时性等进行动态调 配，形成可靠、低成本的应用方案。从过去几年的发展积累来看，AI 已在物联网多个层面进行融合，比我们合作的海康威视、旷视宇视、商汤科技等纷纷发布了物联网AI相关平台和产品，和移动和小区进行了紧密的融合。
物联网平台接入
向下连接海量设备，支撑设备数据采集上云；
向上通过调用云端API将指令下发至设备端，实现远程控制。
上行数据链路
下行指令链路
门锁接入
WIFI门锁：非保活 平常处于断电休眠状态，需要MCU 唤醒才能传输和发送数据
蓝牙门锁：MCU串口对接和SDK对接，近距离单点登录和远距离网关登录
Zigbee门锁：非保活 但是保持心跳，MCU对接，Zigbee协议控制。
NB-Iot门锁：可以通过公网连接，把门禁变成SAAS服务，MCU
| 名词 |
解释 |
| SaaS |
Software-as-a-Service ，提供给客户的服务是运营商运行在云计算基础设施上的应用程序。用户可以在各种设备上通过客户端界面访问应用，例如计算机浏览器。用户不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等资源，一切由 SaaS 提供商管理和运维。 |
| PaaS |
Platform-as-a-Service，表示平台即服务理念，客户不需要管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储等，但客户能控制部署的应用程序，也可能控制运行应用程序的托管环境配置。 |
| IaaS |
Infrastructure-as-a-Service ，表示基础设施即服务理念，提供的服务是对所有计算基础设施的利用，包括 CPU、内存、存储、网络等其它计算资源。用户能够部署和运行任意软件，包括操作系统和应用程序。 |
各种协议
HTTP协议（CS用户上网）
HTTP协议是典型的CS通讯模式，由客户端主动发起连接，向服务器请求XML或JSON数据。该协议最早是为了适用web浏览器的上网浏览场景和设计的，目前在PC、手机、pad等终端上都应用广泛，但并不适用于物联网场景
RESTAPI（松耦合调用）
REST/HTTP主要为了简化互联网中的系统架构，快速实现客户端和服务器之间交互的松耦合，降低了客户端和服务器之间的交互延迟。因此适合在物联网的应用层面，通过REST开放物联网中资源，实现服务被其他应用所调用。
CoAP协议（无线传感）
简化了HTTP协议的RESTful API，它适用于在资源受限的通信的IP网络。
MQTT协议（低带宽）
MQTT协议采用发布/订阅模式，物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，负责将设备与设备之间消息的转发
适用范围：在低带宽、不可靠的集中星型网络架构（hub-and-spoke），不适用设备与设备之间通信，设备控制能力弱，另外实时性较差，一般都在秒级。协议要足够轻量，方便嵌入式设备去快速地解析和响应。具备足够的灵活性，使其足以为 IoT 设备和服务的多样化提供支持。应该设计为异步消息协议，这么做是因为大多数 IoT 设备的网络延迟很可能非常不稳定，若使用同步消息协议，IoT 设备需要等待服务器的响应，必须是双向通信，服务器和客户端应该可以互相发送消息。
AMQP协议（互操作性）
用于业务系统例如PLM，ERP，MES等进行数据交换。
适用范围：最早应用于金融系统之间的交易消息传递，在物联网应用中，主要适用于移动手持设备与后台数据中心的通信和分析。
XMPP协议（即时通信）
开源形式组织产生的网络即时通信协议。被IETF国际标准组织完成了标准化工作
适用范围：即时通信的应用程序，还能用在协同工具、游戏等。
XMPP在通讯的业务流程上是更适合物联网系统的，开发者不用花太多心思去解决设备通讯时的业务通讯流程，相对开发成本会更低。但是HTTP协议中的安全性以及计算资源消耗的硬伤并没有得到本质的解决。
JMS （Java消息服务）
Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
Zigbee协议
低功耗，它保持IEEE 802.15.4（2003）标准
智慧社区IOT领域，不管是嵌入式芯片还是应用服务器都需要传递消息，常见上行的消息有：人脸识别开门、烟感雾感告警、共享充电桩充电，下行的广告下发、NB门禁开门指令、超级门板显示等，由于物联网设备时不时会故障和断网导致大量的流量洪峰，传统消息队列需要针对性优化。
如果解决海量Topic
首先要做的就是分区、分组等水平拆分的方式，接下来考虑单实例如何处理更多Topic，传统消息队列在海量Topic下顺序写会退化成随机写，性能大幅下降
针对单个Topic海量订阅的问题，可以在上层封装广播组件来协调批量发送
使用端 / 边 / 云三级架构，客户端加密传输，边缘节点转发、云侧转码并持久化
产品的背景
上线时间，从调研到正式上线用了 3个月时间，上线后一个月内就要经历双十二挑战。在这么紧的上线时间要求下，需要用到公司提供的所有优势，包括cdn网络，直播牌照等
面临的挑战
协议的比较
| 协议 |
上线时间 |
网络兼容 |
端对端延迟 |
应用大小 |
问题 |
| WebRTC |
✗ |
Webrtc 基于 UDP，和社区应用的网络架构不兼容 |
|||
| HTTP Upload |
✗ |
会导致网络高延迟 |
|||
| Custom Protocol |
✗ |
工程师需要实现自己的客户端与服务端的库，无法按时上线 |
|||
| Proprietary |
✗ |
协议就需要几兆的空间，超出额度 |
|||
| RTMPS |
✔ |
✔ |
✔ |
✔ |
TCP实时传输消息协议，更安全更可靠 |
整体流程
RTMPS：基于TCP实时传输消息协议，更安全更可靠
MPEG-DASH：是一种基于HTTP协议自适应比特率流媒体技术，应对复杂的环境
直播流程
播放流程
收获
网络可靠性：
惊群效应：
数据库优化： 数据库是最容易成为瓶颈的组件，考虑从 SQL 优化或者数据库本身去提高它的性能。如果瓶颈依然存在，则会考虑分库分表将数据打散，如果这样也没能解决问题，则可能会选择缓存组件进行优化
集群最优：存储节点的问题解决后，计算节点也有可能发生问题。一个集群系统如果获得了水平扩容的能力，就会给下层的优化提供非常大的时间空间，由最初的 3 个节点，扩容到最后的 200 多个节点，但由于人力问题，服务又没有什么新的需求，下层的优化就一直被搁置着。
硬件升级：水平扩容不总是有效的，原因在于单节点的计算量比较集中，或者 JVM 对内存的使用超出了宿主机的承载范围。在动手进行代码优化之前，我们会对节点的硬件配置进行升级。
代码优化：代码优化是提高性能最有效的方式，但需要收集一些数据，这个过程可能是服务治理，也有可能是代码流程优化。比如JavaAgent 技术，会无侵入的收集一些 profile 信息，供我们进行决策。
并行优化：并行优化是针对速度慢的接口进行并行调用。所以我们通常使用 ContDownLatch 对需要获取的数据进行并行处理，效果非常不错，比如在 200ms 内返回对 50 个耗时 100ms 的下层接口的调用。
JVM 优化： JVM 发生问题时，优化会获得巨大的性能提升。但在 JVM 不发生问题时，它的优化效果有限。但在代码优化、并行优化、JVM 优化的过程中，JVM 的知识却起到了关键性的作用
操作系统优化：操作系统优化是解决问题的杀手锏，比如像 HugePage、SWAP、“CPU 亲和性”这种比较底层的优化。但就计算节点来说，对操作系统进行优化并不是很常见。运维在背后会做一些诸如文件句柄的调整、网络参数的修改，这对于我们来说就已经够用了
系统级的重构，测试回归的工作量至少都是以月为单位，对于人力的消耗巨大。一种应对方案是，先不改造，到系统实在扛不住了再想办法。另一种应对方案是，先暂停需求，全力进行改造。但在实际工作场景中，上述应对策略往往很难实现。
场景：
1、读服务均是查询，它是无状态的。
2、不管是架构升级还是日常需求，读服务对外接口的出入参格式是没有变化的
方法论
Discovery
考虑企业战略，分析客户需求，制定产品目标
由外到内：竞争对手的方案，为什么做，以后怎么发展，如何去优化。
自上而下：基于公司的战略，考虑自身能力和所处环境。
自下而上：从资源、历史问题、优先级出发，形成一套可行性实施方法。
Define
基于收集的信息，综合跨业务线的抽象能力和服务，先做什么后做什么，怎么做
设计新的架构，重点设计解决痛点问题。
拆分业务领域，重点划分工作临界上下文。
Design
详细的业务设计，功能设计，交付计划，考核计划
产品愿景，产品形态，相关竞品方案对比，价值、优势、收益
梳理业务范围，要知道电商领域四大流（信息流、商流、资金流、物流）
MVP最小可用比，让客户和老大看到结果，最后通编写story把故事编圆
Delivery
交付阶段，根据反馈及时调整中台战略，减少损失和增大收益
合理制定每个阶段的绩效考核目标：
40%稳定+25%业务创新+20%服务接入+15%用户满意度
系统拆分
通过DDD领域模型，对服务进行拆分，将一个系统拆分为多个子系统，做成SpringCloud的微服务。微服务设计时要尽可能做到少扇出，多扇入，根据服务器的承载，进行客户端负载均衡，通过对核心服务的上游服务进行限流和降级改造。
一个服务的代码不要太多，1 万行左右，两三万撑死了吧。
大部分的系统，是要进行多轮拆分的，第一次拆分，可能就是将以前的多个模块该拆分开来了，比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统等等吧。
但是后面可能每个系统又变得越来越复杂了，比如说采购系统里面又分成了供应商管理系统、采购单管理系统，订单系统又拆分成了购物车系统、价格系统、订单管理系统。
CDN、Nginx静态缓存、JVM缓存
利用Java的模板thymeleaf可以将页面和数据动态渲染好，然后通过Nginx直接返回。动态数据可以从redis中获取。其中redis里的数据由一个缓存服务来进行消费指定的变更服务。
商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。
缓存
Redis cluster，10 台机器，5主5从，5 个节点对外提供读写服务，每个节点的读写高峰 QPS 可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求每秒。
32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 Redis 进程的是 10g 内存，一般线上生产环境，Redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。
因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，Redis 从实例会自动变成主实例继续提供读写服务。
MQ
可以通过消息队列对微服务系统进行解耦，异步调用的更适合微服务的扩展
同时可以应对秒杀活动中[应对高并发写请求](# 6、应对高并发的写请求)，比如kafka在毫秒延迟基础上可以实现10w级吞吐量
针对IOT流量洪峰做了一些特殊的优化，保证消息的及时性
同时可以使用消息队列保证分布式系统最终一致性
分库分表
分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就 将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个 表，每个表的数据量保持少一点，提高 sql 跑的性能。在通讯录、订单和商城商品模块超过千万级别都应及时考虑分表分库
读写分离
读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都 集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。 读流量太多的时候，还可以加更多的从库。比如统计监控类的微服务通过读写分离，只需访问从库就可以完成统计，例如ES
ElasticSearch
Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作，比如运营平台上的各地市的汇聚统计，还有一些全文搜索类的操作，比如通讯录和订单的查询。
基于 Hash 取模、一致性 Hash 实现分库分表
高并发读可以通过多级缓存应对
大促销热key读的问题通过redis集群+本地缓存+限流+key加随机值分布在多个实例中
高并发写的问题通过基于 Hash 取模、一致性 Hash 实现分库分表均匀落盘
业务分配不均导致的热key读写问题，可以根据业务场景进行range分片，将热点范围下的子key打散
具体实现：预先设定主键的生成规则，根据规则进行数据的分片路由，但这种方式会侵入商品各条线主数据的业务规则，更好的方式是基于分片元数据服务器（即每次访问分片前先询问分片元服务器在路由到实际分片）不过会带来复杂性，比如保证元数据服务器的一致性和可用性。
尽量避免分布式事务，单进程用数据库事务，跨进程用消息队列
主流实现分布式系统事务一致性的方案：
理论上也可以使用（2PC两阶段提交、3PC三阶段提交、TCC短事务、SAGA长事务方案），但是这些方案工业上落地代价很大，不适合互联网的业界场景。针对金融支付等需要强一致性的场景可以通过前两种方案实现。（展开说的话参考分布式事务）
本地数据库事务原理：undo log（原子性） + redo log（持久性） + 数据库锁（原子性&隔离性） + MVCC（隔离性）
分布式事务原理：全局事务协调器（原子性） + 全局锁（隔离性） + DB本地事务（原子性、持久性）
一、我们公司账单系统和第三方支付系统对账时，就采用“自研补偿/MQ方案 + 人工介入”方式
落地的话：方案最“轻”，性能损失最少。可掌控性好，简单易懂，易维护。
考虑到分布式事务问题是小概率事件，留有补救余地就行，性能的损失可是实打实的反应在线上每一个请求上
二、也了解到业界比如阿里成熟Seata AT模式，平均性能会降低35%以上
我觉得不是特殊的场景不推荐
三、RocketMQ事务消息
听起来挺好挺简单的方案，但它比较挑业务场景，同步性强的处理链路不适合。
【重要】要求下游MQ消费方一定能成功消费消息。否则转人工介入处理。
【重要】千万记得实现幂等性。
由于项目需要进行数据割接，保证用户多平台使用用户感知的一致，将广东项目的几百万用户及业务数据按照一定的逻辑灌到社区云平台上，由于依赖了第三方统一认证和省侧crm系统，按照之前系统内割接的方法，通过数据库将用户的唯一标识查出来然后使用多线程向省侧crm系统获取结果。
但是测试的过程中，发现每个线程请求的数据发生了错乱，导致每个请求处理的数据有重复，于是立即停止了脚本，当时怀疑是多线程对资源并发访问导致的，于是把ArrayList 改成了CopyOnWriteArrayList，但是折腾了一晚上，不管怎么修改，线程之间一直有重复数据，叫了一起加班的同事也没看出问题来，和同事估算了一下不使用多线程，大概30-40个小时能跑完，想了下也能接受，本来已经准备放弃了。
不过回到家，我还是用多线程仔细单步模拟了下，整个处理的过程，发现在起线程的时候，有些子线程并没有把分配给他的全部id的list处理完，导致最终状态没更新，新线程又去执行了一遍，然后我尝试通过修改在线程外深拷贝一个List再作为参数传入到子线程里，（后续clear的时候也是clear老的List）果然，整个测试过程中再也没出现过重复处理的情况。
事后，我也深究了下原因：
if(arrayBuffer.length == 99) { val asList = arrayBuffer.toList exec.execute ( openIdInsertMethod(asList) ) arrayBuffer.clear }
在一个线程中开启另外一个新线程，则新开线程称为该线程的子线程，子线程初始优先级与父线程相同。不过主线程先启动占用了cpu资源，因此主线程总是优于子线程。然而，即使设置了优先级，也无法保障线程的执行次序。只不过，优先级高的线程获取CPU资源的概率较大，优先级低的并非没机会执行。
所以主线程上的clear操作有可能先执行，那么子线程中未处理完的数据就变成一个空的数组，所以就出现了多个线程出现了重复数据的原因，所以我们要保证的是子线程每次执行完后再进行clear即可。而不是一开始定位的保证ArrayList的安全性。所以将赋值(buffer->list)操作放在外面去执行后，多线程数据就正常了。
[见秒杀项目方案设计](# 二、秒杀项目)
中小规模的计数服务（万级）
最常见的计数方案是采用缓存 + DB 的存储方案。当计数变更时，先变更计数 DB，计数加 1，然后再变更计数缓存，修改计数存储的 Memcached 或 Redis。这种方案比较通用且成熟，但在高并发访问场景，支持不够友好。在互联网社交系统中，有些业务的计数变更特别频繁，比如微博 feed 的阅读数，计数的变更次数和访问次数相当，每秒十万到百万级以上的更新量，如果用 DB 存储，会给 DB 带来巨大的压力，DB 就会成为整个计数服务的瓶颈所在。即便采用聚合延迟更新 DB 的方案，由于总量特别大，同时请求均衡分散在大量不同的业务端，巨大的写压力仍然是 DB 的不可承受之重。
大型互联网场景（百万级）
直接把计数全部存储在 Redis 中，通过 hash 分拆的方式，可以大幅提升计数服务在 Redis 集群的写性能，通过主从复制，在 master 后挂载多个从库，利用读写分离，可以大幅提升计数服务在 Redis 集群的读性能。而且 Redis 有持久化机制，不会丢数据
一方面 Redis 作为通用型存储来存储计数，内存存储效率低。以存储一个 key 为 long 型 id、value 为 4 字节的计数为例，Redis 至少需要 65 个字节左右，不同版本略有差异。但这个计数理论只需要占用 12 个字节即可。内存有效负荷只有 12/65=18.5%。如果再考虑一个 long 型 id 需要存 4 个不同类型的 4 字节计数，内存有效负荷只有 (8+16)/(65*4)= 9.2%。
另一方面，Redis 所有数据均存在内存，单存储历史千亿级记录，单份数据拷贝需要 10T 以上，要考虑核心业务上 1 主 3 从，需要 40T 以上的内存，再考虑多 IDC 部署，轻松占用上百 T 内存。就按单机 100G 内存来算，计数服务就要占用上千台大内存服务器。存储成本太高。
微博、微信、抖音（亿级）
定制数据结构，共享key 紧凑存储，提升计数有效负荷率
超过阈值后数据保存到SSD硬盘，内存里存索引
冷key从SSD硬盘中读取后，放入到LRU队列中
自定义主从复制的方式，海量冷数据异步多线程并发复制
确认使用的对象（ToC：高并发，ToB：高可用）
系统的服务场景（即时通信：低延迟，游戏：高性能，购物：秒杀-一致性）
用户量级（万级：双机、百万：集群、亿级：弹性分布式、容器化编排架构）
百万读：3主6从，每个节点的读写高峰 QPS 可能可以达到每秒 5 万，可以实现15万，30万读性能
亿级读，通过CDN、静态缓存、JVM缓存等多级缓存来提高读并发
百万写，通过消息队列削峰填谷，通过hash分拆，水平扩展分布式缓存
亿级写，redis可以定制数据结构、SSD+内存LRU、冷数据异步多线程复制
持久化，（Mysql）承受量约为 1K的QPS，读写分离提升读并发，分库分表提升写并发
核心功能包括什么：
写功能：发送微博
读功能：热点资讯
交互：点赞、关注
键值存储 : Redis ( 热点资讯 )
文档存储 : MongoDB ( 微博文档分类)
分词倒排：Elasticsearch（搜索）
列型存储：Hbase、BigTable（大数据）
图形存储：Neo4j （社交及推荐）
多媒体：FastDfs（图文视频微博）
实现哪些功能：
筛选出核心功能（Post a Tweet，Timeline，News Feed，Follow/Unfollow a user，Register/Login）
承担多大QPS：
QPS = 100，那么用我的笔记本作Web服务器就好了
QPS = 1K，一台好点的Web 服务器也能应付，需要考虑单点故障；
QPS = 1m，则需要建设一个1000台Web服务器的集群，考虑动态扩容、负载分担、故障转移
一台 SQL Database （Mysql）承受量约为 1K的QPS；
一台 NoSQL Database (Redis) 约承受量是 20k 的 QPS；
一台 NoSQL Database (Memcache) 约承受量是 200k 的 QPS；
微服务战略拆分
针对不同服务选择不同存储
设计数据表的结构
基本差不多就形成了一个解决方案，但是并不是完美的，仍然需要小步快跑的不断的针对消息队列、缓存、分布式事务、分表分库、大数据、监控、可伸缩方面进行优化
微服务内高内聚，微服务间低耦合
微服务内高内聚即单一职责原则
每个微服务中的代码变化都是同一类原因。因这类原因而需要变更的代码都在这个微服务中，与其他微服务无关，那么就可以将代码修改的范围缩小到这个微服务内。把这个微服务修改好了，独立修改、独立发布，该需求就实现了。这样，微服务的优势才能发挥出来。
微服务间低耦合开放封闭原则
就是说在微服务实现自身业务的过程中，如果需要执行的某些过程不是自己的职责，就应当将这些过程交给其他微服务去实现，你只需要对它的接口进行调用。这样，微服务之间的调用就实现了解耦。
领域建模就是将一个系统划分成了多个子域，每个子域都是一个独立的业务场景，每个子域的边界就是“限界上下文”。该业务场景会涉及许多领域对象，但分析建模始终需要围绕着业务场景的上下文进行。
领域事件通知机制最有效的方式就是通过消息队列，实现领域事件在微服务间的通知。
“核心通讯录”微服务只负责发送变更消息到消息队列，不管谁会接收并处理这些消息；
“门禁管理”微服务只负责接收照片变更消息，不管谁发送的这个消息。
通过合理的微df服务设计，尽量让每次的需求变更都交给某个小团队独立完成，让需求变更落到某个微服务上进行变更。唯有这样，每次变更只需独立地修改这个微服务，独立打包、独立升级，新需求独立实现，才能发挥微服务的优势。
贫血模型、充血模型、策略模式、装饰者模式只是DDD实现的方式，而DDD的真谛是领域建模。
做事不能仅凭一腔热血，一定要符合自然规律。其实软件的设计开发过程也是这样。对业务理解不深刻全局架构设计往往是过度设计，这时候应该抓主要流程，开始领域建模。
保持软件设计不退化的关键在于每次需求变更的设计，只有保证每次需求变更时做出正确的设计，才能保证软件以一种良性循环的方式不断维护下去。
有没有一种方法，让我们在第十次变更、第二十次变更、第三十次变更时，依然能够找到正确的设计呢？有，那就是领域驱动设计
那么在每次需求变更时，将变更还原到真实世界中，看看真实世界是什么样子的，根据真实世界进行变更。
领域和子域（Domain/Subdomain）
在上下文地图构建的领域中，对应模块，使用限界上下文划分领域，对应微服务
限界上下文（Bounded Context）
在一个领域/子域中，有概念上的领域边界，任何领域对象在该边界内部的有不依赖外部的确切含义。
领域对象
服务、实体与值对象是领域驱动设计的领域对象，可以通过贫血模型和充血模型转换为程序设计
实体和值对象
通过一个唯一标识字段来区分真实世界中的每一个个体的领域对象，称为实体。真实世界中那些一成不变的、本质性的事物的领域对象，称为值对象。 可变性是实体的特点，而不变性则是值对象的本质。
贫血模型与充血模型
POJO对象中只保存get/set方法，没有任何业务逻辑，这样的设计被称为贫血模型
充血模型是封装和继承思想的体现，门禁设备实体中，包含特征值下发、广告下发、通行记录回调等方法，不同厂商的实体针对多态进行聚合，并通过工厂或仓库对外提供服务。在充血模型中， Service 只干一件非常简单的事，就是直接去调用对象中的工厂方法生成不同产品，其他的什么都不干。
聚合
聚合体现的是一种整体与部分的关系。正是因为有这样的关系，在操作整体的时候，整体就封装了对部分的操作。如何正确理解是否存在聚合的关系：就是当整体不存在时，部分就变得没有了意义。部分是整体的一个部分，与整体有相同的生命周期。
工厂
通过装配，创建领域对象，是领域对象生命周期的起点。譬如，系统要通过 ID 装载一个访客申请：
仓库
如果服务器是一个非常强大的服务器，那么我们不需要任何数据库。系统创建的所有领域对象都放在仓库中，当需要这些对象时，通过 ID 到仓库中去获取。