首页  思维导图  详情

计算机知识梳理

2023-04-23 09:35:34   0  举报





AI智能生成

为你推荐

查看更多



计算机全部知识梳理

作者其他创作

大纲/内容

1+1=2 加法器

先行进位&并行进位

电控开关

计算机系统底层架构

对称多处理器结构

这样的架构对软件层面来说非常容易，总线模型保证所有的内存访问是一致的，即每个处理器核心共享相同的内存地址空间

UMA(Uniform Memory Access)，直译为“统一内存访问”

对称多处理器结构(SMP：Symmetric Multi-Processor)

不同的内存器件和CPU核心从属不同的 Node，每个 Node 都有自己的集成内存控制器（IMC，Integrated Memory Controller）。

不同的 Node 间通过QPI（Quick Path Interconnect）进行通信

QPI的延迟要高于IMC Bus，也就是说CPU访问内存有了远近（remote/local）之别，而且实验分析来看，这个差别非常明显。

非一致存储访问结构(NUMA：Non-Uniform Memory Access)

海量并行处理结构(MPP：Massive Parallel Processing)。

服务器

均匀存储器存取（Uniform-Memory-Access，简称UMA）模型

非均匀存储器存取（Nonuniform-Memory-Access，简称NUMA）模型

存储器共享方式

ARM公司: arm架构

intel公司: intelx86系列架构

AMD公司: amdx86系列架构

品牌

架构

提供了8个64bit的寄存器进行SIMD操作

通过复用CPU内部x87浮点单元的寄存器来实现SIMD的，所以与运行浮点运算的x87指令集有冲突，两者不能交叉使用，必须先进行切换

只支持整数操作

MMX（Multi Media eXtension，多媒体扩展指令集）

SSE系列提供了8个128bit的寄存器进行SIMD操作

引入新的独立寄存器解决了与浮点运算间的冲突问题

SSE（Stream SIMD Extentions，数据流单指令多数据扩展）

Intel AVX指令集，在单指令多数据流计算性能增强的同时也沿用了的MMX/SSE指令集。不过和MMX/SSE的不同点在于增强的AVX指令，从指令的格式上就发生了很大的变化。x86(IA-32/Intel 64)架构的基础上增加了prefix(Prefix)，所以实现了新的命令，也使更加复杂的指令得以实现，从而提升了x86 CPU的性能。

AVX指令集

AVX2

512-bit

AVX512

SIMD（Single Instruction Multiple Data）是单指令多数据技术

SIMD

指令指针寄存器

寄存器

存放指令

指令寄存器（IR ）

从主存获取操作数放入高速缓存L1

操作用户程序数据段

指令译码器（ ID ）

从用户程序取指令，放入寄存器

操作控制器（ OC ）

控制器

运算器

组成

内存屏障(Memory Barrier)

该变量超过一个缓存行的大小，缓存一致性协议是针对单个缓存行进行加锁，此时，缓存一致性协议无法再对该变量进行加锁，只能改用总线加锁的方式。

1、CPU1从内存中将变量a加载到缓存中，并将变量a的状态改为E（独享），并通过总线嗅探机制对内存中变量a的操作进行嗅探

2、此时，CPU2读取变量a，总线嗅探机制会将CPU1中的变量a的状态置为S（共享），并将变量a加载到CPU2的缓存中，状态为S

3、CPU1对变量a进行修改操作，此时CPU1中的变量a会被置为M（修改）状态，而CPU2中的变量a会被通知，改为I（无效）状态，此时CPU2中的变量a做的任何修改都不会被写回内存中（高并发情况下可能出现两个CPU同时修改变量a，并同时向总线发出将各自的缓存行更改为M状态的情况，此时总线会采用相应的裁决机制进行裁决，将其中一个置为M状态，另一个置为I状态，且I状态的缓存行修改无效）

4、CPU1将修改后的数据写回内存，并将变量a置为E（独占）状态

5、此时，CPU2通过总线嗅探机制得知变量a已被修改，会重新去内存中加载变量a，同时CPU1和CPU2中的变量a都改为S状态

modified（修改）、exclusive（互斥）、share（共享）、invalid（无效）

Intel 的MESI协议

缓存一致性协议

总线

L1 data cache（DL1）

L1 instruction cache（IL1）

32KB

256KB

3MB

1B（字节）=8b（位）

这个缓存行可以被许多线程访问。如果其中一个修改了v2，那么会导致Thread1和Thread2都会重新加载整个缓存行。你可能会疑惑为什么修改了v2会导致Thread1和Thread2重新加载该缓存行，毕竟只是修改了v2的值啊。虽然说这些修改逻辑上是互相独立的，但同一缓存行上的数据是统一维护的，一致性的粒度并非体现在单个元素上。这种不必要的数据共享就称之为“伪共享”(False Sharing)。

伪共享”(False Sharing)

多级缓存

其中段基地址在程序启动的时候确认，尽管这个段基地址还是绝对的物理地址，但终究可以同时运行多个程序了， CPU 采用这种方式访问内存，就需要段基址寄存器和段内偏移地址寄存器来存储地址，最终将两个地址相加送上地址总线。

伟大的计算机前辈设计出，让 CPU 采用段基址 + 段内偏移地址的方式访问内存

连续的地址空间

内存分页

内存分段，相当于每个进程都会分配一个内存段，而且这个内存段需要是一块连续的空间，主存里维护着多个内存段，当某个进程需要更多内存，并且超出物理内存的时候，就需要将某个不常用的内存段换到硬盘上，等有充足内存的时候在从硬盘加载进来，也就是 swap 。每次交换都需要操作整个段的数据。

内存分段

虚拟存储

正常情况下，我们读取文件的流程为，系统调用从磁盘读取数据，存入操作系统的内核缓冲区，然后在从内核缓冲区拷贝到用户空间

内存映射，是将磁盘文件直接映射到用户的虚拟存储空间中，通过页表维护虚拟地址到磁盘的映射，通过内存映射的方式读取文件的好处有，因为减少了从内核缓冲区到用户空间的拷贝，直接从磁盘读取数据到内存，减少了系统调用的开销，对用户而言，仿佛直接操作的磁盘上的文件，另外由于使用了虚拟存储，所以不需要连续的主存空间来存储数据。

内存映射

当程序被加载进内存后，指令就在内存中了，这个时候说的内存是独立于 CPU 外的主存设备，也就是 PC 机中的内存条，指令指针寄存器IP 指向内存中下一条待执行指令的地址，控制单元根据 IP寄存器的指向，将主存中的指令装载到指令寄存器。

这个指令寄存器也是一个存储设备，不过他集成在 CPU 内部，指令从主存到达 CPU 后只是一串 010101 的二进制串，还需要通过译码器解码，分析出操作码是什么，操作数在哪，之后就是具体的运算单元进行算术运算（加减乘除），逻辑运算（比较，位移）。而 CPU 指令执行过程大致为：取址（去主存获取指令放到寄存器），译码（从主存获取操作数放入高速缓存 L1 ），执行（运算）。

程序运行

实时时钟 RTC ，用于长时间存放系统时间的设备，即使关机也可以依靠主板中的电池继续计时。Linux 启动的时候会从 RTC 中读取时间和日期作为初始值，之后在运行期间通过其他计时器去维护系统时间。

可编程间隔定时器 PIT ，该计数器会有一个初始值，每过一个时钟周期，该初始值会减1，当该初始值被减到0时，就通过导线向 CPU 发送一个时钟中断， CPU 就可以执行对应的中断程序，也就是回调对应的任务

时间戳计数器 TSC ，所有的 Intel8086 CPU 中都包含一个时间戳计数器对应的寄存器，该寄存器的值会在每次 CPU 收到一个时钟周期的中断信号后就会加 1 。他比 PIT 精度高，但是不能编程，只能读取。

硬件计时器在多长时间内产生时钟脉冲，而时钟周期频率为1秒内产生时钟脉冲的个数。目前通常为1193180。

时钟周期

当PIT中的初始值减到0的时候，就会产生一次时钟中断，这个初始值由编程的时候指定。

时钟滴答

时钟的实现

CPU

NVIDIA推出的运算平台

它包含了CUDA指令集架构（ISA）以及GPU内部的并行计算引擎

CUDA

GPU

计算机的CPU、RAM、ROM、定时计数器和多种I/O接口集成在一片芯片上，形成芯片级的芯片

MCU

组成原理

树莓派

硬件

数组

先序

中序

后序

public ArrayList<ArrayList<Integer>> levelOrder (TreeNode root) { ArrayList<ArrayList<Integer>> result = new ArrayList<ArrayList<Integer>>(); if(root != null){ Queue<TreeNode> queue = new LinkedList<>(); queue.offer(root); while(!queue.isEmpty()){ int size = queue.size(); ArrayList<Integer> newLevel = new ArrayList<Integer>(); for(int i=0; i<size; i++){ TreeNode temp = queue.poll(); newLevel.add(temp.val); if(temp.left != null) queue.offer(temp.left); if(temp.right != null) queue.offer(temp.right); } result.add(newLevel); } } return result; }

二叉树层序遍历

层序

遍历

翻转

二叉树

红黑树是一棵平衡二叉搜索树，其中序遍历单调不减

节点是红色或黑色。

根节点是黑色。

每个叶节点（也有称外部节点的，目的是将红黑树变为真二叉树，即NULL节点，空节点）是黑色的。

每个红色节点的两个子节点都是黑色。（换句话说，从每个叶子到根的所有路径上不能有两个连续的红色节点）

从根节点到每个叶子的所有路径都包含相同数目的黑色节点（这个数值叫做黑高度）。

红黑树

b树

B+树是在B树的基础上又一次的改进，其主要对两个方面进行了提升，一方面是查询的稳定性，另外一方面是在数据排序方面更友好。

非叶子节点不保存具体的数据，而只保存关键字的索引

b+树

利用顺序写来提高写性能，但因为分层(此处分层是指的分为内存和文件两部分)的设计会稍微降低读性能，但是通过牺牲小部分读性能换来高性能写，使得LSM树成为非常流行的存储结构。

LSM树(Log-Structured-Merge-Tree)正如它的名字一样，LSM树会将所有的数据插入、修改、删除等操作记录(注意是操作记录)保存在内存之中，当此类操作达到一定的数据量后，再批量地顺序写入到磁盘当中。

内存中的数据结构，用于保存最近更新的数据，会按照Key有序地组织这些数据，

MemTable

Immutable MemTable

有序键值对集合，是LSM树组在磁盘中的数据结构。为了加快SSTable的读取，可以通过建立key的索引以及布隆过滤器来加快key的查找。

SSTable(Sorted String Table)

LSM树

树

链表

添加 add会抛出异常

offer，add

删除对头元素

poll，remove

查询头部元素

peek，element

Queue

队列

栈

堆

邻接表无法快速判断两个节点是否相邻

邻接表

邻接矩阵

存储

图

数据结构

业务逻辑问题(死循环)

jstat -gc pid 1000命令来对 gc 分代变化情况进行观察

频繁 gc

cs(context switch)一列则代表了上下文切换的次数。

vmstat 1

使用vmstat命令

pidstat -w pid命令，cswch 和 nvcswch 表示自愿及非自愿切换。

对特定的 pid 进行监控

上下文切换过多

top -H -p pid

找到 CPU 使用率比较高的一些线程

printf '%x\'

然后将占用最高的 pid 转换为 16 进制

jstack pid |grep 'nid' -C5 –color

jstack 中找到相应的堆栈信息

关注 WAITING 、TIMED_WAITING、BLOCKED

方案

df -hl

查看文件系统状态

最后一列%util可以看到每块磁盘写入的程度，而rrqpm/s以及wrqm/s分别表示读写速度

iostatiostat -d -k -x

磁盘性能

拿到的是 tid，我们要转换成 pid，可以通过 readlink 来找到 pidreadlink -f /proc/*/task/tid/../..。

iotop

cat /proc/pid/io

定位文件读写的来源

lsof -p pid

具体的文件读写情况

磁盘

比如说每次请求都 new 对象，导致大量重复创建对象；进行文件流操作但未正确关闭；手动不当触发 gc；ByteBuffer 缓存分配不合理等都会造成代码 OOM。

线程池代码写的有问题，比如说忘记 shutdown

JVM 方面可以通过指定Xss来减少单个 thread stack 的大小

可以在系统层面，可以通过修改/etc/security/limits.confnofile 和 nproc 来增大 os 对线程的限制

没有足够的内存空间给线程分配 Java 栈

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

jstack+jmap

堆的内存占用已经达到-Xmx 设置的最大值

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

元数据区的内存占用已经达到XX:MaxMetaspaceSize设置的最大值

Caused by: java.lang.OutOfMemoryError: Meta space

-XX:+HeapDumpOnOutOfMemoryError来保存 OOM 时的 dump 文件。

OOM

表示线程栈需要的内存大于 Xss 值，

Exception in thread "main" java.lang.StackOverflowError

Stack Overflo

youngGC 或者 fullGC 次数是不是太多；EU、OU 等指标增长是不是异常。

使用 jstat 来查看分代变化情况

通过pstreee -p pid |wc -l。

/proc/pid/task

看下总体线程

GC 问题

往往是和 NIO

OutOfMemoryError: Direct buffer memory。

DirectByteBuffer

OutOfDirectMemoryError

查看对应 pid 倒序前 30 大的内存段

pmap -x pid | sort -rn -k3 | head -30

pmap 来查看下进程占用的内存

gdb --batch --pid {pid} -ex "dump memory filename.dump {内存起始地址} {内存起始地址+内存块大小}"

gdb

堆外内存

内存

网络

火焰图就是看顶层的哪个函数占据的宽度最大。只要有"平顶"（plateaus），就表示该函数可能存在性能问题。

火焰图

线上调优

grep 'core id' /proc/cpuinfo |wc -l 查看核心数

cpu过高

查看资源占用过高的线程

top -Hp

top 查看附载

系统查看

tar -zxvf 解压

：set nu 显示行号

vim

ln -s 软链接

检查当前VPS的数据硬盘情况

fdisk -l

挂载盘

mount /dev/vdb1 /mnt/data

scp -r test root@107.172.27.254:/home 上传目录

SSH

递归下载

自由软件 copyleft 许可证（GNU GPL）发布的

只提供简单的 HTTP POST 支持。

https --no-check-certificate

wget

自由软件许可证（MIT 衍生产品）

上传和发送功能

curl

远程登录

telnet

命令

所有的文件都是通过文件描述符引用

文件描述符

文件的打开

int close(int fd) 关闭一个文件会释放上面所有的记录锁。一个进程终止后，内核会自动关闭它打开的所有文件。

文件的关闭

文件定位

空洞文件

文件写入

文件读取

文件属性编辑

文件内核API

进程中的文件表，记录着进程打开的所有文件。每个文件用了一个fd标志和一个文件指针（指向2）表示。

内核为每个进程打开的每个文件创建了一个文件表，包含了文件状态标志、文件偏移量和i-node指针。需要注意不同进程打开了不同文件的时候，会有两个文件表。所以并发读取是安全的。

每个文件都对应一个i-node。这个node里包含了文件的磁盘块位置、文件的长度、拥有者、权限等。这些信息会被读入内存。

多线程读取

磁盘划分为数据区和i-node区，一般每4个块（一个块为4K，8个扇区）就会有一个i-node，占地256字节。每创建一个文件，系统就分配一个i-node给文件，并把文件名和i-node编号关联起来。查找的时候，根据文件名找到编号，再找到文件的磁盘位置。

每次write完毕，内核文件表2中的文件偏移量都会增加写入的字节数。如果此时文件的偏移量大于i-node记录的文件长度，i-node记录会被更新为这个偏移量（文件变长）。

O_APPEND会被写内核文件表2中的文件状态标志中。这样，每次write发现这个标志，都会先把文件偏移量设置为i-node的文件长度，这样就可以写到尾端。

文件系统

缓冲区缓存 Buffer Cache

页缓存 Page Cache

buffer和cache在Linux 2.4之前是两种缓存，也就是说同一份数据有两份内容在内核中。这两份数据的同步和维护其实带来了一些麻烦。在Linux 2.4之后，人们想到了统一这两种缓存，就把buffer指向了cache，使得数据只剩下一份实体。对于为什么是cache作为了主要的语义

buffer和cache区别

Linux2.4 内核做了优化，取而代之的是只包含关于数据的位置和长度的信息的描述符被追加到了socket buffer 缓冲区中。DMA引擎直接把数据从内核缓冲区传输到协议引擎（protocol engine）

零拷贝

保存了实际在网络中传输的数据；

报文数据

供内核处理报文的额外数据，这些数据构成了协议之间交换的控制信息

管理数据

socket buffer

虚拟内存的磁盘空间

swap分区

IO事件处理机制 select 到 Epoll 的进化过程

O(1)利用FD的回调

同时支持 block 和 non-block socket

如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。

LT(level triggered，水平触发模式)

只支持no-block socket

当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，，并且不会再为那个文件描述符发送更多的就绪通知

ET(edge-triggered，边缘触发模式)

两种模型

构建epoll对象

有连接接入时，会插入到epoll对象中，epoll对象里实际是一个红黑树+双向链表，fd插入到红黑树中，通过红黑树查找到是否重复

一旦fd就绪，会触发回调把fd的插入到就绪链表中，并唤醒等待队列中的线程

调用epoll_wait方法时只需要检查就绪链表，如有则返回给用户程序，如没有进入等待队列

路径

epoll把fd管理起来，不需要每次都重复传入，而且只返回就绪的fd，因此减少了用户空间和内核空间的相互拷贝，在fd数量庞大的时候更加高效。

epoll

poll使用链表保存文件描述符，因此没有了监视文件数量的限制

poll

单个进程能够监视的文件描述符的数量存在最大限制

select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差

select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件

select

IO事件处理机制

内核的I/O Cache

有如果有，就直接分配物理内存，并建立虚拟内存与物理内存之间的映射关系。

如果没有空闲的物理内存，那么内核就会开始进行回收内存的工作，如果回收内存工作结束后，空闲的物理内存仍然无法满足此次物理内存的申请，那么内核就会放最后的大招了触发 OOM （Out of Memory）机制。

是否有空闲的物理内存

触发缺页中断函数

如果虚拟地址对应的物理地址不在物理内存中，则产生缺页中断

只读段

全局变量、静态变量

数据段

动态内存

动态库

文件映射区

维护函数调用的上线文空间

页表

内核虚拟空间

有低地址到高地址

32 位操作系统，进程最多只能申请 3 GB 大小的虚拟内存空间

32 位系统的内核空间占用 1G，位于最高处，剩下的 3G 是用户空间；

64 位操作系统，进程可以使用 128 TB 大小的虚拟内存空间，所以进程申请 8GB 内存是没问题的，因为进程申请内存是申请虚拟内存，只要不读写这个虚拟内存，操作系统就不会分配物理内存。

64 位系统的内核空间和用户空间都是 128T，分别占据整个内存空间的最高和最低处，剩下的中间部分是未定义的。

虚拟地址空间

虚拟地址

每一个进程都有独立的虚拟地址空间，进程访问的不是真正的物理地址

虚拟内存

让执行线程不再在同一个共享变量上自旋，避免过高频率的缓存同步操作。

MCS在自己的结点的locked域上自旋等待

解决了CLH在NUMA系统架构中获取locked域状态内存过远的问题

MCS

CLH是在前趋结点的locked域上自旋等待

CLH

自旋转锁

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。

两个对象a、b，对应两个线程1、2。线程1先锁住a对象再锁住b对象，线程2先锁住b对象再锁a对象

案例

死鎖

锁

异步：内核空间发起IO

同步：用户空间发起IO

同步&异步

用户空间执行状态

阻塞&非阻塞

概念

阻塞式I/O

非阻塞式I/O

非阻塞是指I/O读写，对应的是recvfrom操作

同步，是因为，这个执行是在一个线程里面执行的

同步非阻塞

NIO只负责对发生在fd描述符上的事件进行通知。事件的获取和通知部分是非阻塞的

I/O复用(select/poll/epoll)

信号驱动式I/O

异步I/O

I/O模型

Linux上的线程模型为 NPTL （ Native POSIX Thread Library），他使用一对一模式，兼容 POSIX 标准，没有使用管理线程，可以更好地在多核 CPU 上运行。

新建（new Thread）

就绪（runnable）

运行（running）

(一)等待堵塞：执行的线程执行wait()方法，JVM会把该线程放入等待池中。

(二)同步堵塞：执行的线程在获取对象的同步锁时，若该同步锁被别的线程占用。则JVM会把该线程放入锁池中。

(三)其它堵塞：执行的线程执行sleep()或join()方法，或者发出了I/O请求时。JVM会把该线程置为堵塞状态。

堵塞（blocked）

死亡（dead）

线程的基本状态

线程

linux

点对点设计

ROS（robot operating system）机器人操作系统

操作系统

计算机网络模型

首先根据目的IP和路由表决定走哪个网卡，再根据网卡的子网掩码地址判断目的IP是否在子网内。如果不在则会通过arp缓存查询IP的网卡地址，不存在的话会通过广播询问目的IP的mac地址，得到后就开始发包了，同时mac地址也会被arp缓存起来。

输入 ping IP 后敲回车，发包前会发生什么？

Client requests connection by sending SYN (synchronize) message to the server.

客戶端收到旧的 SYN SEQ NUM 响应报文终止连接

在两次握手的情况下，「被动发起方」没有中间状态给「主动发起方」来阻止历史连接，导致「被动发起方」可能建立一个历史连接，造成资源浪费。

Server acknowledges by sending SYN-ACK (synchronize-acknowledge) message back to the client.

旧的数据包，先到达目标主机

首要原因是为了防止旧的重复连接初始化造成混乱。

同步双方初始序列号

原因

三次握手

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。

客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。

等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。

客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态

服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。

客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。

服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

四次挥手

攻击者使用假IP重复发送SYN包到目标服务端的每一个端口。服务端接受这些表面上合法的请求并与之建立链接，接着从自己的端口应答SNY-ACK报文给每一个请求。攻击者此时，要么不接受SNY-ACK（第3步），要么不发送ACK（第3步），此时服务端就会等待攻击者应答自己，但是明显是等不到的（但是还要等一个固定的时间段），那么这个socket就被占用了，网络资源也被浪费了。

Micro blocks --- “疏”，依旧接受SNY请求，但是变相扩大自己的容量。对于SNY请求，不在用大数据结构管理，而采用微型数据结构（16个字节）。

RST cookies --- “堵”+“骗”，服务端不再傻乎乎地走正常套路了，服务端在收到SNY后，会故意发一个错误的SNY-ACK给客户端，这个时候，如果使用正常tcp/ip协议的客户端会发现SNY-ACK内容不对，于是会回一个RST给服务端，告诉服务端“你发的东西不对头啊”。如果客户端收到了这个RST packet，那么可以说明对面那个客户端是合法的，接着进入正常流程。

解决

tcp洪流

数据库读写分离负载

跳板机端口映射

四层负载均衡是基于传输层协议包来封装的（如：TCP/IP）

TCP/IP协议

HTTP1.0

HTTP1.1

多路复用和首部压缩解决了head of line blocking

server pushing

HTTP2.0

简称 UA，它是一个特殊字符串头，使得服务器能够识别客户使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等

User-Agent

永久重定向

301

临时重定向

302

404

503

状态码

Type（消息类型）：数据类型定义的容器，它使用某种类型系统（如 XSD）。

Message（消息）：通信数据的抽象类型化定义，它由一个或者多个 part 组成。

WSDL定义了四种操作： 1.单向（one-way）：端点接受信息；2.请求-响应（request-response）：端点接受消息，然后发送相关消息；3.要求-响应（solicit-response）：端点发送消息，然后接受相关消息；4.通知（notification）：端点发送消息。

Operation（操作）：对服务所支持的操作进行抽象描述

Part：消息参数

Port Type（端口类型）：特定端口类型的具体协议和数据格式规范。

Port：定义为绑定和网络地址组合的单个端点。

Service：相关端口的集合，包括其关联的接口、操作、消息等。

描述Web服务发布的XML格式

WSDL（Web服务描述语言，Web Services Description Language）

XML

soap用来描述传递信息的格式

SOAP（简单对象访问协议）

管理，分发，查询webService

UDDI

WebService

报文

text/html ： HTML格式text/plain ：纯文本格式 text/xml ： XML格式image/gif ：gif图片格式 image/jpeg ：jpg图片格式 image/png：png图片格式以application开头的媒体格式类型：application/xhtml+xml ：XHTML格式application/xml ： XML数据格式application/atom+xml ：Atom XML聚合格式 application/json ： JSON数据格式application/pdf ：pdf格式 application/msword ： Word文档格式application/octet-stream ：二进制流数据（如常见的文件下载）application/x-www-form-urlencoded ： <form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）另外一种常见的媒体格式是上传文件之时使用的：multipart/form-data ：需要在表单中进行文件上传时，就需要使用该格式

Content-Type

则无法通过 JS 脚本读写该 cookie 的信息，但还是能通过 Application 中手动修改 cookie，所以只是在一定程度上可以防止 CSRF 攻击，不是绝对的安全

HttpOnly

键值对，设置 Cookie 的名称及相对应的值，都必须是字符串类型（name 不区分大小写）- 如果值为 Unicode 字符，需要为字符编码。- 如果值为二进制数据，则需要使用 BASE64 编码。

name=value

指定 cookie 所属域名，默认是当前域名

domain

Set-Cookie

Set-Cookie 响应头字段（Response header）是服务器发送到浏览器或者其他客户端的一些信息，一般用于登陆成功的情况下返回给客户端的凭证信息，然后下次请求时会带上这个 cookie，这样服务器端就能知道是来自哪个用户的请求了。

浏览器端某个 Cookie 的 domain（.a.com）字段等于请求的域名或者是请求的父域名，请求的域名需要是 a.com/b.a.com 才可以

都是 http 或者 https，或者不同的情况下 Secure 属性为 false（即 secure 是 true 的情况下，只有 https 请求才能携带这个 cookie）

要发送请求的路径，跟浏览器端 Cookie 的 path 属性必须一致，或者是浏览器端 Cookie 的 path 的子目录，比如浏览器端 Cookie 的 path 为 /test，那么请求的路径必须为/test 或者/test/xxxx 等子目录才可以

Cookie 请求头字段是客户端发送请求到服务器端时发送的信息（满足一定条件下浏览器自动完成，无需前端代码辅助）

HTTP

HTTPS

客户端两次请求

重定向

服务的行为

AVB（音频视频桥接技术）

时间同步

调度和流量整形

通信路径的选择、预留和容错

TSN（Time-Sensitive Networking）时间敏感网络

车载以太网

归纳演绎法

插入排序

选择排序

希尔排序

快速排序

归并排序

堆排序

排序算法

多叉树的延伸

广度优先

全排列

N皇后

问题

路径：也就是已经做出的选择。

选择列表：也就是你当前可以做的选择。

结束条件：也就是到达决策树底层，无法再做选择的条件。

解决一个回溯问题，实际上就是一个决策树的遍历过程

回溯算法

深度优先

弗洛伊德算法（多源最短路径）

迪杰斯特拉算法

Bellman-Ford算法(解决负权边）

图的最短路径

找到一个岛屿、用海水淹没他

岛屿问题

图算法

暴力算法BF算法

哈希值进行比较的RK算法

最长可匹配后缀子串

最长可匹配前缀子串

数组的下标代表了“已匹配前缀的下一个位置“

元素的值则是“最长可匹配前缀子串的下一个位置”

next数组

KMP

字符串匹配

动态规划的穷举有点特别，因为这类问题存在「重叠子问题」，如果暴力穷举的话效率会极其低下，所以需要「备忘录」或者「DP table」来优化穷举过程，避免不必要的计算

动态规划的核心问题是穷举

通项公式

递推公式

备忘录

DP table

状态转移方程

重叠子问题

最优子结构

三要素

斐波那契数列

凑零钱问题

最长递增子序列

最小编辑距离

01背包

背包9讲

动态规划

朴素的算法

解决分布式系统中负载均衡的问题，使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡的作用。

伸缩性很差

新增或者下线服务器机器时候，用户id与服务器的映射关系会大量失效

余数hash

各个服务器使用Hash进行一个哈希，具体可以选择服务器的ip或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置

数据key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器。

hash环

虚拟节点机制

数据倾斜

一致性hash

分布式算法

对称

加密算法

输入任意长度的信息，经过处理，输出为128位的信息（数字指纹）；

一个MD5理论上的确是可能对应无数多个原文的，因为MD5是有限多个的而原文可以是无数多个

3.4*10^38

MD5目前最有效的攻击方式就是彩虹表

不同的输入得到的不同的结果（唯一性）；

超损压缩

MD5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子分组，经过了一系列的处理后，算法的输出由四个32位分组组成，将这四个32位分组级联后将生成一个128位散列值。

MD5

把3个8 bit 的二进制数转换成4个6字节的二进制数，而这4个6字节数，都是可见打印字符

BASE64

编码

public ListNode ReverseList(ListNode head) { ListNode pre = null; ListNode cur = head; ListNode next = null; while(cur!=null) { next = cur.next; cur.next = pre; pre = cur; cur = next; } return pre; }

反转链表（单链表）

设计LRU缓存结构

最长无重复数组

public String solve (String str) { char[] ans = str.toCharArray(); int len = str.length(); for(int i = 0 ; i < len ;i++) { ans[i] = str.charAt(len-1-i); } return new String(ans); }

翻转字符串

public boolean hasCycle(ListNode head) { if (head == null) return false; //快慢两个指针 ListNode slow = head; ListNode fast = head; while (fast != null && fast.next != null) { slow = slow.next; fast = fast.next.next; if (slow == fast) return true; } return false; }

判断链表是否有环

环形链表

合并两个有序链表

删除链表的倒数第N节点

相交链表

链表的中间节点

双指针

技巧

算法

template

style

该属性规定了元素是否可进行拖动

draggable

div

html

向外暴露成员

export default

export

返回值一定是一个Promise

async异步函数可以捕获错误处理，不会终止后续代码执行

使用then方法添加回调函数

async异步函数

普通函数

const 用来定义常量，使用时必须初始化(即必须赋值)，只能在块作用域里访问，而且不能修改

const

let出的变量作用域是块作用域

let

var

关键字

vetur

插件

v-bind绑定一个value属性

子主题 2

原理

v-model

slot-scope=“scope“语义更加明确，相当于一行的数据

slot（插槽）

model

ref

inline

label-width

el-input

el-form-item

el-autocomplete（输入建议输入框）

el-form

default-active

<el-menu>

<el-submenu>（一级菜单）

激活的路由

index

<el-menu-item>（二级菜单）

该row内元素之间的间隙，也就是col占6，gutter占6中的20px

gutter

每个元素所占此row比例，一行是24

span

el-输入框

输入建议

el-autocomplete

el-drawer

即修改

el-switch

Element UI组件

渲染的组件是你使用vue-router指定

router-view

created

mounted

钩子

vue

在JavaScript的基础上添加静态类型定义构建而成

TypeScript通过TypeScript编译器或Babel转译为JavaScript代码

TypeScript

执行自身工厂的preinstall

指的是dependencies和devDependencies中配置的模块

确定首层依赖模块

获取模块

模块扁平化

更新工程中的node_modules

安装模块

npm install

npm

环境工具

同源是指"协议+域名+端口"三者相同

浏览器在执行脚本前，会判断脚本是否与打开的网页是同源的，不相同就表示跨域访问。会在控制台报一个CORS异常，目的是为了保护本地数据不被JavaScript代码获取回来的数据污染，因此拦截的是客户端发出的请求回来的数据接收，即请求发送了，服务器响应了，但是无法被浏览器接收。

跨域并不是请求发不出去，请求能发出去，服务端能收到请求并正常返回结果，只是结果被浏览器拦截了。

1.后台放开限制优点：谁都能请求，方便缺点：不安全

2.JSONP JSONP实现原理

3.配置代理

跨域

DOM 同源策略

XMLHttpRequest 同源策略

Cookie、LocalStorage、IndexedDB 等存储性内容同源策略

同源策略

浏览器

前端

泛型作用只在编译期

泛型的擦除保证了有泛型和没有泛型产生的代码（class文件）是一致的。

泛型类

泛型接口

泛型方法

使用

泛型

native

如果引用为基本数据类型，则该引用为常量，该值无法修改

如果引用为引用数据类型，比如对象、数组，则该对象、数组本身可以修改，但指向该对象或数组的地址的引用不能修改

如果引用时类的成员变量，则必须当场赋值，否则编译会报错

修饰一个引用

final修饰方法时，这个方法将成为最终方法，无法被子类重写。但是，该方法仍然可以被继承。

修饰一个方法

该类成为最终类，无法被继承

修饰类

final

== 比较的是变量(栈)内存中存放的对象的(堆)内存地址，用来判断两个对象的地址是否相同，即是否是指相同一个对象。比较的是真正意义上的指针操作。

==是判断两个变量或实例是不是指向同一个内存空间，equals是判断两个变量或实例所指向的内存空间的值是不是相同

==指引用是否相同， equals()指的是值是否相同

==是指对内存地址进行比较， equals()是对字符串的内容进行比较

类没有覆盖 equals() 方法。则通过 equals() 比较该类的两个对象时，等价于通过“==”比较这两个对象。

equals和==

次方

4 >> 1，结果是2；-4 >> 1，结果是-2。-2 >> 1，结果是-1。

>>：带符号右移。正数右移高位补0，负数右移高位补1

>>>：无符号右移。无论是正数还是负数，高位通通补0。

>> and >>>

位移操作

~(按位非)

| (按位或)

&(按位与)

^ (按位异或）

位运算

强引用

SoftReference 的原理是：在保持对对象的引用时保证在 JVM 报告内存不足情况之前将清除所有的软引用

软引用（SoftReference ）

弱引用（WeakReference ）

PhantomReference 类只能用于跟踪对被引用对象即将进行的收集。

虚引用（PhantomReference ）

引用

应为抽象类中有抽象方法，抽象方法没有方法体，抽象类不是完整的类，因此不能实例化。

不能实例化的类

抽象类

接口是对行为的抽象，它是抽象方法的集合，利用接口可以达到 API 定义和实现分离的目的。

不能包含任何非常量成员

单继承和多继承

\t接口中只能有抽象方法和常量，在JDK8.0之后可以有Static和default方法

实例成员、类成员、抽象方法

extends和implements

接口中只能定义常量（使用public static final修饰）

抽象类中既可以定义常量也可以定义变量

\t抽象类中可以有构造方法

区别

接口

accept(T t)

Consumer

get()

Supplier

Function.apply

Function

test(T t)

Predicate

函数编程

无法删除和无法修改数据

foreach

循环

语法

常量池

String str="i"

堆内存

String str=new String(“i”)

length()

getByte()

toCharArray()

split(String)

equals()

equalsIsIgnoreCase(String)

contains(String)

startsWith(String)

endsWith(String)

取常量池

intern()

方法

String

数据类型

哈希码

GC 信息

持有的锁信息

64 位

数组对象包含数组长度

标记字段

指向该对象的类 Class

类型指针

对象头（object header）

对象

classloader

class是已经初始化完成的

Class.forName

运行时获取实例

通过属性相对对象起始地址的偏移量，来读取和写入属性的值

通过 UnSafe 类

反射

synchronized(lockObject){}

public synchornized void test()

作用

对象头

32/64bit\tClass Metadata Address\t指向对象类型数据的指针

实例数据

填充数据

对象的结构

锁标志位 01

无锁

当有一个线程访问同步块

锁膨胀（无锁-偏向锁）

当线程执行到临界区（critical section）时

该锁没有被其他线程所获取，没有其他线程来竞争该锁，那么持有偏向锁的线程将永远不需要进行同步操作。

锁标志位01

偏向锁

有锁竞争

线程在自己的栈桢中创建锁记录 LockRecord。

将锁对象的对象头中的MarkWord复制到线程的刚刚创建的锁记录中。

锁记录中的Owner指针指向锁对象。

将锁对象的对象头的MarkWord替换为指向锁记录的指针。

锁膨胀（偏向锁-轻量级锁）

自旋锁

自适应自旋锁

指向LockRecord的指针锁标志位 00

轻量级锁也被称为非阻塞同步、乐观锁，因为这个过程并没有把线程阻塞挂起，而是让线程空循环等待，串行执行。

轻量级锁（自旋锁）

自旋转十次失败

锁膨胀（轻量级锁-重量级锁）

指向Mutex的指针\t10

monitor锁来实现的，而monitor又依赖操作系统的MutexLock(互斥锁)来实现的，所以重量级锁也被成为互斥锁。

当系统检查到锁是重量级锁之后，会把等待想要获得锁的线程进行阻塞，被阻塞的线程不会消耗cup。但是阻塞或者唤醒一个线程时，都需要操作系统来帮忙，这就需要从用户态转换到内核态，而转换状态是需要消耗很多时间的，有可能比用户执行代码的时间还要长。

锁标志位11

重量级锁

锁的升级

对于Entry Set：如果线程A已经持有了对象锁，此时如果有其他线程也想获得该对象锁的话，它只能进入Entry Set，并且处于线程的BLOCKED状态。

对于Entry Set中的线程，当对象锁被释放的时候，JVM会唤醒处于Entry Set中的某一个线程，这个线程的状态就从BLOCKED转变为RUNNABLE。

锁池

Entry Set

对于Wait Set：如果线程A调用了wait()方法，那么线程A会释放该对象的锁，进入到Wait Set，并且处于线程的WAITING状态。

对于Wait Set中的线程，当对象的notify()方法被调用时，JVM会唤醒处于Wait Set中的某一个线程，这个线程的状态就从WAITING转变为RUNNABLE；或者当notifyAll()方法被调用时，Wait Set中的全部线程会转变为RUNNABLE状态。所有Wait Set中被唤醒的线程会被转移到Entry Set中。

等待池

Wait Set

底层支持

synchronized

JDBC

JCE

JNDI

JAXP

JBI

SPI 的本质是将接口的实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载对应接口的实现类。这样就可以在运行时，获取接口的实现类。

Java SPI 是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。

SPI （ Service Provider Interface），是一种服务发现机制。

SPI

基础

数组链表红黑树

扩容容量因子

调用对象的hashcode（）方法获取hashcode 寻找 bucket位置来存储Entry对象

A线程覆盖B线程PUT 同一个桶覆盖

新增一个节点在链表末尾覆盖

put

table 已经指向newtable

无法删除元素

正好执行到 table = newTab

resize扩容

多个线程都发现hashmap需要扩容的时候，同时调整hashmap的大小。调整时会出现尾部遍历，导致死锁。

resize copy链表指针错误引起死锁

1.7JDK

线程不安全

1 << 4

DEFAULT_INITIAL_CAPACITY 初始容量

1<<30

MAXIMUM_CAPACITY最大容量

0.75f

DEFAULT_LOAD_FACTOR 加载因子

使用树形阈值

TREEIFY_THRESHOLD

高16位跟低16位进行异或运算，这样目的是使结果更加随机性，尽可能使数据均匀分布

hash算法

懒加载

在第一次put的时候进行初始化 table

根据hash跟（新数组的容量-1）异或计算节点在新数组的位置

resize（）

hashmap

1.判断elementData数组容量是否满足需求

2.在elementData对应位置上设置值

add

数组越界

覆盖一个为空

elementData[size++] = e不是原子操作

扩容

arrayList

treemap

NavigableMap（接口）

SortedMap

用数组实现的有界阻塞队列，FIFO先进先出，支持公平所和非公平锁

ArrayBlockQueue

链表结构阻塞队列，FIFO，默认长度为Intger.MAX_VALUE，默认有容量风险

LinkedBlockingQueue

支持线程优先级排序的队列，可自定义ComparaTo()方法来指定元素排序，不保证同优先级顺序

PriorityBlockQueue

实现PriorityBlockQueue的无界队列，创建元素时，可以指定多久从才能从队列中获取当前元素。

DalayQueue

不存储元素的队列，一个put元素必须等待一个take操作

SynchronousQueue

LinkedTransferQueue

双向阻塞队列，多线程并发时，降低锁的竞争

LinkedBlockDeque

BlockQueue

queue

集合类

URL

URLConnection

HttpURLConnection

java.net

SecurityManager

getSecurityManager

System

获取运行时类

getClass

toString()

如果两个对象equals相等，那么这两个对象的HashCode一定也相同

如果两个对象的HashCode相同，不代表两个对象就相同，只能说明这两个对象在散列存储结构中，存放于同一个位置

equals方法重写的话，建议也一起重写hashcode方法

String 类型 Aa 和 BB hascode相同 2112

Park-Miller RNG的随机数生成策略

内存地址

自增变量

状态值进行异或（XOR）运算得到的一个 hash 值

5（默认）

hashCode

对象复制

clone

notify

之所以我们应该尽量使用notifyAll()的原因就是，notify()非常容易导致死锁

notifyAll

释放占有的锁

超时和非超时

需要另一个线程使用Object.notify()唤醒

被唤醒不一定立即执行原代码

有中断异常

需要在synchronized中执行

wait

当垃圾回收器将要回收对象所占内存之前被调用

此方法有很大的不确定性（不保证方法中的任务执行完）而且运行代价较高。

finalize

Object

表示此方法已废弃、暂时可用

@Deprecated

compareTo方法对比

Comparable

不会释放占有的锁

超时版本

自己醒来

一定会继续执行后续代码

sleep

Thread

函数调用栈太深了

StackOverflowError

OutOfMemoryError

VirtualMachineError

Error

Exception

Throwable

RetentionPolicy.SOURCE：注解只保留在源文件，当Java文件编译成class文件的时候，注解被遗弃；

RetentionPolicy.CLASS：注解被保留到class文件，但jvm加载class文件时候被遗弃，这是默认的生命周期；

RetentionPolicy.RUNTIME：注解不仅被保存到class文件中，jvm加载class文件之后，仍然存在；

RetentionPolicy

@Target(ElementType.TYPE) //接口、类、枚举、注解@Target(ElementType.FIELD) //字段、枚举的常量@Target(ElementType.METHOD) //方法@Target(ElementType.PARAMETER) //方法参数@Target(ElementType.CONSTRUCTOR) //构造函数@Target(ElementType.LOCAL_VARIABLE)//局部变量@Target(ElementType.ANNOTATION_TYPE)//注解@Target(ElementType.PACKAGE) ///包

Target

annotation

静态初始化块中出现异常的时候

ExceptionInInitializerError

日志输出方法

java.lang

Date

AQS是一个同步器，设计模式是模板模式。

双向链表 + state(锁状态)

CAS

AQS（AbstractQueuedSynchronizer）

atomic

同步队列

LockSupport.park()

条件队列

AbstractQueuedSynchronizer

避免了使线程进入内核态的阻塞状态

ReentrantLock

ReentrantReadWriteLock

StampedLock

任意处执行

一定继续执行源代码

park

LockSupport

释放锁资源

不一定继续执行原代码

在lock.lock()和lock.unlock之间

await

signal()

Condition

Locks

TimeUnit

这个类使一个线程等待其他线程各自执行完毕后再执行

CountDownLatch

它的作用就是会让所有线程都等待完成后才会继续下一步行动。

循环栅栏

CyclicBarrier

Semaphore

转移时使用数组

nextTable

正在转移

MOVED

返回节点数组的指定位置的节点的原子操作

tabAt

cas原子操作，在指定位置设定值

casTabAt

原子操作，在指定位置设定值

setTabAt

　·在ConcurrentHashMap中，同步处理主要是通过Synchronized和unsafe两种方式来完成的。　·在取得sizeCtl、某个位置的Node的时候，使用的都是unsafe的方法，来达到并发安全的目的　·当需要在某个位置设置节点的时候，则会通过Synchronized的同步机制来锁定该位置的节点。　·在数组扩容的时候，则通过处理的步长和fwd节点来达到并发安全的目的，通过设置hash值为MOVED　·当把某个位置的节点复制到扩张后的table的时候，也通过Synchronized的同步机制来保证现程安全

ConcurrentHashMap

有界队列

ArrayBlockingQueue

双向链表的队列

LinkedBlockingDeque

支持延时获取元素的无界阻塞队列

PriorityQueue

DelayQueue

支持优先级的无界阻塞队列

PriorityBlockingQueue

阻塞队列

线程执行结果

outcome

callable

implements RunnableFuture

FutureTask

DelayedFutureTask

DelayedWorkQueue

ScheduledThreadPoolExecutor

避免了处理任务时创建销毁线程开销的代价

避免了线程数量膨胀导致的过分调度问题，保证了对内核的充分利用。

池化思想管理线程

将任务提交和任务执行进行解耦

Executor

ExecutorService

扩充执行任务的能力，补充可以为一个或一批异步任务生成 Future 的方法

提供了管控线程池的方法，比如停止线程池的运行

abstractExecutorService

线程池在内部实际上构建了一个生产者消费者模型，将线程和任务两者解耦，并不直接关联，从而良好的缓冲任务，复用线程。

用一个变量去存储两个值，可避免在做相关决策时，出现不一致的情况，不必为了维护两者的一致，而占用锁资源。

ctl共包括32位。其中，高3位表示"线程池状态"，低29位表示"线程池中的任务数量"。

运行状态 (runState) 和线程数量 (work\u0002erCount)

(01) 状态说明：线程池处在RUNNING状态时，能够接收新任务，以及对已添加的任务进行处理。

(02) 状态切换：线程池的初始化状态是RUNNING。换句话说，线程池被一旦被创建，就处于RUNNING状态！

高3位值是111

RUNNING

(01) 状态说明：线程池处在SHUTDOWN状态时，不接收新任务，但能处理已添加的任务。

(02) 状态切换：调用线程池的shutdown()接口时，线程池由RUNNING -> SHUTDOWN

对应的高3位值是000

SHUTDOWN

(01) 状态说明：线程池处在STOP状态时，不接收新任务，不处理已添加的任务，并且会中断正在处理的任务。

(02) 状态切换：调用线程池的shutdownNow()接口时，线程池由(RUNNING or SHUTDOWN ) -> STOP。

高3位值是001

STOP

(01) 状态说明：当所有的任务已终止，ctl记录的"任务数量"为0，线程池会变为TIDYING状态。当线程池变为TIDYING状态时，会执行钩子函数terminated()。terminated()在ThreadPoolExecutor类中是空的，若用户想在线程池变为TIDYING时，进行相应的处理；可以通过重载terminated()函数来实现。

(02) 状态切换：当线程池在SHUTDOWN状态下，阻塞队列为空并且线程池中执行的任务也为空时，就会由 SHUTDOWN -> TIDYING。

高3位值是010

TIDYING

高3位值是011

(01) 状态说明：线程池彻底终止，就变成TERMINATED状态。

(02) 状态切换：线程池处在TIDYING状态时，执行完terminated()之后，就会由 TIDYING -> TERMINATED。

TERMINATED

状态

生命周期管理

shutdown()

RejectedExecutionException

当任务添加到线程池中被拒绝时，它将抛出 RejectedExecutionException 异常

AbortPolicy

当任务添加到线程池中被拒绝时，会在线程池当前正在运行的Thread线程池中处理被拒绝的任务。

CallerRunsPolicy

当任务添加到线程池中被拒绝时，线程池会放弃等待队列中最旧的未处理任务，然后将被拒绝的任务添加到等待队列中。

DiscardOldestPolicy

当任务添加到线程池中被拒绝时，线程池将丢弃被拒绝的任务

DiscardPolicy

拒绝策略

（1）并行执行子任务，提高响应速度。这种情况下，应该使用同步队列，没有什么任务应该被缓存下来，而是应该立即执行

（2）并行执行大批次任务，提升吞吐量。这种情况下，应该使用有界队列，使用队列去缓冲大批量的任务，队列容量必须声明，防止任务无限制堆积。

extends AbstractQueuedSynchronizer implements Runnable

Worker

丢弃策略

DiscardPolicy

DiscardOldestPolicy

不是立刻就被关闭，因为这时线程池中可能还有任务正在执行，或是任务队列中有正在等待的任务，它会等待正在执行的任务和队列中等待的任务执行完毕后才彻底关闭。注意：调用 shutdown() 方法后如果还有新的任务被提交，线程池则会根据拒绝策略直接拒绝提交的任务。

shutdown

shutdownNow() 表示立刻关闭的意思。在执行 shutdownNow 方法之后，首先会给所有线程池中的线程发送 interrupt 中断信号尝试中断这些任务的执行，然后将任务队列中的任务转移到一个 List 中并返回注意：即便我们调用了 shutdownNow 方法，如果被中断的线程对于中断信号不理不睬，那么依然有可能导致任务不会停止。所以我们自己编写的线程应当具有响应中断信号的能力。

shutdownNow

isTerminated()方法可以检测线程池是否真正“终结”了，这不仅代表线程池已关闭，同时代表线程池中的所有任务都已经都执行完毕了。

isTerminated()

关闭线程池

ThreadPoolExecutor

线程池

concurrent

Iterator

过滤流中的某些元素

filter

接收一个函数作为参数，该函数会被应用到每个元素上，并将其映射成一个新的元素

map

接收一个函数作为参数，将流中的每个值都换成另一个流，然后把所有流连接成一个流。

flatMap

如同于 map，能得到流中的每一个元素。但 map 接收的是一个 Function 表达式，有返回值；而 peek 接收的是 Consumer 表达式，没有返回值。

peek

指元素的处理不受之前元素的影响

无状态

通过流中元素的 hashCode() 和 equals() 去除重复元素

distinct

获取 n 个元素

limit

跳过 n 元素，配合 limit(n) 可实现分页

skip

自然排序，流中元素需实现 Comparable 接口

sorted

定制排序，自定义 Comparator 排序器

sorted(Comparator com)

指该操作只有拿到所有元素之后才能继续下去

有状态

中间操作

接收一个 Collector 实例，将流中元素收集成另外一个数据结构。

collect

规约操作

reduce

返回流中元素最大值

max

返回流中元素最小值

min

返回流中元素的总个数

count

指必须处理所有元素才能得到最终结果

非短路操作

接收一个 Predicate 函数，只要流中有一个元素满足该断言则返回 true，否则返回 false

anyMatch

接收一个 Predicate 函数，当流中每个元素都不符合该断言时才返回 true，否则返回 false

noneMatch

接收一个 Predicate 函数，当流中每个元素都符合该断言时才返回 true，否则返回 false

allMatch

返回流中第一个元素

findFirst

返回流中的任意元素

findAny

指遇到某些符合条件的元素就可以得到最终结果

短路操作

结果操作

使用 Arrays 中的 stream() 方法，将数组转成流：

常用创建方法

Stream

线程集合和阻塞队列

双精度快速排序+插入排序

sort源码

BitSet

java.util

Contended

jdk.internal

被@PostConstruct修饰的方法会在服务器加载Servlet的时候运行，并且只会被服务器调用一次，类似于Servlet的inti()方法。被@PostConstruct修饰的方法会在构造函数之后，init()方法之前运行。

PostConstruct

@PreConstruct修饰的方法会在服务器卸载Servlet的时候运行，并且只会被服务器调用一次，类似于Servlet的destroy()方法。被@PreConstruct修饰的方法会在destroy()方法之后运行，在Servlet被彻底卸载之前

PreConstruct

javax.annotation

PreparedStatement

Statement

java.sql

unpark

挂起

Unsafe

sun.misc

FileChannel，从文件中读写数据。

DatagramChannel，通过UDP读写网络中的数据。

SocketChannel，通过TCP读写网络中的数据。

ServerSocketChannel，可以监听新进来的TCP连接，对每一个新进来的连接都会创建一个SocketChannel

Channel通道类似流

数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性

Buffer用于和NIO通道进行交互。数据从通道读入到缓冲区，从缓冲区写入到通道中

Selector(选择区)用于监听多个通道的事件

reactor

Selector

NIO（new IO）

ByteArrayInputStream

inputStream

对byte类型数据进行写入的类相当于一个中间缓冲层，将类写入到文件等其他outputStream。它是对字节进行操作，属于内存操作流

ByteArrayOutputStream

outputStream

字节流

InputStreamReader类是从字节流到字符流的桥接器：它使用指定的字符集读取字节并将它们解码为字符

每次调用一个InputStreamReader的read（）方法都可能导致从底层字节输入流中读取一个或多个字节。为了实现字节到字符的有效转换，可以从基础流中提取比满足当前读取操作所需的更多字节。为了获得最高效率，请考虑在BufferedReader中包装InputStreamReader

InputStreamReader

Reader

Writer

字符流

Old IO

NIO处理数据是以数据块为单位，而传统IO流是以字节为单位

NIO 非阻塞

NIO 选择器

源码

Java内存模型规定了所有的变量都存储在主内存（Main Memory）中（此处的主内存与介绍物理硬件时的主内存名字一样，两者也可以互相类比，但此处仅是虚拟机内存的一部分）。

主内存

每条线程还有自己的工作内存（Working Memory，可与前面讲的处理器高速缓存类比），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成

工作内存

•lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。

•unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

•read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。

•load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。

•use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。

•assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。

•store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。

•write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中。

内存间的交互

java内存模型

程序计数器是一块很小的内存空间，用于记录下一条要运行的指令。每个线程都需要一个程序计数器，各个线程之中的计数器相互独立，是线程中私有的内存空间

•程序计数器(PC)

java虚拟机栈也是线程私有的内存空间，它和java线程同一时间创建，保存了局部变量、部分结果，并参与方法的调用和返回

•java虚拟机栈

本地方法栈和java虚拟机栈的功能相似，java虚拟机栈用于管理Java函数的调用，而本地方法栈用于管理本地方法的调用，但不是由Java实现的，而是由C实现的

•本地方法栈

•java堆

也被称为永久区，与堆空间相似，被JVM中所有的线程共享。方法区主要保存的信息是类的元数据，方法区中最为重要的是类的类型信息、常量池、域信息、方法信息，其中运行时常量池就在方法区，对永久区的GC回收，一是GC对永久区常量池的回收;二是永久区对元数据的回收

•方法区

VM stack

native stack

program counter stack

stack

eden

Young

tenured

Humongous

old

symbolc Relerence

Literal

runtime constant pool

heap

compile code

comprssed class space

feild&Method data

meta

JNI Memory

Direct Memory

stack Memory

JIT Compile

JIT code

code cache

non-heap

内存结构

内存模型JMM

当应用程序请求分配内存时，GC 负责提供内存。提供内存的过程应尽可能快

GC 检测应用程序不再使用的内存。这个操作也应当十分高效，不应消耗太多时间。这种不再使用的内存称为“垃圾”；

GC 将同一块内存再次提供给应用程序，最好是“实时”，也就是要快。

基本功能

JDK 8 以及更早版本的默认回收期

版本

吞吐量

专注

多线程的stop-the-world压缩和分代回收

Parallel GC 是 JDK 8 以及更早版本的默认回收期。它专注于吞吐量，尽快完成工作，而很少考虑延迟（暂停）。

Parallel GC 会在 STW（全局暂停）期间，以更紧凑的方式，将正在使用中的内存移动（复制）到堆中的其他位置，从而制造出大片的空闲内存区域。当内存分配请求无法满足时就会发生 STW 暂停，然后JVM完全停止应用程序运行，投入尽可能多的处理器线程，让垃圾回收算法执行内存压缩工作，然后分配请求的内存，最后恢复应用程序执行。

解释

Parallel GC

ParNew收集器是Serial收集器的多线程版本

ParNew

Concurrent Mark Sweep 并发、使用标记-清除算法的gc。

CMS以获取最小停顿时间为目的。在一些对响应时间有很高要求的应用或网站中，用户程序不能有长时间的停顿，CMS 可以用于此场景。

进行可达性分析，标记GC ROOT能直接关联到的对象。注意是直接关联间接关联的对象在下一阶段标记。

1 初始标记(STW)

该阶段进行GC ROOT TRACING，在第一个阶段被暂停的线程重新开始运行。由前阶段标记过的对象出发，所有可到达的对象都在本阶段中标记。

2 并发标记

CMS是以获取最短停顿时间为目的的GC。重标记需要STW（Stop The World），因此重标记的工作尽可能多的在并发阶段完成来减少STW的时间。此阶段标记从新生代晋升的对象、新分配到老年代的对象以及在并发阶段被修改了的对象。

3 并发预清理

4 重标记(STW)

并发清理。用户线程被重新激活，同时清理那些无效的对象。

5 并发清理

CMS清除内部状态，为下次回收做准备。

6 重置

步骤

CMS + ParNew

1.CMS只能回收老年代

2.CMS在old gc的时候会回收整个Old区

CMS

JDK6~ 9

平衡

多线程的stop-the-world压缩、并发活跃分代回收

G1 的长时间操作会与应用程序并行进行，即通过多线程方式，在应用程序运行时执行。这样可以大幅度减少暂停，代价是整体的吞吐量会降低一点。

G1收集器的总体效果是好于CMS的，有更好的自我调节能力而G1从JDK9开始才是默认垃圾回收器。所以JDK8的情况下，最好主动设置G1垃圾回收器：-XX:+UseG1GC

1.G1同时回收老年代和年轻代

-XX:MaxGCPauseMillis

-XX:InitiatingHeapOccupancyPercent

-XX:ParallelGCThreads

XX:G1ReservePercent

2.G1的分代更多是逻辑上的概念，G1将内存分成多个等大小的region，Eden/ Survivor/Old分别是一部分region的逻辑集合，物理上内存地址并不连续。

JDK 15

延迟

ZGC：JDK11 中推出的一款低延迟垃圾回收器，适用于大内存低延迟服务的内存管理和回收，SPECjbb 2015 基准测试，在 128G 的大堆下，最大停顿时间才 1.68 ms，停顿时间远胜于 G1 和 CMS。

多重映射

子主题 1

染色指针

读屏障

ZGC

JDK 12

Shenandoah GC

垃圾回收器

年轻代引用老年代的这种跨代不需要单独处理。但是老年代引用年轻代的会影响young gc

这种跨代需要处理。为了避免在回收年轻代的时候扫描整个老年代，需要记录老年代对年轻代的引用，young gc的时候只要扫描这个记录。CMS和G1都用到了Card Table

跨代引用

并发过程的对象变化

Promotion Failure和Concurrent Mode Failure年轻代晋升的时候老年代没有足够的连续空间容纳，很有可能是内存碎片导致的；后者是在并发过程中jvm觉得在并发过程结束前堆就会满了，需要提前触发Full GC

CMS Full GC

1. Evacuation的时候没有足够的to-space来存放晋升的对象；2. 并发处理过程完成之前空间耗尽。这两个原因跟CMS类似。

G1 Full GC

Full GC

Thread Local Allocation Buffer 的简写，基于 CAS 的独享线程（Mutator Threads）可以优先将对象分配在 Eden 中的一块内存，因为是Java 线程独享的内存区没有锁竞争，所以分配速度更快，每个 TLAB 都是一个线程独享的

TLAB

中文翻译为卡表，主要是用来标记卡页的状态，每个卡表项对应一个卡页。当卡页中一个对象引用有写操作时，写屏障将会标记对象所在的卡表状态改为 dirty，卡表的本质是用来解决跨代引用的问题。

Card Table

1.将转移到老年代的对象数量降低到最小；

2.减少full GC的执行时间；

目的

减少使用全局变量和大对象；

调整新生代的大小到最合适；

设置老年代的大小为最合适；

选择合适的GC收集器

措施

Minor GC执行时间不到50ms；Minor GC执行不频繁（约10s一次）；Full GC执行时间不到1s；Full GC执行不算频繁（不低于10m一次）

指标

性能调优

Bootstrap ClassLoader

Extention ClassLoader

Appclass Loader

编写一个类继承自ClassLoader抽象类。

复写它的findClass()方法。

在findClass()方法中调用defineClass()。

子主题 4

自定义ClassLoader

ClassLoader

装载：（loading）找到class对应的字节码文件。

连接：（linking）将对应的字节码文件读入到JVM中。

初始化：（initializing）对class做相应的初始化动作

类加载步骤

空闲链表（free list）：通过额外的存储记录空闲的地址，将随机 IO 变为顺序IO，但带来了额外的空间消耗。

碰撞指针（bump pointer）：通过一个指针作为分界点，需要分配内存时，仅需把指针往空闲的一端移动与对象大小相等的距离，分配效率较高，但使用场景有限

Java 中对象地址操作主要使用 Unsafe 调用了 C 的 allocate 和 free 两个方法

分配对象

零地址指令，它们依赖操作数栈进行工作

Java 字节码的操作指令（OpCode）被固定为一个字节

Java 代码必须通过 Java 编译器将其转换成虚拟机所能识别的指令序列，也称为 Java 字节码

字节码

解释器是软件来实现的，主要是为了实现同一份 Java 字节码可以在不同的硬件平台上运行

将汇编指令转换成机器指令由硬件直接实现，这一步速度是很快的，当然 JVM 为了提高运行效率也可以将某些热点代码（一个方法内的代码）一次全部编译成机器指令后然后在执行，也就是和解释执行对应的即时编译（JIT）， JVM 启动的时候可以通过 -Xint 和 -Xcomp 来控制执行模式。

JVM 通过类加载器加载 class 文件里的字节码后，会通过解释器解释成汇编指令，最终再转译成 CPU 可以识别的机器指令

编译

引用计数法（Reference Counting）：对每个对象的引用进行计数，每当有一个地方引用它时计数器 +1、引用失效则 -1，引用的计数放到对象头中，大于 0 的对象被认为是存活对象。虽然循环引用的问题可通过 Recycler 算法解决，但是在多线程环境下，引用计数变更也要进行昂贵的同步操作，性能较低，早期的编程语言会采用此算法

引用计数法

可达性分析，又称引用链法（Tracing GC）：从 GC Root 开始进行对象搜索，可以被搜索到的对象即为可达对象，此时还不足以判断对象是否存活 / 死亡，需要经过多次标记才能更加准确地确定，整个连通图之外的对象便可以作为垃圾被回收掉。目前 Java 中主流的虚拟机均采用此算法。

可达性分析

识别垃圾

Mark-Sweep（标记 - 清除）：回收过程主要分为两个阶段，第一阶段为追踪（Tracing）阶段，即从 GC Root 开始遍历对象图，并标记（Mark）所遇到的每个对象，第二阶段为清除（Sweep）阶段，即回收器检查堆中每一个对象，并将所有未被标记的对象进行回收，整个过程不会发生对象移动。整个算法在不同的实现中会使用三色抽象（Tricolour Abstraction）、位图标记（BitMap）等技术来提高算法的效率，存活对象较多时较高效

Mark-Sweep（标记 - 清除）

Mark-Compact（标记 - 整理）：这个算法的主要目的就是解决在非移动式回收器中都会存在的碎片化问题，也分为两个阶段，第一阶段与 Mark-Sweep类似，第二阶段则会对存活对象按照整理顺序（Compaction Order）进行整理。主要实现有双指针（Two-Finger）回收算法、滑动回收（Lisp2）算法和引线整理（Threaded Compaction）算法等

Mark-Compact（标记 - 整理）

Copying（复制）：将空间分为两个大小相同的 From 和 To 两个半区，同一时间只会使用其中一个，每次进行回收时将一个半区的存活对象通过复制的方式转移到另一个半区。有递归（Robert R. Fenichel 和 Jerome C. Yochelson提出）和迭代（Cheney 提出）算法，以及解决了前两者递归栈、缓存行等问题的近似优先搜索算法。复制算法可以通过碰撞指针的方式进行快速地分配内存，但是也存在着空间利用率不高的缺点，另外就是存活对象比较大时复制的成本比较高

Copying（复制）

收集算法

ParNew：一款多线程的收集器，采用复制算法，主要工作在 Young 区，可以通过 -XX:ParallelGCThreads 参数来控制收集的线程数，整个过程都是STW 的，常与 CMS 组合使用

CMS：以获取最短回收停顿时间为目标，采用“标记 - 清除”算法，分 4 大步进行垃圾收集，其中初始标记和重新标记会 STW ，多数应用于互联网站或者 B/S 系统的服务器端上，JDK9 被标记弃用，JDK14 被删除，详情可见

分代收集器

G1：一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在实现高吞吐量的同时，尽可能地满足垃圾收集暂停时间的要求

Shenandoah：由 Red Hat 的一个团队负责开发，与 G1 类似，基于Region 设计的垃圾收集器，但不需要 Remember Set 或者 Card Table 来记录跨 Region 引用，停顿时间和堆的大小没有任何关系。停顿时间与 ZGC接近

分区收集器

收集对象

Invokevirtual：根据虚方法表调用虚方法。

invokeinteface：调用接口方法

invokestatic：调用静态方法

invokedynamic 动态语言支持 lamda

指令

JVM

jconsole

jstack(查看线程)、

接 top -hp 查看线程的16进制

jstack -l

得到运行java程序的内存分配的详细情况。

通过 mat(Eclipse Memory Analysis Tools)导入 dump 文件进行分析，内存泄漏问题一般我们直接选 Leak Suspects 即可

jmap -histo pid(查看实例)

jmap(查看内存)

可以观察到classloader，compiler，gc相关信息

jstat(性能分析)

运行

休眠

等待

驻留

监视

监控线程状态

JDK tools

匿名内部类（VM Anonymous Class）

invokedynamic

MethodHandle

依托

JVM_CONSTANT_InvokeDynamic

JVM_CONSTANT_MethodHandle

JVM_CONSTANT_MethodType

BootstrapMethods

类属性

多一个lambda方法

Lambda

函数式编程

Optional

Streams

MetaSpace代替了永久代

接口可以添加默认方法和静态方法

方法引用

不用 char[] 来存储啦，改成了 byte[] 加上编码标记

String存储结构

G1为JVM默认垃圾收集器

接口方法可以使用private来修饰

支持http2.0的API

并行Full GC，来优化G1的延迟

局部变量类型推断，类似JS可以通过var来修饰局部变量，编译之后会推断出值的真实类型

基于OS、JVM和JDK的事件产生的数据收集框架

Flight Recorder（飞行记录器）

Shenandoah GC

Switch 表达式表达式

版本升级特性

Linux进行OOM-killer机制

查看系统资源情况

/var/log/message

是否触发OOM

dump

当jvm出现致命错误时，会生成一个错误文件 hs_err_pid.log。

进程挂了

问题排查

java

2.x

3.x

列表

元组

字典

classmethod 修饰符对应的函数不需要实例化，不需要 self 参数，但第一个参数需要是表示自身类的 cls 参数，可以来调用类的属性，类的方法，实例化对象等

classmethod

HTTP 请求库

request

从网页抓取数据，将 html 解析为对象进行处理

BeautifulSoup

通过正则表达式是用来匹配处理字符串

time

pandas

对大数组的数据进行高效处理。优化包括NumPy是在一个连续的内存块中存储数据，独立于其他Python内置对象，如此便可以加速数据索引的速度。

NumPy调用了大量的用C语言编写的算法库，使得其可以直接操作内存，不必进行Python动态语言特性所含有的前期类型检查工作，从而大大提高了运算速度。

NumPy所有独有的可以在整个数组上执行复杂的计算也能够大幅提高运算效率（基于NumPy的算法要比纯Python快10到100倍，甚至会快更多）

秩，即轴的数量或维度的数量

.dim

对象的尺度，对于矩阵来说，即n行m列

.shape

对象的个数，即n*m的值

.size

对象的类型

.dtype

根据起始值等间距的填充数据，形成数组

类似range函数，放回ndarray类型，元素从0到n-1

np.arange(n)

根据shape生成一个全1数组，shape是元组类型

np.ones(shape)

根据shape生成一个全0数组

np.zeros(shape)

根据shape生成一个数组，每个元素值都为val

创建一个正方的n*n单位矩阵，对角线全为1其余为0

np.eye(n)

数组的创建方法

Numpy

使用面向对象的编程方式来表示文件系统路径

pathlib

Union

类型检查

typing

logging

模块

爬虫

djingo

flask

web框架

文件作为脚本直接执行

main方法写在声明方法后. 无法像java 可能是因为编译过程

if __name__ == '__main__':

conda install --channel https://conda.anaconda.org/conda-forge mnelab

The following packages are not available from current channels

channel

Anaconda

conda是包及其依赖项和环境的管理工具。

Anaconda repo和Cloud

包来源

conda

pip是用于安装和管理软件包的包管理器。

只能管理Python包。

PyPI

pip+virtualenv

在conda环境下，我们可以管理不同版本的Python，包括安装和升级Python本身。但是virtualenvs必须基于一个已经存在的、有外部管理的Python可执行文件。virtualenv能实现的只是不同环境下的python包互相独立，但是不同环境下用的python是同一个版本。

包管理

python

MFC

c++

后端

编程语言

生成实现子类的代理类

fast

CGLIB

生成实现接口的代理类

JDK

动态代理

AOP

Bean容器找到配置文件中Spring Bean的定义

Bean容器利用Java Reflection API创建一个Bean的实例

如果涉及到一些属性值，利用set()方法设置一些属性值

如果Bean实现了BeanNameAware接口，调用setBeanName()方法，传入Bean的名字

如果Bean实现了BeanClassLoaderAware接口，调用setBeanClassLoader()方法，传入ClassLoader对象的实例

如果Bean实现了BeanFactoryAware接口，调用setBeanClassFacotory()方法，传入ClassLoader对象的实例

与上面的类似，如果实现了其他*Aware接口，就调用相应的方法

如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象，执行postProcessBeforeInitialization()方法

该方法会在对象属性被设置后，即：调用了setter方法之后被调用

如果Bean实现了InitializingBean接口，执行afeterPropertiesSet()方法

如果Bean在配置文件中的定义包含init-method属性，执行指定的方法

如果有和加载这个Bean的Spring容器相关的BeanPostProcess对象，执行postProcessAfterInitialization()方法

当要销毁Bean的时候，如果Bean实现了DisposableBean接口，执行destroy()方法

当要销毁Bean的时候，如果Bean在配置文件中的定义包含destroy-method属性，执行指定的方法。

bean的生命周期

变量方式注入非常简洁，没有任何多余代码

变量注入

构造器注入

set方法注入

注入

减少创建

单例模式

原型模式

第一级缓存：单例池 singletonObjects，它用来存放经过完整Bean生命周期过程的单例Bean对象

第二级缓存：earlySingletonObjects，它用来保存哪些没有经过完整Bean生命周期的单例Bean对象，用来保证不完整的bean也是单例

第三级缓存：singletonFactories，工厂

三级缓存来解决循环依赖

循环依赖

bean

IOC

Nullable

NonNull

NonNullApi

NonNullFields

lang

控制Bean加载顺序

DependsOn

ClassPathXmlApplicationContext启动的Spring容器，通过ClassPathResource以类路径的方式进行访问

FileSystemXmlApplicationContext启动的Spring容器，通过FileSystemResource以文件系统绝对路径的方式进行访问

XmlWebApplicationContext启动的Spring容器，通过ServletContextResource以相对于Web应用根目录的方式进行访问

与ApplicationContext相同的策略

前缀"classpath:"是指定使用ClassPathResource

前缀"file:"则指定使用UrlResource

ResourceLoader

core

@ControllerAdvice

produces的作用是指定返回值类型和返回值编码

@RequestMapping

bind

拦截器（Interceptor）

servlet

web

Prepare this context for refreshing.

prepareRefresh()

Tell the subclass to refresh the internal bean factory.

obtainFreshBeanFactory()

Prepare the bean factory for use in this context.

DefaultListableBeanFactory.registerResolvableDependency

这些特殊实例变量直接获取

注册了可解析依赖项

Allows post-processing of the bean factory in context subclasses.

postProcessBeanFactory(beanFactory)

Invoke factory processors registered as beans in the context

invokeBeanFactoryPostProcessors(beanFactory)

registerBeanPostProcessors(beanFactory)

initMessageSource()

initApplicationEventMulticaster()

onRefresh()

registerListeners()

finishBeanFactoryInitialization(beanFactory)

finishRefresh()

refresh （）

AbstractApplicationContext

support

默认接口代理

boolean proxyTargetClass() default false;

EnableAspectJAutoProxy

例如@EnableAspectJAutoProxy

可以在类上使用，也可以作为元注解使用

可以拆分配置类，然后在程序中按需导入相应的配置

例子 @EnableRetry

@Configuration标注的配置类

根据给定的条件（AdviceMode），选择导入哪些配置类

例如@EnableTransactionManagemen

实现ImportSelector接口的类

按需注册额外的BeanDefinition

例如@EnableAspectJAutoProxy注解

实现ImportBeanDefinitionRegistrar接口的类

@component类

导入

@Import

@Autowired能够用在构造方法、成员变量、方法参数以及注解上

容易违背了单一职责原则使用这种基于 field 注入的方式，添加依赖是很简单的，就算你的类中有十几个依赖你可能都觉得没有什么问题，普通的开发者很可能会无意识地给一个类添加很多的依赖。但是当使用构造器方式注入，到了某个特定的点，构造器中的参数变得太多以至于很明显地发现 something is wrong。拥有太多的依赖通常意味着你的类要承担更多的责任，明显违背了单一职责原则（SRP：Single responsibility principle）。

依赖注入与容器本身耦合

基于 field 注入的坏处

强制依赖就用构造器方式

可选、可变的依赖就用 setter 注入

@Autowired

context

TransactionAspectSupport

TransactionInterceptor

注解从切面进入事务.所以非切面调用事务不生效

获取事务属性

getTransactionAttribute

确定事务管理器

determineTransactionManager(txAttr)

创建事务管理器如果有必要

AbstractPlatformTransactionManager

createTransactionIfNecessary

调用真实方法

retVal = invocation.proceedWithInvocation();

invokeWithinTransaction

interceptor

abstract Object doGetTransaction()

abstract void doCommit(DefaultTransactionStatus status)

abstract void doRollback(DefaultTransactionStatus status)

存储线程开启事务的数据库连接

TransactionSynchronizationManager

transaction

(ConnectionHolder) TransactionSynchronizationManager.getResource(obtainDataSource());

doGetTransaction()

DataSourceTransactionManager extends AbstractPlatformTransactionManager

datasource

jdbc

DefaultListableBeanFactory

factory

beans

Refresh

@SpringBootConfiguration

这个组合注解主要是@Import(AutoConfigurationPackages.Registrar.class)，它通过将Registrar类导入到容器中，而Registrar类作用是扫描主配置类同级目录以及子包，并将相应的组件导入到springboot创建管理的容器中

@AutoConfigurationPackage

AutoConfigurationImportSelector的作用是导入哪些组件的选择器

2.0.x默认CGlib动态代理

AopAutoConfiguration

getImportGroup

DeferredImportSelector

BeanClassLoaderAware

ResourceLoaderAware

BeanFactoryAware

EnvironmentAware

Ordered

它通过将AutoConfigurationImportSelector类导入到容器中，AutoConfigurationImportSelector类作用是通过selectImports方法实现将配置类信息交给SpringFactory加载器进行一系列的容器创建过程

@Import(AutoConfigurationImportSelector.class)

判断是否开启自动配置

从META-INF/spring-autoconfigure-metadata.properties文件中载入属性配置

获取所有的配置列表

@EnableAutoConfiguration

@ComponentScan

registerBeanDefinition

registerFeignClient

FeignClientsRegistrar.class

@EnableFeignClients

AnnotationConfigServletWebServerApplicationContext

SERVLET

AnnotationConfigReactiveWebServerApplicationContext

REACTIVE

AnnotationConfigApplicationContext

NONE

createApplicationContext

设置java.awt.headless

configureHeadlessProperty()

初始化META-INF\\spring.factories下SpringApplicationRunListener对应的实现类

SimpleApplicationEventMulticaster

EventPublishingRunListener

getSpringFactoriesInstances

getRunListeners(args)

listeners.starting()

multicastEvent

listeners.environmentPrepared

prepareEnvironment

configureIgnoreBeanInfo

printBanner

prepareContext

见 spring bean加载过程

ConfigurableApplicationContext.refresh()

refreshContext

afterRefresh

listeners.started(context)

ApplicationRunner.class

CommandLineRunner.class

执行

callRunners

listeners.running(context)

run

SpringApplication

ApplicationEvent

SpringApplicationRunListener

Set<ApplicationListener<?>> applicationListeners

DefaultListenerRetriever

AbstractApplicationEventMulticaster

event

ErrorController

error

boot

cap原理

DistroConsistencyServiceImpl

服务端注册

心跳

特殊场景

服务端某节点宕机，不回复其他服务端节点的健康检查请求，则会被其他节点从健康节点列表中剔除，其他节点重新分配负责节点，依靠客户端的心跳重新建立完整的服务数据

验证任务startVerifyTask()

同步任务startLoadTask();

纯内存保存

Distro

EphemeralConsistencyService

POST HTTP://{ip:port}/v1/ns/raft/vote : 进行投票请求

POST HTTP://{ip:port}/v1/ns/raft/beat : Leader向Follower发送心跳信息

GET HTTP://{ip:port}/v1/ns/raft/peer : 获取该节点的RaftPeer信息

PUT HTTP://{ip:port}/v1/ns/raft/datum/reload : 重新加载某日志信息

POST HTTP://{ip:port}/v1/ns/raft/datum : Leader接收传来的数据并存入

DELETE HTTP://{ip:port}/v1/ns/raft/datum : Leader接收传来的数据删除操作

GET HTTP://{ip:port}/v1/ns/raft/datum : 获取该节点存储的数据信息

GET HTTP://{ip:port}/v1/ns/raft/state : 获取该节点的状态信息{UP or DOWN}

POST HTTP://{ip:port}/v1/ns/raft/datum/commit : Follower节点接收Leader传来得到数据存入操作

DELETE HTTP://{ip:port}/v1/ns/raft/datum : Follower节点接收Leader传来的数据删除操作

RaftConsistencyServiceImpl

Raft

PersistentConsistencyService

DelegateConsistencyServiceImpl

nacos

consul

ZK是往Leader(主节点)去写数据

zookeeper（见hadoop分支）

注册中心

SPI重写线程池获取ThreadLocal值

线程隔离

信号量隔离

为每一个需要被调用的服务维护了一个独立的线程池，这样每个服务都有自己的使用资源，当某个服务出现问题时，大家互不影响。

信号量隔离我理解为对线程池隔离的一个补充功能，如果开辟专有线程池的开销远远大于该依赖服务正常的访问时间，那么我们就可以使用信号量隔离。

信号量的开销确实是小于线程池的开销的，不过信号量做不到线程池的设置超时和异步访问，所以啊，在确保服务确实靠谱的情况下，再采用信号量哈

hystrix舱壁模式

构建HystrixCommand或HystrixObservableCommand

Connection reset by peer

服务器返回了RST

Connection reset

hystrix

dashboard

统计数据：统计某个资源的访问数据（QPS、RT等信息）

规则判断：判断限流规则、隔离规则、降级规则、熔断规则是否满足

限流、隔离、降级、熔断

基于责任链模式来设计，将不同的功能（限流、降级、系统保护）封装为一个个的Slot，请求进入后逐个执行

StatisticSlot：负责统计实时调用数据，包括运行信息、来源信息等

ClusterBuilderSlot：负责构建某个资源的ClusterNode，ClusterNode可以保存资源的运行信息（响应时间、QPS、block 数目、线程数、异常数等）以及来源信息（origin名称）

NodeSelectorSlot：负责构建簇点链路中的节点（DefaultNode），将这些节点形成链路树

statistic

AuthoritySlot：负责授权规则（来源控制）

SystemSlot：负责系统保护规则

ParamFlowSlot：负责热点参数限流规则

FlowSlot：负责限流规则

DegradeSlot：负责降级规则

rule checking

ProcessorSlotChain

sentinel

熔断限流

actuator

extends AbstractHandlerMapping（spring-webflux）

寻找路由匹配返回 webHandler

找到yml中配置的所有的路由断言工厂执行

lookupRoute

getHandlerInternal

找到对应的适配器HandlerAdaptor，执行过滤器链

RoutePredicateHandlerMapping

globalFilters转化成GatewayFilterAdapter。 GatewayFilterAdapter在内部集成了GlobalFilter，同时也实现了GatewayFilter，使 globalFilters和gatewayFilters在适配器类GatewayFilterAdapter中共存

implements WebHandler（spring-web）

FilteringWebHandler

见 spring

spring-webflux

为请求添加一个preserveHostHeader=true的属性，路由过滤器会检查该属性以决定是否要发送原始的Host

- PreserveHostHeader

去掉一层url前缀

- StripPrefix=1

为原始请求添加Header

- AddRequestHeader

AddRequestParameter

AddResponseHeader

剔除响应头中重复的值

DedupeResponseHeader

为路由引入Hystrix的断路器保护

Hystrix

gateway

网关

#feignfeign.httpclient.enabled=truefeign.hystrix.enabled=truefeign.client.config.default.connectTimeout = 30000feign.client.config.default.readTimeout = 30000#ribbonribbon.OkToRetryOnAllOperations=falseribbon.ConnectTimeout=20000ribbon.ReadTimeout=50000ribbon.SocketTimeout=30000ribbon.ServerListRefreshInterval=10 ribbon.MaxAutoRetries=0ribbon.MaxAutoRetriesNextServer= 1#hystrixhystrix.command.default.execution.timeout.enabled=truehystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=20000

配置

cloud

RequestMappingHandlerAdapter

doDispatch

doService

前端控制器(DispatcherServlet)

处理器映射器(HandlerMapping)

拦截器

Handler处理器

处理器适配器(HandlerAdapter)

视图解析器(ViewResolver)

视图(View)

1.发起请求到前端控制器(DispatcherServlet)2.前端控制器请求处理器映射器(HandlerMapping)查找Handler(可根据xml配置、注解进行查找)3.处理器映射器(HandlerMapping)向前端控制器返回Handler4.前端控制器调用处理器适配器(HandlerAdapter)执行Handler5.处理器适配器(HandlerAdapter)去执行Handler6.Handler执行完，给适配器返回ModelAndView(Springmvc框架的一个底层对象)7.处理器适配器(HandlerAdapter)向前端控制器返回ModelAndView8.前端控制器(DispatcherServlet)请求视图解析器(ViewResolver)进行视图解析，根据逻辑视图名解析成真正的视图(jsp)9.视图解析器(ViewResolver)向前端控制器(DispatcherServlet)返回View10.前端控制器进行视图渲染，即将模型数据(在ModelAndView对象中)填充到request域11.前端控制器向用户响应结果

springmvc将url和controller方法映射。映射成功后springmvc生成一个Handler对象，对象中只包括了一个method

基于mvc拦截器

spring-mvc

\treturn Flux.fromIterable(this.handlerMappings) \t\t// 1.遍历所有的 handlerMapping

.concatMap(mapping -> mapping.getHandler(exchange)).next() // 2.获取对应的handlerMapping ，比如常用的 RequestMappingHandlerMapping、RoutePredicateHandlerMapping

处理所有过滤器链的方法

LoadBalancerClientFilter

负载均衡

ForwardRoutingFilter

转发路由网关过滤器

基于 Netty 实现的 HttpClient 请求后端 Http 服务

NettyRoutingFilter

将 NettyRoutingFilter 请求后端 Http 服务的响应写回客户端

NettyWriteResponseFilter

WebsocketRoutingFilter

websocket

WebClientHttpRoutingFilter

WebClientWriteResponseFilter

org.springframework.cloud.gateway.filter.WebClient实现的 HttpClient 请求后端 Http 服务

webclient

globalFilters

见gatway

网关适配器

webHandler.handle

SimpleHandlerAdapter

HandlerAdapter

链式调用

handle

DispatcherHandler

AbstractHandlerMethodMapping

AbstractUrlHandlerMapping

RouterFunctions

PropertySourcesPropertyResolver

Backpressure 其实是一种现象：在数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure 出现。

反应式 HTTP

服务器推送事件

WebSocket 的客户端和服务器端的支持

reactor-core实现响应式

Reactor

如果消息不可路由，应该通过Basic.Return RPC命令将消息返回给发布者。

mandatory

ConfirmCallback为发送Exchange（交换器）时回调，成功或者失败都会触发；

confirmCallback

ReturnCallback为路由不到队列时触发，成功则不触发；

returnCallback

sendConnectionFactorySelectorExpression

receiveConnectionFactorySelectorExpression

RabbitTemplate支持SpELsendConnectionFactorySelectorExpression 和receiveConnectionFactorySelectorExpression 属性，这些属性每个在每个AMQP协议的交互操作（send、sendAndReceive、receive、receiveAndReply）都会计算解析出来AbstractRoutingConnectionFactory提供的lookupKey值。您可以使用bean引用，例如在表达式中使用@vhostersolvergetVHost(#root)。在send操作中，要发送的消息是根源计算对象。在receive操作中，queueName是根源计算对象。

afterReceivePostProcessors

beforePublishPostProcessors

参数

RabbitTemplate

ConnectionFactory

spring-rabbit

spring-amqp

获取当前 request 对应的权限配置，调用访问控制器进行鉴权操作

FilterSecurityInterceptor

MethodSecurityInterceptor

AspectJMethodSecurityInterceptor

少数服从多数授权访问决策方案。

ConsensusBased

要求所有 AccessDecisionVoter 均返回肯定的结果时，才代表授予权限

UnanimousBased

只要任一 AccessDecisionVoter 返回肯定的结果，便授予访问权限。

AffirmativeBased

AccessDecisionManager

AfterInvocationManager

RunAsManager

AuthenticationManager

MessageSourceAccessor

AbstractSecurityInterceptor

Spring Security Filter Chain

@PreAuthorize

@EnableGlobalMethodSecurity(prePostEnabled = true)。

http.authorizeRequests() .url匹配规则1.权限控制方法1 .url匹配规则2.权限控制方法2...

permitAll()表示所匹配的URL任何人都允许访问

anonymous()表示可以匿名访问匹配的URL。和permitAll()效果类似，只是设置为anonymous()的url会执行filterChain中的filter

denyAll()表示所匹配的URL都不允许被访问。

authenticated()表示所匹配的URL都需要被认证才能访问

rememberMe()允许通过remember-me登录的用户访问

权限控制

anyRequest()

antMatcher(String regx)，传递一个ant表达式参数，表示匹配所有满足ant表达式的请求

regexMatchers(String regexPattern) 传递一个参数

匹配规则

authorizeRequests()

HttpSecurity

configure（）

WebSecurityConfigurerAdapter

SavedRequestAwareAuthenticationSuccessHandler

spring-security

org.springframework

在HttpServletRequest到达Servlet之前，拦截客户的HttpServletRequest。根据需要检查HttpServletRequest，也可以修改HttpServletRequest头和数据。在HttpServletResponse到达客户端之前，拦截HttpServletResponse。根据需要检查HttpServletResponse，也可以修改HttpServletResponse头和数据。

过滤器

sendRedirect(String url)

HttpServletResponse

HttpServletRequest

http

注册NioServerSocketChannel

注册NioSocketChannel

管道(SelectableChannel)

选择器(Selector)

选择键(SelectorKey)

Selector（多路复用器）

NioEventLoop

NioEventLoopGroup

一个Channel包含一个ChannelPipeline，所有ChannelHandler都会注册到ChannelPipeline中，并按顺序组织起来。

Channe

客户端发起请求再接受请求，先 outbound再inbound。服务端：先接受请求再发送请求，先inbound再outbound.

NettyInbound

sendUpstream

ChannelSink

NettyOutbound

sendDownstream

一个ChannelEvent并不会主动的"流"经所有的Handler，而是由上一个Handler显式的调用ChannelPipeline.sendUp(Down)stream产生，并交给下一个Handler处理。也就是说，每个Handler接收到一个ChannelEvent，并处理结束后，如果需要继续处理，那么它需要调用sendUp(Down)stream新发起一个事件。如果它不再发起事件，那么处理就到此结束，即使它后面仍然有Handler没有执行。这个机制可以保证最大的灵活性，当然对Handler的先后顺序也有了更严格的要求。

ChannelPipeline

EventLoop

ChannelUpstreamHandler

ChannelDownstreamHandler

ChannelHandler

Channel

模型

第一创建与服务端的连接（即OP_CONNECT事件），第二就是进行IO读写、编解码、业务逻辑等操作（即OP_READ事件、OP_WRITE事件）

客户端发出连接请求的同时会自己创建一条NioSocketChannel通道与服务端NioSocketChannel进行互通，连接完之后就是WorkGroup的事了，不需要BossGroup管了

一个客户端连接对应一条服务端NioSocketChannel

ClientGroup

客户端

向WorkGroup中的某个Selector注册刚才创建好的NioSocketChannel

ServerBootStrapAcceptor

创建一个NioSocketChannel实例

对客户端的新连接请求进行处理（OP_ACCEPT）

BossGroup

负责处理IO读写、编解码、业务逻辑等（即OP_READ事件、OP_WRITE事件）

WorkGroup

服务端启动的时候会绑定一个端口，作为后续客户端连接入口

服务端

SelectionKey.OP_READ

SelectionKey.OP_WRITE

SelectionKey.OP_ACCEPT

SelectionKey.OP_CONNECT

IO事件类型

对应 mainReactor

对应 subReactor

多线程的Reactor模式

EpollEventLoop

多路复用

netty

Flux是一个发出(emit)0-N个元素组成的异步序列的Publisher

just

Flux

Mono 是一个发出(emit)0-1个元素的Publisher

Mono

publisher

collection

结果嵌套

SqlSessionFactoryBuilder（构造器）

SqlSessionFactory：依靠工厂来生成SqlSession。

SqlSession：是一个既可以发送SQL去执行并返回结果的，也可以获取Mapper接口，通过Mapper接口查询并封装数据。

SQL Mapper:它是MyBatis新设计的组件，它是由一个Java接口和XML文件（或者注解)构成的，需要给出对应的SQL和映射规则。它负责发送SQL去执行，并返回结果。

执行流程

日志

异常

缓存

xml解析，${} 格式的字符串解析

org.apache.ibatis.parsing

解析

实现java和jdbc中的类型之间转换

类型处理器

绑定

注解

映射

执行器

org.apache.ibatis.transactionorg.apache.ibatis.transaction.jdbcorg.apache.ibatis.transaction.managed

事务

数据源

org.apache.ibatis.sessionorg.apache.ibatis.session.defaults

会话

mapper.xml中的namespace和实际的mapper文件不一致

mapper接口中的方法名和mapper.xml中的id标签不一致

Mapper.xml没有构建进去

配置文件导不出来

mapper-locations 配置 xml

Invalid bound statement (not found)

BindingException

generator

PersistenceException

exceptions

selectList（）

defaults

session

SqlSession执行增删改查都是委托给Executor

CachingExecutor用于处理二级缓存，如果缓存中不存在要查询的数据，那么将查询请求委托给其他的Executor。如果是执行SQL的增删改，那么CachingExecutor将清空二级缓存。

CachingExecutor

BaseExecutor是除CachingExecutor之外，其他Executor实现类的基类。该类主要处理一级缓存

BaseExecutor

SimpleExecutor

BatchExecutor

executor

Plugin

MybatisPlusInterceptor（mybaits-plus实现）

PageInterceptor（pagehelper实现）

PaginationInterceptor（mybatis-plus作废的实现）

Interceptor

plugin

apache.ibatis

SqlSessionTemplate

spring

mybatis

org

protected long limit = 500L;

PaginationInterceptor

plugins

extension

com.baomidou.mybatisplus

mybatisplus

getConnectionDirect

GetConnectionTimeoutException

DataSource用来取代DriverManager来获取Connection，获取速度快，同时可以大幅度提高数据库访问速度。

初始化时建立物理连接的个数。初始化发生在显示调用init方法，或者第一次getConnection时

initialSize

最大连接池数量

maxActive

最小连接池数量

minIdle

获取连接时最大等待时间，单位毫秒。配置了maxWait之后，缺省启用公平锁，并发效率会有所下降，如果需要可以通过配置useUnfairLock属性为true使用非公平锁。

maxWait

是否缓存preparedStatement，也就是PSCache。PSCache对支持游标的数据库性能提升巨大，比如说oracle。在mysql下建议关闭。

poolPreparedStatements

申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。

默认 true

testOnBorrow

testOnReturn

默认 false

有两个含义： 1) Destroy线程会检测连接的间隔时间 2) testWhileIdle false

配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒

timeBetweenEvictionRunsMillis

testWhileIdle

Druid

锁定事务单元（lock）

确认事务模块状态(confirm)

通知事务(notify)

TX-LCN

维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚

Transaction Coordinator (TC)：事务协调器

负责开启一个全局事务，并最终发起全局提交或全局回滚的决议

Transaction Manager (TM)：控制全局事务的边界

负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

Resource Manager (RM)：控制分支事务

TM是一个分布式事务的发起者和终结者，TC负责维护分布式事务的运行状态，而RM则负责本地事务的运行

Read Uncommitted

隔离级别

TM 要求 TC 开始新的全局事务。TC 生成一个代表全局事务的 XID。

XID 通过微服务的调用链传播

RM将本地事务注册为XID对应的全局事务的一个分支到TC。

TM 要求 TC 提交或回滚 XID 对应的全局事务。

TC 驱动 XID 对应的全局事务下的所有分支事务完成分支提交或回滚。

生命周期

Seata

监控

MetricsMonitor

multimap

multiset

google-guava

ConnectionImpl

mysql-connect-java

当此属性设置为true时，配置文件如果发生改变，将会被重新加载，默认值为true

scan

用来设置某一个包或者具体的某一个类的日志打印级别、以及指定 <appender>。<logger> 仅有一个name属性，一个可选的level和一个可选的addtivity属性

是负责写日志的组件。该标签负责以适当的格式将日志记录事件输出到适当的输出设备

滚动记录文件，先将日志记录到指定文件，当符合某个条件时，将日志记录到其他文件

RollingFileAppender

常用的 appender 类型

对日志进行格式化

标签

logback

log

gRPC (gRPC Remote Procedure Calls) 是 Google 发起的一个开源远程过程调用系统

gRPC

Dubbo是阿里巴巴开源的基于 Java 的高性能RPC（一种远程调用）分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

泛化调用

Dubbo

rpc

使用表达式访问Json数据

JSONPath

fastjson

多态类型的序列化及反序列化

JsonTypeInfo

Jackson

json

JSqlParser

reflections

Keras

线性内核线性内核是最简单的内核函数。

多项式内核多项式验证非标准内核函数，该函数非常适合于正交归一化的数据。

高斯核这里是经典的鲁棒径向基核，即高斯核函数。

指数核。

拉普拉斯内核。

方差分析内核。

乙状结肠

Wave内核

三角核

日志内核

内核功能

TensorFlow

Raw

通过Raw对象和事件事件点(event times)

通过读取.fif文件数据生成Epoch对象

通过mne.EpochsArray从头创建Epoch对象

创建Epochs对象方式

从连续的脑电图信号中提取一些特定时间窗口的信号，分析事件，这些时间窗口可以称作为epochs.

Epochs

Evoked potential(EP)诱发电

Evoked

sleep_physionet

dataset

参考电极

mne

PyTorch是使用GPU和CPU优化的深度学习张量库。

含了多维张量的数据结构以及基于其上的多种数学操作。另外，它也提供了多种工具，其中一些可以更有效地对张量和任意类型进行序列化。

张量 Tensors

优化算法的库

对SGD的扩展，可以代替经典的随机梯度下降法来更有效地更新网络权重。

为每一个参数保留一个学习率以提升在稀疏梯度（即自然语言和计算机视觉问题）上的性能。

适应性梯度算法（AdaGrad）

基于权重梯度最近量级的均值为每一个参数适应性地保留学习率。这意味着算法在非稳态和在线问题上有很有优秀的性能。

均方根传播（RMSProp）

Adam 算法同时获得了 AdaGrad 和 RMSProp 算法的优点。Adam 不仅如 RMSProp 算法那样基于一阶矩均值计算适应性参数学习率，它同时还充分利用了梯度的二阶矩均值（即有偏方差/uncentered variance）。具体来说，算法计算了梯度的指数移动均值（exponential moving average），超参数 beta1 和 beta2 控制了这些移动均值的衰减率。移动均值的初始值和 beta1、beta2 值接近于 1（推荐值），因此矩估计的偏差接近于 0。该偏差通过首先计算带偏差的估计而后计算偏差修正后的估计而得到提升。

adam

torch.optim

该接口定义在dataloader.py脚本中，只要是用PyTorch来训练模型基本都会用到该接口，该接口主要用来将自定义的数据读取接口的输出或者PyTorch已有的数据读取接口的输入按照batch size封装成Tensor，后续只需要再包装成Variable即可作为模型的输入

DataLoader

data

util

多个GPU来加速训练

nn.DataParallel

torch.nn

torch

sklearn是基于python语言的机器学习工具包

广义线性模型

普通最小二乘法

监督学习

pipeline

sklearn

NumPy

OpenCV

Scikit-learn

Pandas

Matplotlib

PyTorch

PaddlePaddle

框架组件库

Nginx创建一个client-fd，与要转发的服务器进行通讯，当目标服务器把数据写回的时候，被Nginx的epoll监听到，然后再处理这个事件！

反向代理

限流

证书配置

为了协调客户端到nginx以及nginx到服务器的速度不同

缓冲区

X-Frame-Options

嵌套Frame

采用的所谓事件驱动往往局限在 TCP 连接建立、关闭事件上，一个连接建立以后，在其关闭之前的所有操作都不再是事件驱动，这时会退化成按顺序执行每个操作的批处理模式，这样每个请求在连接建立后都将始终占用着系统资源，直到关闭才会释放资源。这种请求占用着服务器资源等待处理的模式会造成服务器资源极大的浪费。

事件驱动架构

根据每个 fd 上面的 callback 函数实现的，

所以 epoll 不会随着监听 fd 数目的增长而降低效率

epoll 模型

Master-Worker模式多进程单线程模型

sendfile

静态文件

nginx

包含多个服务 service

一个Service只有一个Container，但是可以有多个Connectors

不同的ProtocolHandler代表不同的连接类型，比如：Http11Protocol使用的是普通Socket来连接的，Http11NioProtocol使用的是NioSocket来连接的。

Coyote通信端点，即通信监听的接口，是具体的Socker接收处理类，是对传输层的抽象。Tomcat并没有Endpoint接口，而是提供了一个抽象类AvstractEndpoint。根据I/O方式的不同，提供了NioEndpoint（NIO）、AprEndpoint（APR）以及Nio2Endpoint（NIO2）三个实现

Endpoint用来处理底层Socket的网络连接

Endpoint

Coyote协议处理接口，负责构造Request和Response对象，并且通过Adapter将其提交到Catalina容器处理，是对应用层的抽象。Processor是单线程的，Tomcat在同一次链接中复用Processor。Tomcat按照协议的不同提供了3个实现类：Http11Processor（HTTP/1.1）、AjpProcessor（AJP）、StreamProcessor（HTTP/2.0）。除此之外，他还提供了两个用于处理内部处理的实现：UpgradeProcessorInternal和UpgradeProcessorExternal，前者用于处理内部支持的升级协议（如HTTP/2.0和WebSocket），后者用于处理外部扩展的升级协议支持。

Processor用于将Endpoint接收到的Socket封装成Request

Processor

Adapter用于将Request交给Container进行具体的处理。

Adapter

ProtocolHandler

Connector用于处理连接相关的事情，并提供Socket与Request和Response相关的转化

Coyote是Tomcat链接器框架的名称

Coyote将Socket输入转换为Request对象，交由Catalina容器进行处理，处理请求完成之后，Catalina通过Coyote提供的Response对象将结果写入输出流。

Coyote封装了底层的网络通信（Socket请求以及响应处理），为Catalina容器提供了统一的接口

coyote

Connector

Catalina servlet容器

引擎，用来管理多个站点，一个Service最多只能有一个Engine

Engine

代表一个站点，也可以叫虚拟主机，通过配置Host就可以添加站点；

Host

代表一个应用程序，对应着平时开发的一套程序，或者一个WEB-INF目录以及下面的web.xml文件；

Context

每一Wrapper封装着一个Servlet；

Wrapper

Pipeline-Value是责任链模式

Container处理请求是使用Pipeline-Value管道来处理的！

Container

service

顶层容器 server

BIO

基于JDK的java.nio包

NIO

APR

模式

"common gateway interface"，通用网关接口，CGI的存在，可以是用户通过浏览器来访问执行在服务器上的动态程序；CGI是Web服务器与CGI程序间传输数据的标准；

CGI

用一个线程去遍历轮询每一个连接，然后得到需要处理的连接，并对这些连接进行处理。

select 模型

maxThreads

当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100

acceptCount

tomcat

•源站内容有更新的时候，源站主动把内容推送到CDN节点。

•常规的CDN都是回源的。即：当有用户访问某一个URL的时候，如果被解析到的那个CDN节点没有缓存响应的内容，或者是缓存已经到期，就会回源站去获取。如果没有人访问，那么CDN节点不会主动去源站拿的。

•回源域名

回源

工作方法

边缘层

中心层

源站

http标准协议

CDN

undertow

resin

jetty

同一时间只占用一个 CPU，只能有一个指令在运行，并行读写是不存在的。

单线程

缓存、限流、分布式锁、分布式session

string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象string类型是Redis最基本的数据类型，一个键最大能存储512MB。

String（字符串）

用户信息

时间轴、简单队列

List类型是按照插入顺序排序的字符串链表（所以它这里的list指的相当于java中的linkesdlist）

List类型

赞、踩

Set类型看作为没有排序的字符集合。如果多次添加相同元素，Set中将仅保留该元素的一份拷贝。

set类型

排行榜

Sorted-Sets中的每一个成员都会有一个分数(score)与之关联

Sorted-Sets类型

位图

HLL

GEO（地理信息）

跳跃表

设计

跳跃列表（skipList）

底层结构

xadd mystream * name zhangsan age 18;

添加消息

xgroup create mystream cg1 $

创建消费组

xreadgroup group cg1 godconsumer streams mystream >

消费消息

xack mystream cg1 1636612497298-0

ACK

XPENDING mystream cg1

查询未消费消息

消费组，使用 XGROUP CREATE 命令创建，一个消费组有多个消费者(Consumer)。

Consumer Group

游标，每个消费组会有个游标 last_delivered_id，任意一个消费者读取了消息都会使游标 last_delivered_id 往前移动。

last_delivered_id

消费者(Consumer)的状态变量，作用是维护消费者的未确认的 id。 pending_ids 记录了当前已经被客户端读取的消息，但是还没有 ack (Acknowledge character：确认字符）。

pending_ids

stream

处理客户端请求时，不会阻塞主线程；Redis 单纯执行（大多数指令）一个指令不到 1 微秒[4]，如此，单核 CPU 一秒就能处理 1 百万个指令（大概对应着几十万个请求吧），用不着实现多线程（网络才是瓶颈）。

多路 I/O 复用机制

使用操作系统提供的虚拟内存来存储数据

这段时间，redis 是无法处理请求的。

RDB 全量持久化

AOF 增量持久化

持久化

纯文本格式（redis文本协议的流水记录），加载的过程相当于历史重放

aof（日志文件）

二进制格式，直接进行加载，所以一般情况下rdb数据加载会比aof加载快

rdb（快照文件）

replication（主从复制）

数据迁移方式

First In First Out，先进先出。

FIFO 淘汰最早数据

Least Recently Used，最近最少使用。

LRU 剔除最近最少使用

Least Frequently Used，最不经常使用。

LFU 剔除最近使用频率最低

noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）

allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。

allkeys-random: 回收随机的键使得新添加的数据有空间存放。

volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。

淘汰策略

redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！

定期删除

定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，也是够懒的哈

惰性删除

删除策略

Sentine l哨兵

高可用

异步补偿

数据不一致

跳表

事务提供了一种将多个命令请求打包

批量操作在发送 EXEC 命令前被放入队列缓存

Lua脚本

不保证原子性

没有隔离级别

且没有回滚

multi : 标记一个事务块的开始（ queued ）

exec : 执行所有事务块的命令（一旦执行exec后，之前加的监控锁都会被取消掉）　

discard : 取消事务，放弃事务块中的所有命令

unwatch : 取消watch对所有key的监控

多套环境

redlock 红锁

redis

Tair

neo4j

nosql

Binary log

解释器

全表扫描（顺序扫描(sequential scan)）

索引扫描

优化器

服务层

核心服务

引擎事务日志

存储引擎

系统文件层

逻辑架构

主键ID

事务ID

回滚指针

系统内部字段

trx_sys->mysql_trx_list 包含了所有用户线程的事务对象，即使是未开启的事务对象，只要还没被回收到trx_pool中，都被放在该链表上。当session断开时，事务对象从链表上摘取，并被回收到trx_pool中，以待重用。

trx_sys->rw_trx_list 读写事务链表，当开启一个读写事务，或者事务模式转换成读写模式时，会将当前事务加入到读写事务链表中，链表上的事务是按照trx_t::id有序的；在事务提交阶段将其从读写事务链表上移除。

trx_sys->serialisation_list 序列化事务链表，在事务提交阶段，需要先将事务的undo状态设置为完成，在这之前，获得一个全局序列号trx->no，从trx_sys->max_trx_id中分配，并将当前事务加入到该链表中。随后更新undo等一系列操作后，因此进入提交阶段的事务并不是trx->id有序的，而是根据trx->no排序。当完成undo更新等操作后，再将事务对象同时从serialisation_list和rw_trx_list上移除。

trx_sys->rw_trx_ids 记录了当前活跃的读写事务ID集合，主要用于构建ReadView时快速拷贝一个快照

trx_sys->rw_trx_set 这是的映射集合，根据trx_id排序，用于通过trx_id快速获得对应的事务对象。一个主要的用途就是用于隐式锁转换，需要为记录中的事务id所对应的事务对象创建记录锁，通过该集合可以快速获得事务对象

集合

事务链表和集合

trx_sys

在Innodb中，每次开启一个事务时，都会为该session分配一个事务对象。而为了对全局所有的事务进行控制和协调，有一个全局对象trx_sys，对trx_sys相关成员的操作需要trx_sys->mutex锁。

Innodb使用一种称做ReadView(视图)的对象来判断事务的可见性（也就是ACID中的隔离性）

对于普通的读写事务，总是为其指定一个回滚段（默认128个回滚段）。而对于只读事务，如果使用到了InnoDB临时表，则为其分配(1~32)号回滚段。（回滚段指定参阅函数trx_assign_rseg_low）

当为事务指定了回滚段后，后续在事务需要写undo页时，就从该回滚段上分别分配两个slot，一个用于update_undo，一个用于insert_undo。分别处理的原因是事务提交后，update_undo需要purge线程来进行回收，而insert_undo则可以直接被重利用。

事务回滚段

Innodb的多版本数据使用UNDO来维护的，例如聚集索引记录(1) =>(2)=>(3)，从1更新成2，再更新成3，就会产生两条undo记录。

事务锁维护在不同的Isolation level下数据库的Atomicity和Consistency两大基本特性。

一类是mutex，实现内存结构的串行化访问

一类是rw lock，实现读写阻塞，读读并发的访问的读写锁

内存锁为了维护内存结构的一致性，比如Dictionary cache、sync array、trx system等结构。 InnoDB并没有直接使用glibc提供的库，而是自己封装了两类：

undo log

Atomicity(原子性)

保证数据页的准确性

doublewrite buffer

保证恢复时能够将所有的变更apply到数据

崩溃恢复时存在还未提交的事务，那么根据XA规则提交或者回滚事务

crash recovery

Consistency （一致性）

事务A读到了事务B还没有提交的数据

READ-UNCOMMITTED 在该隔离级别下会读到未提交事务所产生的数据更改，这意味着可以读到脏数据，实际上你可以从函数row_search_mvcc中发现，当从btree读到一条记录后，如果隔离级别设置成READ-UNCOMMITTED，根本不会去检查可见性或是查看老版本。这意味着，即使在同一条SQL中，也可能读到不一致的数据。

脏读

读未提交(READ UNCOMMITED)

在一个事务里面读取了两次某个数据，读出来的数据不一致

每次select都生成一个快照读

READ-COMMITTED 在该隔离级别下，可以在SQL级别做到一致性读，当事务中的SQL执行完成时，ReadView被立刻释放了，在执行下一条SQL时再重建ReadView。这意味着如果两次查询之间有别的事务提交了，是可以读到不一致的数据的。

不可重复读

读已提交(READ COMMITTED)

事务后第一个select语句才是快照读的地方

并发的事务中有事务发生了插入、删除操作

在一个事务里面的操作中发现了未被操作的数据

行锁只能锁住行，即使把所有的行记录都上锁，也阻止不了新插入的记录。

幻读（当前读）

REPEATABLE-READ 可重复读和READ-COMMITTED的不同之处在于，当第一次创建ReadView后（例如事务内执行的第一条SEELCT语句），这个视图就会一直维持到事务结束。也就是说，在事务执行期间的可见性判断不会发生变化，从而实现了事务内的可重复读。

可重复读(REPEATABLE READ)

序列化(SERIALIZABLE)

Isolation(隔离性)

WAL（Write-Ahead Logging）的原则

Redo log和数据页都做了checksum校验

为了解决半写的问题，即写一半数据页时实例crash，这时候数据页是损坏的。InnoDB使用double write buffer来解决这个问题，在写数据页到用户表空间之前，总是先持久化到double write buffer，这样即使没有完整写页，我们也可以从double write buffer中将其恢复出来。你可以通过innodb_doublewrite选项来开启或者关闭该特性。

Durability(持久性)

事务特性

只读事务

读写事务

读写事务并不意味着一定在引擎层就被认定为读写事务了，5.7版本InnoDB里总是默认一个事务开启时的状态为只读的。举个简单的例子，如果你事务的第一条SQL是只读查询，那么在InnoDB层，它的事务状态就是只读的，如果第二条SQL是更新操作，就将事务转换成读写模式。

BEGIN

当Server层接受到任何数据更改的SQL时，都会直接拒绝请求，返回错误码ER_CANT_EXECUTE_IN_READ_ONLY_TRANSACTION，不会进入引擎层。

这个选项可以强约束一个事务为只读的，而只读事务在引擎层可以走优化过的逻辑，相比读写事务的开销更小，例如不用分配事务id、不用分配回滚段、不用维护到全局事务链表中。

START TRANSACTION READ ONLY

START TRANSACTION READ WRITE

innobase_start_trx_and_assign_read_view

这里会进入InnoDB层，调用函数innobase_start_trx_and_assign_read_view，注意只有你的隔离级别设置成REPEATABLE READ（可重复读）时，才会显式开启一个Read View

START TRANSACTION WITH CONSISTENT SNAPSHOT

无需显式开启事务，如果你执行多条SQL但不显式的调用COMMIT（或者执行会引起隐式提交的SQL）进行提交，事务将一直存在

AUTOCOMMIT = 0

事务开启

事务类型

回滚的方式是提取undo日志，做逆向操作

InnoDB的undo是单独写在表空间中的，本质上和普通的数据页是一样的。如果在事务回滚时，undo页已经被从内存淘汰，回滚操作（特别是大事务变更回滚）就可能伴随大量的磁盘IO。因此InnoDB的回滚效率非常低

事务回滚

Server层的MDL锁模块，维持了一个事务过程中所有涉及到的表级锁对象。通过MDL锁，可以堵塞DDL，避免DDL和DML记录binlog乱序

InnoDB的trx_sys子系统，维持了所有的事务状态，包括活跃事务、非活跃事务对象、读写事务链表、负责分配事务id、回滚段、Readview等信息，是事务系统的总控模块；

InnoDB的lock_sys子系统，维护事务锁信息，用于对修改数据操作做并发控制，保证了在一个事务中被修改的记录，不可以被另外一个事务修改；

InnoDB的log_sys子系统，负责事务redo日志管理模块；

InnoDB的purge_sys子系统，则主要用于在事务提交后，进行垃圾回收，以及数据页的无效数据清理。

在InnoDB中一直维持了一个不断递增的整数，存储在trx_sys->max_trx_id中；每次开启一个新的读写事务时，都将该ID分配给事务，同时递增全局计数。事务ID可以看做一个事务的唯一标识。

事务管理执行

回滚段undo是实现InnoDB MVCC的根基。每次修改聚集索引页上的记录时，变更之前的记录都会写到undo日志中。回滚段指针包括undo log所在的回滚段ID、日志所在的page no、以及page内的偏移量，可以据此找到最近一次修改之前的undo记录，而每条Undo记录又能再次找到之前的变更。

undo日志

ReadView::id 创建该视图的事务ID；

ReadView::m_ids 创建ReadView时，活跃的读写事务ID数组，有序存储；

ReadView::m_low_limit_id 设置为当前最大事务ID；

ReadView::m_up_limit_id m_ids集合中的最小值，如果m_ids集合为空，表示当前没有活跃读写事务，则设置为当前最大事务ID。

Readview

快照读

加排他锁

间隙锁

1.对主键或唯一索引，如果当前读时，where条件全部精确命中(=或者in)，这种场景本身就不会出现幻读，所以只会加行记录锁。

2.没有索引的列，当前读操作时，会加全表gap锁，生产环境要注意

3.非唯一索引列，如果where条件部分命中(>、<、like等)或者全未命中，则会加附近Gap间隙锁。

update ... (更新操作)

delete ... (删除操作)

insert ... (插入操作)

select ... lock in share mode (共享读锁)

select ... for update (写锁)

场景

当前读

聚集索引

二级索引

可见性判断

多版本并发控制MVCC

GTID

数据库事务

LOCK_X（排他锁）

LOCK_S（共享锁）

意向共享锁（ Intent share lock，简称IS锁）

意向排它锁（ Intent Exclusive lock，简称IX锁）

表锁

锁带上这个 FLAG 时，表示这个锁对象只是单纯的锁在记录上，不会锁记录之前的 GAP。在 RC 隔离级别下一般加的都是该类型的记录锁（但唯一二级索引上的 duplicate key 检查除外，总是加 LOCK_ORDINARY 类型的锁）。

LOCK_REC_NOT_GAP

记录锁(RK)

表示只锁住一段范围，不锁记录本身，通常表示两个索引记录之间，或者索引上的第一条记录之前，或者最后一条记录之后的锁。可以理解为一种区间锁，一般在RR隔离级别下会使用到GAP锁。

间隙锁(GK) LOCK_GAP

类型

而NEXT-KEY LOCK正是为了解决RR隔离级别下的幻读问题。所谓幻读就是一个事务内执行相同的查询，会看到不同的行记录。在RR隔离级别下这是不允许的。

LOCK_ORDINARY(Next-Key Lock)

插入意向锁(IK) LOCK_INSERT_INTENTION(插入意向锁)

行锁

InnoDB 通常对插入操作无需加锁，而是通过一种“隐式锁”的方式来解决冲突。聚集索引记录中存储了事务id，如果另外有个session查询到了这条记录，会去判断该记录对应的事务id是否属于一个活跃的事务，并协助这个事务创建一个记录锁，然后将自己置于等待队列中。该设计的思路是基于大多数情况下新插入的记录不会立刻被别的线程并发修改，而创建锁的开销是比较昂贵的，涉及到全局资源的竞争。

隐式锁

16k

Row size too large (> 8126).

每个page至少要包含两个记录

最小存储单元

页

自增ID可以保证每次插入时B+索引是从右边扩展的，可以避免B+树和频繁合并和分裂（对比使用UUID）。如果使用字符串主键和随机主键，会使得数据随机插入，效率比较差。

推荐自增 id 做主键

6字节

指针

768字节的时候，剩余部分会保存在另外的页面（off-page）

64K

如果我们想在创建的表的时候，保证创建的表中的text字段都能安全的达到64k上限（而不是等插入的时候才发现），那么需要将默认为OFF的innodb_strict_mode设置为ON，这样在建表时会先做判断

text

一般情况下，当我们需要读入一个Page时，首先根据space id 和page no找到对应的buffer pool instance。然后查询page hash，如果page hash中没有，则表示需要从磁盘读取。在读盘前首先我们需要为即将读入内存的数据页分配一个空闲的block。当free list上存在空闲的block时，可以直接从free list上摘取；

流程

我们知道InnoDB使用buffer pool来缓存从磁盘读取到内存的数据页。buffer pool通常由数个内存块加上一组控制结构体对象组成

buffer pool

对于 VARCHAR、VARBINARY、BLOB、TEXT 这类可变长字段，如果数据长度过长，会将其单独存储在主索引记录之外的 LOB page 上（从主索引所属的 tablespace 上分配）

InnoDB 将一个 LOB 字段直接存储在多个 LOB page 中，这些 LOB page 组成一个单向链表

随机访问 LOB 中的数据是非常低效的

8.0前

LOB index 来索引 LOB page

在 LOB 字段更新了部分数据后，user tablespace 中还是只有一个 LOB，更新操作只会修改部分 LOB data page，并且 LOB 中同时存在被修改 LOB data page 的多个版本

MVCC

8.0

LOB

记录sql

优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，

Statement

不记录sql语句上下文相关信息，仅保存哪条记录被修改。

ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。)

Row

是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog

有数据一致性问题走Row

Mixed

格式

【Log_name】:日志名称

【pos】上次操作点的序号

TABLE_MAP_EVENT

代表binlog日志的第一条，且只会在第一次出现

FORMAT_DESCRIPTION_EVENT

实测没有换文件也会有该事件

当MySQL切换至新的binlog文件的时候，MySQL会在旧的binlog文件中写入一个ROTATE_EVENT，表示新的binlog文件的文件名

ROTATE_EVENT

记录更新操作的语句

QUERY_EVENT

在开启ROW模式记录的binlog文件中，WRITE_ROWS_EVENT记录了插入的行记录。

WRITE_ROWS_EVENT

在开启ROW模式记录的binlog文件，UPDATE_ROWS_EVENT记录了更新的行记录。

UPDATE_ROWS_EVENT

在开启ROW模式记录的binlog文件，DELETE_ROWS_EVENT记录了删除的行记录。

DELETE_ROWS_EVENT

ROWS_EVENT

当事务提交时，无论哪种模式都会记录。

XID_EVENT

在启用GTID模式（主从复制模式）后，MySQL将为每个事务都分配了个GTID。

GTID_LOG_EVENT

开启GTID模式（主从复制）后，每个binlog开头都会有一个PREVIOUS_GTIDS_LOG_EVENT（在后简称PE）事件，它的值是上一个binlog的PE+GTID信息。

PREVIOUS_GTIDS_LOG_EVENT

当MySQL数据库停止时，会在当前的binlog末尾添加一个STOP_EVENT事件表示数据库停止。

STOP_EVENT

【event_type】事件类型

show binlog events;

查看

# at 523 #210405 21:08:18 server id 1 end_log_pos 639 Query thread_id=13 exec_time=0 error_code=0 SET TIMESTAMP=1617628098/*!*/; update user set username='zhangqian' where uid = '15' /*!*/;

at后面的数字代表在binlog日志文件的第几个字节开始（at 523 ）

postion（描述）

即第二行的（#210405 21:08:18）

timestamp（事件发生的时间戳）

（1），代表执行的主机编号

server id（服务器标识）

结束的字节位置639

end_log_pos（结束字节数）

事件类型。

Query（类型）

处理的线程编号(13)

thread_id

执行花费的时间

exec_time

错误码

error_code

SET TIMESTAMP=1617628098/*!*/;代表执行的时间戳

update user set username='zhangqian' where uid = '15' 代表执行的语句，遇到下一个#at 则为下一个binlog日志事件。

日志解析

将会清空00000X之前的所有日志文件.

purge master logs to "binlog_name.00000X"

（2）使用命令

(3) 使用--expire_logs_days=N选项指定过了多少天日志自动过期清空。

删除binlog

binlog

512字节

不管是log buffer中还是os buffer中以及redo log file on disk中，都是这样以512字节的块存储的

12字节

日志头

492字节

日志体

8字节

日志尾

redo log block

redo

旧版本数据读取

purge时扫描undo log record

崩溃恢复时扫描undo log record

大事务回滚

undo log segment

rollback segment称为回滚段，每个回滚段中有1024个undo log segment。

回滚

undo

备库通过二进制日志重放主库提交的事务，而主库binlog写入在commit之前，如果写完binlog主库crash，再次启动时会回滚事务。但此时从库已经执行，则会造成主备数据不一致

–自动为每个事务分配一个唯一的ID（XID）–COMMIT会被自动的分成Prepare和Commit两个阶段。– Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。

若关闭了binlog，且存在不止一种事务引擎时，则XA控制对象为tc_log_mmap；

若打开binlog，且使用了事务引擎，则XA控制对象为mysql_bin_log；

其他情况，使用tc_log_dummy，这种场景下就没有什么XA可言了，无需任何协调者来进行XA。

隐式XA

显式XA

XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口

两种XA事务方式

XA事务（内部分布式事物）

崩溃提交或回退

binlog 与事务日志一致性

prepare_commit_mutex锁以串行的方式来保证MySQL数据库上层二进制日志和Innodb存储引擎层的事务提交顺序一致，然后会导致组提交（group commit）特性无法生效

5.6前

引入队列机制保证Innodb commit顺序与binlog落盘顺序一致，并将事务分组，组内的binlog刷盘动作交给一个事务进行，实现组提交目的。在MySQL数据库上层进行提交时首先按顺序将其放入一个队列中，队列中的第一个事务称为leader，其他事务称为follow，leader控制着follow的行为。

BLGC（Binary Log Group Commit），并把事务提交过程分成三个阶段，Flush stage、Sync stage、Commit stage。

5.6

binlog与 redolog的顺序性

事务日志

刷新binlog_cache中的信息到磁盘由os决定。

每N次事务提交刷新binlog_cache中的信息到磁盘。

sync_binlog

它控制了重做日志（redo log）的写盘和落盘策略

事务安全

事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中

OS crash可能丢失

每次提交都仅写入到os buffer，然后是每秒调用fsync()将os buffer中的日志写入到log file on disk

mysqld 进程crash可能丢失

事务提交时不会将log buffer中日志写入到os buffer，而是每秒写入os buffer并调用fsync()写入到log file on disk中

innodb_flush_log_at_trx_commit

“双1”，是保证CrashSafe的根本。

InnoDB

MyISAM

InnoDB支持事务，MyISAM不支持

InnoDB支持外键，而MyISAM不支持

InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。

MyISAM是非聚集索引，也是使用B+Tree作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

InnoDB表必须有主键（用户没有指定的话会自己找或生产一个主键），而Myisam可以没有

InnoDB的B+树主键索引的叶子节点就是数据文件，辅助索引的叶子节点是主键的值；而MyISAM的B+树主键索引和辅助索引的叶子节点都是数据文件的地址指针。

因为InnoDB的事务特性

InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快（注意不能加有任何WHERE条件）；

InnoDB的行锁是实现在索引上的，而不是锁在物理行记录上。潜台词是，如果访问没有命中索引，也无法使用行锁，将要退化为表锁。

InnoDB支持表、行(默认)级锁，而MyISAM支持表级锁

引擎

from

Simple Nested-Loop Join

驱动表会根据关联字段的索引进行查找，当在索引上找到了符合的值，再回表进行查询，也就是只有当匹配到索引以后才会进行回表。至于驱动表的选择，MySQL优化器一般情况下是会选择记录数少的作为驱动表，但是当SQL特别复杂的时候不排除会出现错误选择。在索引嵌套链接的方式下，如果非驱动表的关联键是主键的话，这样来说性能就会非常的高，如果不是主键的话，关联起来如果返回的行数很多的话，效率就会特别的低，因为要多次的回表操作。先关联索引，然后根据二级索引的主键ID进行回表的操作。这样来说的话性能相对就会很差。

Index Nested-Loop Join

最先介绍的Simple Nested-Loop Join算法，而是会优先使用Block Nested-Loop Join的算法。Block Nested-Loop Join对比Simple Nested-Loop Join多了一个中间处理的过程，也就是join buffer，使用join buffer将驱动表的查询JOIN相关列都给缓冲到了JOIN BUFFER当中，然后批量与非驱动表进行比较，这也来实现的话，可以将多次比较合并到一次，降低了非驱动表的访问频率。也就是只需要访问一次S表。这样来说的话，就不会出现多次访问非驱动表的情况了，也只有这种情况下才会访问join buffer。在MySQL当中，我们可以通过参数join_buffer_size来设置join buffer的值，然后再进行操作。默认情况下join_buffer_size=256K，在查找的时候MySQL会将所有的需要的列缓存到join buffer当中，包括select的列，而不是仅仅只缓存关联列。在一个有N个JOIN关联的SQL当中会在执行时候分配N-1个join buffer。

Block Nested-Loop Join

Nested-Loop Join（嵌套循环链接），不像其他商业数据库可以支持哈希链接和合并连接

Sort Merge Join

Hash Join

join

where

order by

GROUP BY 条件字段需要符合最左前缀索引;

在使用GROUP BY 的同时，只能使用 MAX 和 MIN 这两个聚合函数;

如果引用到了该索引中 GROUP BY 条件之外的字段条件的时候，必须以常量形式存在;

使用松散（Loose）索引扫描实现 GROUP BY

使用紧凑(Tight)索引扫描实现 GROUP BY

使用临时表实现 GROUP BY

group by

having

　CTE的主要思想就先生成临时结果集，以方便后面的使用；与临时表不同的是这个结果集的作用域不是当前session而是当前语句，对！不是　　session级是语句级别的

MySQL8的新特性CTE

with

parttion by

并发死锁

Replace into

sql

指定表中的一列或者几列的组合的值在表中不能出现空值和重复值

主键约束

某一列或多个列不能有相同的两行或者两行以上的数据存在，和主键约束不同，唯一约束允许为NULL，只是只能有一行

唯一约束

非空约束

外键约束

约束

可以为NULL

唯一索引

索引

Sending data

Writing to net

state

show processlist

修改配置

用户量小

修改数据库连接池check连接时间

用户量大

8小时问题

wait_timeout

select * from information_schema.INNODB_TRX

查看事务

状态检查

•表字段避免null值出现，null值很难查询优化且占用额外的索引空间，推荐默认数字0代替null。

•尽量使用INT而非BIGINT，如果非负则加上UNSIGNED（这样数值容量会扩大一倍），当然能使用TINYINT、SMALLINT、MEDIUM_INT更好。

•使用枚举或整数代替字符串类型

•尽量使用TIMESTAMP而非DATETIME

•单表不要有太多字段，建议在20以内

•用整型来存IP

•应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃使用索引而进行全表扫描

•字符字段只建前缀索引

•字符字段最好不要做主键

•不用外键，由程序保证约束

•尽量不用UNIQUE，由程序保证约束

•使用多列索引时主意顺序和查询条件保持一致，同时删除不必要的单列索引

选择数据结构

当where条件和order by同时出现时，如果where中字段A使用了索引，而order by的字段是B，查看执行计划时，就会出现filesort文件排序

建立一个包含 WHERE 和 ORDER BY 条件的混合索引

优化

速度2倍

parttion

窗口函数

隐藏索引

降序索引

在复杂的查询中使用嵌入式表时，使用 CTE 使得查询语句更清晰。

通用表表达式(Common Table Expressions CTE)

InnoDB 现在支持表 DDL 的原子性

可靠性

8.X新特性

分页对sql要求高

流式查询

创建影子表、执行alert

拷贝数据、追平binlog

ghost方案

基于触发器

percona

percona方案

DDL锁表（ALERT语句）

生产问题处理

mysql

tidb

交叉连接，计算笛卡儿积

CROSS JOIN

内连接，返回满足条件的记录

INNER JOIN

返回左表所有行，右表不存在补NULL

LEFT

返回右表所有行，左边不存在补NULL

RIGHT

返回左表和右表的并集，不存在一边补NULL

FULL

OUTER JOIN

自连接，将表查询时候命名不同的别名。

SELF JOIN

JOIN

SQL

数据库

ActiveMQ

convertAndSend

当确认了所有的消费者都接收成功之后，才触发另一个convertSendAndReceive(…)，也就是才会接收下一条消息。RPC调用方式

convertSendAndReceive

高并发、持久化、支持集群、社区活跃、综合技术

client

basicAck

basicNack

多个队列或者单个消费

顺序性

幂等

网络延迟

为什么会重复

防止重复

confirm模式

一套绑定规则，用于告诉Exchange消息应该被存储到哪个Queue。

Binding

直连

DIRECT

广播

FANOUT

一个队列多个模糊匹配多个 routingkey

TOPIC

HEADERS

Exchange交换器

生产者在向Exchange发送消息时，需要指定一个Routing Key来设定该消息的路由规则。 Routing Key需要与Exchange类型及Binding Key联合使用才能生效

Routing Key

由于消费者读取消息之后可能会把消息放回（或者重传）到队列中（例如，处理失败的情况），这样就会导致消息的顺序无法保证。

当开发复杂的软件系统时，我们可能被诱导使用同一个消息平台去实现所有必须的消息用例。但是，从我的经验看，通常同时使用这两个消息平台能够带来更多的好处。例如，在一个事件驱动的架构系统中，我们可以使用RabbitMQ在服务之间发送命令，并且使用Kafka实现业务事件通知。原因是事件通知常常用于事件溯源，批量操作（ETL风格），或者审计目的，因此Kafka的消息留存能力就显得很有价值。相反，命令一般需要在消费者端做额外处理，并且处理可以失败，所以需要高级的容错处理能力。

virtual host

RabbitMQ

RocketMQ

Kafka（见hadoop分支）

amqp的事务机制

AMQP协议

解耦、异步、削峰

为什么用

系统可用性降低

系统复杂度提高

一致性问题

缺点

幂等性

重复消费

经验

_index

_type

_id

元数据

文档

索引里面最小的存储和查询单元，对于英文来说是一个单词，对于中文来说一般指分词后的一个词。

词条（Term）

或字典，是词条 Term 的集合。搜索引擎的通常索引单位是单词，单词词典是由文档集合中出现过的所有单词构成的字符串集合，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。

词典（Term Dictionary）

一个文档通常由多个词组成，倒排表记录的是某个词在哪些文档里出现过以及出现的位置。

倒排表（Post list）

所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件被称之为倒排文件，倒排文件是存储倒排索引的物理文件。

倒排文件（Inverted File）

Text 用于索引全文值的字段，例如电子邮件正文或产品说明。这些字段是被分词的，它们通过分词器传递，以在被索引之前将字符串转换为单个术语的列表。

分析过程允许 Elasticsearch 搜索单个单词中每个完整的文本字段。文本字段不用于排序，很少用于聚合。

Text

Keyword 用于索引结构化内容的字段，例如电子邮件地址，主机名，状态代码，邮政编码或标签。它们通常用于过滤，排序，和聚合。Keyword 字段只能按其确切值进行搜索。

Keyword

映射是用于定义 ES 对索引中字段的存储类型、分词方式和是否存储等信息，就像数据库中的 Schema ，描述了文档可能具有的字段或属性、每个字段的数据类型。

映射（Mapping）

基本概念

确切值

全文文本

将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。

由文档中出现的唯一单词列表以及每个单词在文档中的位置决定

每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合。例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。

倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。

倒排索引

must

should

must not

搜索

　shard = hash(document_id) % (num_of_primary_shards)

客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）

　当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；

　flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；

flush

当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem 　　Cache的过程就叫做refresh；

coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。[路由的算法是？]

写数据

lucene 就是一个 jar 包，里面包含了封装好的各种建立倒排索引的算法代码

全文检索引擎

lucene

更新和删除文档

磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。

在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

ES 内部是如何通过一个相同的设置 cluster.name 就能将不同的节点连接到同一个集群的？答案是 Zen Discovery。

发现机制

集群

存储原理

translog flush

refresh_interval

中文分词有特定的难点，不像英文，单词有自然的空格作为分隔，在中文句子中，不能简单地切分成一个个的字，而是需要分成有含义的词

支持自定义词库，支持热更新分词字典

Python 中最流行的分词系统，支持分词和词性标注

jieba

清华大学自然语言处理和社会人文计算实验室的一套中文分词器

THULAC

中文分词

Standard Analyzer - 默认分词器，按词切分，小写处理Simple Analyzer - 按照非字母切分（符号被过滤），小写处理Stop Analyzer - 小写处理，停用词过滤（the ，a，is）Whitespace Analyzer - 按照空格切分，不转小写Keyword Analyzer - 不分词，直接将输入当做输出Pattern Analyzer - 正则表达式，默认 \\W+Language - 提供了 30 多种常见语言的分词器Customer Analyzer - 自定义分词器

分词器

Elasticsearch

Logstash

Kibana

Pod可运行的原子

Pod

Name

namespace

Label

Label选择器

Ingress是K8S集群里工作在OSI网络参考模型下，第7层的应用，对外暴露的接口

Service只能进行L4流量调度，表现形式是ip+port

Ingress

连接master和node之间的桥梁、负责维护pod和容器的生命周期，监听到master下发的任务、创建、更新、停止pod等任务

kubelet

分布式K-V数据库

保存了整个集群的状态

raft算法

etcd

提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

apiserver

控制器的管理者、内部管理控制中心负责维护集群的状态，比如故障检测、自动扩展、滚动更新等

replication controller

node controller

deployment controller

ndpoint controller

controller manager

负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上

scheduler

Master节点组件（三节点）

负责镜像管理以及Pod和容器的真正运行（CRI）

docker

Container runtime

负责为Service提供cluster内部的服务发现和负载均衡

在node上实现pod网络代理

kube-proxy

worker Node

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）

管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）

接口层：kubectl命令行工具、客户端SDK以及集群联邦

Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等

Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

分层架构

给K8S里的容器绑host，所以我们必须做一个DNS，然后容器服从我们的DNS解析调度

（DNS服务）

签发证书环境

部署docker环境

harbor仓库是可以部署到本地的私有仓库，也就是你可以把镜像推到这个仓库，然后需要用的时候再下载下来，这样的好处是：1、下载速度快，用到的时候能马上下载下来2、不用担心镜像改动或者下架等。

部署harbor仓库

安装部署主控节点服务etcd

部署API-server集群

安装部署主控节点L4反代服务

安装部署controller-manager（节点控制器/调度器服务）

安装部署运算节点服务（kubelet）

安装部署运算节点服务（kube-proxy）

通过给每台宿主机分配一个子网的方式为容器提供虚拟网络（覆盖网络），该网络中的结点可以看作通过虚拟或逻辑链路而连接起来的

集群宿主机/容器之间必须是互通的

flannel之SNAT规则优化

安装部署flanneld

服务（应用）之间相互定位的过程

安装部署coredns（服务发现）

把用户的请求转发至指定Service资源的规则

当用户输入traefik.od.com时，被dns解析到10.4.7.10，而10则在11上，去找L7层服务，而反代配置的od.com.conf，则是将*.od.com无差别的抛给了ingress，ingress则通过noteselect找到pod

用户访问流程

K8S的服务暴露ingress

向企业展示度量信息和关键业务指标（KPI）现状的数据虚拟化工具

dashboard安装部署

安装部署Jenkins

从仪表板到各个Pipeline运行的查看分支和结果，使用可视编辑器修改Pipeline作为代码

借助BlueOcean插件回顾Jenkins流水线构建

安装蓝海

安装maven

K8S结合CI&CD持续交付和集中管理配置

K8S集群毁灭性测试

Promtheus监控k8s企业家应用

spinnaker

安装

kubeflow 机器学习（ML）工作流程

不支持GPU的共享和隔离

k8s device plugin

使用GPU

包管理工具

Helm

Rancher的核心竞争力在于其强大的多集群管理能力，提供了极其简便的K8s部署及管理能力。同时提供了集成开源监控、日志、Git CI的能力，虽然学习成本较高，但提供了一站式的解决方案，对运维更加友好。

提供Kubernetes、Mesos和Swarm三种调度工具的企业级分发版和商业技术支持的容器管理平台

rancher

KubeSphere定位是以应用为中心的容器平台，提供简单易用的操作界面，一定程度上降低了学习成本，同时集成了原生istio等功能，更加符合开发的使用习惯。

Kubesphere

主流的Kubernetes集群管理平台

Kubernetes

基于 K8S 的集成的模型部署方案，内置了很多通用的例如 tfserving、 sklearn server、mlflow server、triton这样的模型推理服务器(inference server)。除了这些还可以通过自己实现自定义的 inference server 提供一些额外的模型服务支持。

seldon 通过将你的模型部署为K8S上的微服务，来提供 HTTP/GRPC 接口给业务调用。

seldon

快速，一致地交付您的应用程序允许开发人员使用您提供的应用程序或服务的本地容器在标准化环境中工作，从而简化了开发的生命周期

响应式部署和扩展基于容器的平台，允许高度可移植的工作负载，可移植性和轻量级的特性，实时扩展或拆除应用程序和服务

在同一硬件上运行更多工作负载非常适合于高密度环境以及中小型部署，而您可以用更少的资源做更多的事情

可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化，三个核心概念：镜像、容器、仓库

每台虚拟机都需要有自己的操作系统，虚拟机一旦被开启，预分配给它的资源将全部被占用。每一台虚拟机包括应用，必要的二进制和库，以及一个完整的用户操作系统。

容器技术是和我们的宿主机共享硬件资源及操作系统，可以实现资源的动态分配。容器包含应用和其所有的依赖包，但是与其他容器共享内核。容器在宿主机操作系统中，在用户空间以分离的进程运行。

容器技术是实现操作系统虚拟化的一种途径，可以让您在资源受到隔离的进程中运行应用程序及其依赖关系。通过使用容器，我们可以轻松打包应用程序的代码、配置和依赖关系，将其变成容易使用的构建块，从而实现环境一致性、运营效率、开发人员生产力和版本控制等诸多目标。容器可以帮助保证应用程序快速、可靠、一致地部署，其间不受部署环境的影响。容器还赋予我们对资源更多的精细化控制能力，让我们的基础设施效率更高。通过下面这幅图我们可以很直观的反映出这两者的区别所在。

Cgroups 技术是用来制造约束的主要手段

Namespace 技术则是用来修改进程视图的主要方法

容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”。

容器是怎么隔离的

容器和虚拟机

Docker 镜像可以看作是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

Image(镜像)

Container(容器)

Repository(仓库)

Docker Client

Docker Server

Job

Docker daemon

docker run -p 容器外端口:容器内端口

映射端口

docker run -v 容器外目录:容器内目录

挂载数据卷

docker run -e 环境变量key:环境变量value

传递环境变量

docker inspect <容器id>

查看内容

通过指令编排镜像，帮你自动化的构建镜像

vi: 编辑文本FROM：从哪里导入USER：用什么用户起ENV：设置环境变量RUN：修改时区成中国时区'Asia/Shanghai'WORKDIR：指定工作目录，这里指定的是之前ENV指定的WWW 目录，即是/usr/share/nginx/htmlADD：添加指定的东西进去EXPOSE：暴露端口CMD：指令的首要目的在于为启动的容器指定默认要运行的程序，程序运行结束，容器也就结束

Bridge contauner（NAT）桥接式网络模式(默认)None(Close) container 封闭式网络模式，不为容器配置网络Host(open) container 开放式网络模式，和宿主机共享网络Container(join) container 联合挂载式网络模式，和其他容器共享网络

四种网络类型

dockerfile

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

docker attach

nsenter

sudo docker exec -it 775c7c9ee1e1 /bin/bash

exec

进入容器

docker logs --tail 1000 456dec08f55f

wsl --update

desktop

docker

Firecracker

微虚机

faas （function as a service）

serverless

Prometheus 再从这个网关里 Pull 指标

PushGateWay

Exporter

指标暴露

Pull 模型

Push 模型

指标抓取

内置的时序数据库

PromQL

存储和可视化

alertmanageer 基于 promql 来做系统的监控告警

监控告警

静态注册：静态的将服务的 IP 和抓取指标的端口号配置在 Prometheus yaml 文件的 scrape_configs 配置下

动态注册：动态注册就是在 Prometheus yaml 文件的 scrape_configs 配置下配置服务发现的地址和服务名，Prometheus 会去该地址，根据你提供的服务名动态发现实例列表，在 Prometheus 中，支持 consul，DNS，文件，K8s 等多种服务发现机制。

服务注册

配置更新

工作原理

Metric 指标

Prometheus

中间件与容器

单体架构

垂直架构

SOA代表面向服务的架构，将应用程序按照不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。这样将整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有组件通过交互来满足整体的业务需求。服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。这个阶段一般使用Web Service或者Dubbo来服务治理。

SOA服务化架构

1.微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以单独对外提供服务

2.微服务不再强调传统SOA架构里面比较重要的ESB企业服务总线

3.微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。

4.微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调HTTP Rest API的方法进行

5.微服务的切分粒度会更小。

SOA和微服务的区别

提出了一种单向依赖关系，从而从逻辑上形成一种向上的抽象系统

整洁架构 - Clean Architecture

洋葱架构是由多个同心层构成，它们相互连接，并朝向代表领域的核心

洋葱架构

Command指的是增加/更新数据的处理。

Query指的是查询数据的处理。它不会造成数据的变更。

CQRS，全称Command Query Responsibility Segregation。直译过来就是命令查询的职责分离。

command 系统完成数据更新的操作后，会通过「领域事件」的方式通知 query 系统。query 系统在接受到事件之后更新自己的数据源

领域模型与数据模型的边界划分的更清晰些

通过事件的形式通知 query 端系统，这就存在着一定的时间差

CQRS架构（命令查询的责任分离Command Query Responsibility Segregation）

外观模式 feignClient接口包含DTO对象独立模块

Facade

web层

controller

interface接口层

负责接收web层指令，对领域层的逻辑调用。应用层负责将逻辑流程进行组装。而不负责具体的逻辑处理可包含日志，消息，邮件等负责对外转换

可根据CQRS设计拆分cammand与query

ApplicationService

ApplicationServiceImpl

围绕model到外部DTO的转换类

assembler

application应用层

负责逻辑处理

实体逻辑较多的时候，向下拆分值对象

实例的构造逻辑拆分

Factory

实体

构造方法中进行参数验证

值对象

聚合根aggregate

同aggregate对应

规约模式提倡将验证和查询复用同一个逻辑单元

可规约模式（Specification）与CQRS冲突

仓库接口

简化可以没有

domain领域层

围绕model到外部DO的转换类

converter

仓库接口的实现

Repository

DO(data Object)

entity

xml

持久化层

mapper

Infrastructure基础设施

视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。

DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。

VO与DTO的区别

展示层与服务层之间的数据传输对象。

对于一个getUser方法来说，本质上它永远不应该返回用户的密码

DTO与DO的区别

两者在本质上的区别可能导致彼此并不一一对应，一个DTO可能对应多个DO，反之亦然，甚至两者存在多对多的关系。

DO具有一些不应该让展示层知道的数据

为什么不在服务层中直接返回DO呢

DTO

领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

关系表业务实体等也非一一对应

DO与PO的区别

持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系

领域对象

COLA 架构（整洁面向对象分层架构 (Clean Object-Oriented and Layered Architecture)）

明确区分应用程序，领域和基础结构三个层

依赖关系是从应用程序和基础结构再到领域

使用端口和适配器隔离它们的边界

六边形架构（端口和适配器）

导致制造大量的于数据表对应的类，这些类一般不会有行为，而描述业务逻辑的职责就会到很多service类上

Active Record 设计模式

Saga

可以用与语言无关的方式处理常见的客户端连接任务，如监视，日志记录，路由和安全性（如 TLS）。

外交官模式（Ambassador）

介于新应用和遗留应用之间，用于确保新应用的设计不受遗留应用的限制。

不共享相同语义的不同子系统之间实施外观或适配器层。此层转换一个子系统向另一个子系统发出的请求。使用反腐层（Anti-corruption layer）模式可确保应用程序的设计不受限于对外部子系统的依赖

反腐层（Anti-corruption layer）模式最先由 Eric Evans 在 Domain-Driven Design（域驱动的设计）中描述。

反腐层（Anti-corruption layer）

为不同类型的客户端（如桌面和移动设备）创建单独的后端服务。

BFF 后端服务前端（Backends for Frontends）

隔离了每个工作负载或服务的关键资源，如连接池、内存和 CPU。

轮船底下船舱一个个都是互相隔离的，这样一旦哪个舱壁出现漏水也影响不到其他的船舱

Hystrix线程池舱壁模式

舱壁模式（Bulkhead）

聚合服务与 BFF有些类似

将对多个单独微服务的请求聚合成单个请求

网关聚合（Gateway Aggregation）

网关卸载（Gateway Offloading）

网关路由（Gateway Routing）

例：给原有php服务封装一个边车注册在java注册中心

将应用程序的辅助组件部署为单独的容器或进程以提供隔离和封装。

边车模式（Sidecar）

通过逐步重构单体应用（而不是推到重来的方式），逐渐构建出一个新的应用程序。

绞杀者模式（Strangler）

敏捷性

小型专属团队

小型代码库

混合技术

错误隔离

可伸缩性

数据隔离

优点

复杂性

开发和测试

挑战

理论

微服务

Spring Cloud或者Dubbo的成熟框架，直接搞定服务注册，服务发现，负载均衡，熔断等基础功能。然后自己开发服务路由等高级功能，接入Zipkin等Apm做全链路监控，自己做加密、认证、授权。想办法搞定灰度方案，用Redis等实现限速、配额。诸如此类，一大堆的事情，都需要自己做

服务治理周期长：微服务治理框架与业务耦合，上线周期长，策略调整周期长。

产品能力弱：Spring Cloud缺乏平台化和产品化的能力，可视化能力弱。

进化

Istio 的出现为负责的微服务架构减轻了很多的负担，开发者不用关心服务调用的超时、重试、Rate Limit 的实现，服务之间的安全、授权也自动得到了保证。

为 Envoy 提供了服务发现，流量管理和智能路由（AB 测试、金丝雀发布等），以及错误处理（超时、重试、熔断）功能。用户通过 Pilot 的 API 管理网络相关的资源对象，Pilot 会根据用户的配置和服务的信息把网络流量管理变成 Envoy 能识别的格式分发到各个 Sidecar 代理中。

Pilot

为整个集群执行访问控制（哪些用户可以访问哪些服务）和 Policy 管理（Rate Limit，Quota 等），并且收集代理观察到的服务之间的流量统计数据。

Mixer

为服务之间提供认证和证书管理，可以让服务自动升级成 TLS 协议。

citadel

Envoy

L4-6

VirtualService

Ingress gateway

k8s Ingress

Istio（服务网格）

应用架构发展

沟通成本 = N（N-1）/ 2，N代表沟通的总人数沟通的问题会影响系统设计，软件架构最终会是沟通（组织）结构的映射。

第一定律，组织沟通方式会通过系统设计表达出来。

时间永远不够，人力永远不足，事情永远做不完，一件一件慢慢来来。系统经过再严格的测试，总是会有问题。完美测试不存在，测试无法100%覆盖并保证系统没有问题，系统需要测试但永远避免不了问题。

第二定律，时间再多一件事情也不可能做的完美，但总有时间做完一件事情。

什么样的系统对应什么样的组织，什么样的组织设计出什么样的系统。架构由组织关系决定，架构服务于技术，同样服务于组织中的人

第三定律，线性系统和线性组织架构间有潜在的异质同态特性。

系统越复杂，越需越多的人手，需要越多的沟通，需要更高的成本。分而治之，以结构化、模块化的方式架构和设计系统，以小团队形式进行开发和沟通。

第四定律，大的系统组织总是比小系统更倾向于分解。

康威定律

多进程或者线程去进行处理，但是这样会带来一些进程切换的开销，试想一个进程一个数据读了500ms，期间进程切换到它3次，但是CPU却什么都不能干，就这么切换走了

CPU的处理速度是要远远快于IO速度的，如果CPU为了IO操作（例如从Socket读取一段数据）而阻塞显然是不划算的

回调的方式

事件驱动

事件驱动架构是一种松耦合、分布式的驱动架构，收集到某应用产生的事件后实时对事件采取必要的处理后路由至下游系统，无需等待系统响应。

降低耦合：降低事件生产者和订阅者的耦合性。事件生产者只需关注事件的发生，无需关注事件如何处理以及被分发给哪些订阅者；任何一个环节出现故障，都不会影响其他业务正常运行；

异步执行：事件驱动架构适用于异步场景，即便是需求高峰期，收集各种来源的事件后保留在事件总线中，然后逐步分发传递事件，不会造成系统拥塞或资源过剩的情况；

可扩展性：事件驱动架构中路由和过滤能力支持划分服务，便于扩展和路由分发；

事件驱动架构（EDA）

如何增量地构建软件和如何部署软件

对部署而言，增量变更指业务功能的模块化和解耦水平，以及它们是如何映射到架构中去的。

对于开发者来说，变更范围相对更小

增量变更

该函数时一个目标函数，用于计算潜在的解决方案与既定目标的差距。在演化计算中，适应度函数决定一个算法是否在持续提升。

适应度函数驱动架构设计决策，并引导架构变更适应业务和技术环境的变化。

适应度函数

在高速变迁的业务、严谨的系统需求和架构特征间找到平衡

引导性变更

架构师确定了可审计性、数据、安全性、性能、合法性和伸缩性是该应用的关键架构特征。随着业务需求不断变化，每个架构特征都通过适应度函数来保护其完整性。

多个架构维度

演进式架构(Evolutionary Architecture)

为哪些用户提供什么服务

语境图

完成这个系统使用了哪些服务

容器图

每个服务是由哪些组件实现的

组件图

实现这个组件需要完成什么

类图

理论技巧

充血

贫血

几种类型

问题域

应该围绕业务功能而不是数据访问或消息传递等水平层来设计微服务

定义系统的大规模结构

战略

提供一组可用于创建域模型的设计模式

包括实体、聚合和领域服务。借助这些战术模式，可以设计低耦合高内聚的微服务。

战术（策略）

两个阶段

有助于避免组织边界或技术选择左右你的设计

哪些功能密切相关

哪些功能是业务的核心

哪些功能提供辅助服务

什么是依赖项关系图？

在填充关系图时，可以开始标识离散的子域

构建业务域并创建域模型

创建的系统的鸟瞰图

1.分析业务领域

2.定义领域的边界上下文

3.在边界上下文中，应用战术 DDD 模式以定义实体、聚合和域服务。

从域模型派生微服务

4.使用前一步骤的结果可以标识应用程序中的微服务

每个服务承担单一责任

服务之间不存在琐碎的调用。

每个服务足够小，独立工作的小团队即可构建它

两个或更多个服务的部署不应该存在相互依赖的关系

服务未紧密耦合，可独立演变

服务边界不会造成数据一致性或完整性方面的问题

验证设计

使用域分析对微服务建模

商品子域、用户子域、销售子域、订单子域

拆分子域

销售子域

核心域

日志子域

通用子域

除销售外子域：物流子域

支撑子域

eg.电商

领域拆分子域、核心域、通用子域、支撑子域

域建模

领域

服务应该封装领域知识，使这些领域知识对于客户端而言处于抽象状态。例如，客户端应该能够在无需知晓派遣算法或如何管理无人机群的情况下安排无人机。

销售子域中是商品

物流子域中是货品

eg.商品

限界上下文

聚合

工厂

仓储

eg. 订单支付成功

清晰表述事件的概念

事件总线（EventBus）

发布订阅模式

实现

最终一致性

领域事件

战术

策略性 DDD 提供一组可用于创建域模型的设计模式

领域驱动模型DDD

ER图建模

建模

构造函数设为私有的

类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例。

懒汉

线程安全

类加载时就初始化，浪费内存。

饿汉

synchronized

懒汉线程安全

安全且在多线程情况下能保持高性能。

B b = new B();

双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”，

双检锁/双重校验锁（DCL，即 double-checked locking）

登记式/静态内部类

枚举

单例

工厂方法模式

抽象工厂模式

建造者模式

创建型模式

实现被适配接口，拥有适配的引用

双向适配

适配器Adapter

装饰器模式

代理模式

外观模式

组合模式

享元模式

桥接模式

结构型模式

策略模式

模板方法模式

观察者模式

迭代子模式

责任链模式

命令模式

备忘录模式

状态模式

访问者模式

中介者模式

解释器模式

行为型模式

设计模式

服务降级

熔断

防止雪崩

缓存预热是指系统启动后，直接查询热点数据并缓存

缓存预热

先删除缓存，再更新数据库

推荐

先更新数据库，再删除缓存

有多个并发的请求更新数据，你并不能保证更新数据库的顺序和更新缓存的顺序一致，那就会出现数据库中和缓存中数据不一致的情况。所以一般来说考虑删除缓存。

为什么是删除缓存，而不是更新缓存

缓存更新

网络抖动可能导致写缓存响应时间很慢，引起数据库事务阻塞

不要把写缓存操作放在事务中

缓存技巧

缓存策略

存在性检测

BloomFilter

对不存在的用户，在缓存中保存一个空对象进行标记，防止相同 ID 再次访问 DB。不过有时这个方法并不能很好解决问题，可能导致缓存中存储大量无用数据。

缓存空值

缓存穿透是指：查询的数据在数据库中不存在，那么缓存中自然也不存在。所以，应用在缓存中查不到，则会去查询数据库。当这样的请求多了后，数据库的压力就会增大。

缓存穿透

使用快速失败的熔断策略，减少 DB 瞬间压力；

使用主从模式和集群模式来尽量保证缓存服务的高可用。

部署 Redis Cluster（主从+哨兵），以实现 Redis 的高可用，避免全盘崩溃

增加缓存系统可用性（事前）

采用多级缓存方案（事中）

避免被流量打死

限流、降级、熔断方案（事中）

缓存如果支持持久化，可以在恢复工作后恢复数据（事后）

针对多个热点 key 同时失效的问题，可以在缓存时使用固定时间加上一个小的随机数，避免大量热点 key 同一时刻失效。

缓存雪崩是指缓存不可用或者大量缓存由于超时时间相同在同一时间段失效，大量请求直接访问数据库，数据库压力过大导致系统雪崩。

缓存雪崩

锁住热点数据的 key，避免大量线程同时访问同一个 key

分布式锁

可以对部分数据采取失效前自动刷新的策略，而不是到期自动淘汰。淘汰其实也是为了数据的时效性，所以采用自动刷新也可以。

定时异步刷新

使用随机退避方式，失效时随机 sleep 一个很短的时间，再次查询，如果失败再执行更新。

缓存击穿是指，热点数据失效瞬间，大量请求直接访问数据库

缓存击穿

L1 进程缓存

L2 分布式缓存

L1 缓存

通过消息队列的发布、订阅机制，可以通知其他应用节点对进程内缓存进行更新。使用这种方案，即使消息队列服务挂了或不可靠，由于先执行了数据库更新，但进程内缓存过期，刷新缓存时，也能保证数据的最终一致性。

多级缓存更新

横切取模提高并发

分库分表

应用

单 Reactor 单线程模型

单 Reactor 多线程模型

mainReactor

subReactor

因为subReactor也会执行一些比较耗时的IO操作，例如消息的读写，使用多个线程去执行，则更加有利于发挥CPU的运算能力，减少IO等待时间。

多线程下的Reactor模式

主从 Reactor 多线程模型

负责响应IO

我们如何知道IO就绪这个事件，谁来充当这个中间人？Reactor模式的答案是：由一个不断等待和循环的单独进程（线程）来做这件事，它接受所有handler的注册，并负责先操作系统查询IO是否就绪，在就绪后就调用指定handler进行处理，这个角色的名字就叫做Reactor。

Reactor反应器线程

Handlers处理器

生产消费模式没有队列缓存IO事件

和生产消费之模式对比

发布订阅模式有多个观察者/订阅者

与观察者模式（发布订阅）对比

模式对比

Reactor

Reactor模式里，操作系统只负责通知IO就绪，具体的IO操作（例如读写）仍然是要在业务进程里阻塞的去做的，而Proactor模式则更进一步，由操作系统将IO操作执行好（例如读取，会将数据直接读到内存buffer中），而handler只负责处理自己的逻辑，真正做到了IO与程序处理异步执行。所以我们一般又说Reactor是同步IO，Proactor是异步IO。

Proactor模式

高并发

TCP 层之上的微服务层

代理变成了分布式的，它常驻在了应用的身边（最常见的就是 Kubernetes Sidecar 模式，每一个应用的 Pod 中都运行着一个代理，负责流量相关的事情）。

Service Mesh

虽然有主从节点之分，但是在恢复模式选举过程中仍可对外提供服务

CAP

RPC

一阶段记录undo-log并提交分支事务。

利用快照回滚

核心

AT 则是应用/驱动层实现的二阶段提交

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

二阶段：提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。

两阶段提交协议的演变

支持本地 ACID 事务的关系型数据库

seata 使用全局锁避免脏写

XA一阶段不提交分支事务，锁资源

利用数据库回滚

XA 是数据库层面实现的二阶段提交

分布式强一致性的解决方案，但性能低. 以为锁时间长

XA模式

业务无侵入

Try 预留资源（如：库存服务的预占库存，支付服务的冻结部分账户余额）

Confirm 如果所有的事务参与者try 操作都执行成功了，就会调用所有事务参与者的confirm操作，确认资源。（如：库存服务的减库存，支付服务的扣减账户余额）

Cancel 如果有事务参与者在try阶段执行失败，就调用所有已执行try阶段成功的参与方的cancel方法，释放try阶段占用的资源（如：库存服务的释放预占库存，支付服务的释放冻结的账户余额）

TCC（Try Confirm Cancel）是应用层的两阶段提交，所以对代码的侵入性强，其核心思想是：针对每个操作，都要实现对应的确认和补偿操作，也就是业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作

如账户操作：下账确认取消下账操作

高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景

TCC

长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统（第一阶段就操作DB，会存在脏读问题）

confirm 直接执行资源操作，（如：库存服务的减库存，支付服务的扣减账户余额）

cancel 回滚资源操作，这个地方的cancel与TCC中的cancel不一样，准确点说应该是回滚，（如：回滚库存服务的减库存操作，回滚支付服务的扣减账户余额的操作）。当然是业务层面实现的回滚，而非数据库事务层面的回滚

过程

异步更新的场景，并且对数据实时性要求不高的地方

消息发送是一个网络通信的过程，发送消息的过程就有可能出现发送失败、或者超时的情况。超时有可能发送成功了，有可能发送失败了，消息的发送方是无法确定的，所以此时消息发送方无论是提交事务还是回滚事务，都有可能不一致性出现。

事务消息和普通消息的区别在于事务消息发送成功后，处于 prepared 状态，不能被订阅者消费，等到事务消息的状态更改为可消费状态后，下游订阅者才可以监听到次消息。

解决问题

1.事务发起者预先发送一个事务消息

2.MQ 系统收到事务消息后，将消息持久化，消息的状态是“待发送”，并给发送者一个 ACK 消息

3.事务发起者如果没有收到 ACK 消息，则取消本地事务的执行；如果收到了 ACK 消息，则执行本地事务，并给 MQ 系统再发送一个消息，通知本地事务的执行情况

4.MQ 系统收到消息通知后，根据本地事务的执行情况更改事务消息的状态，如果成功执行，则将消息更改为“可消费”并择机下发给订阅者；如果事务执行失败，则删除该事务消息

5.本地事务执行完毕后，发给 MQ 的通知消息有可能丢失了。所以支持事务消息的 MQ 系统有一个定时扫描逻辑，扫描出状态仍然是“待发送”状态的消息，并向消息的发送方发起询问，询问这条事务消息的最终状态如何并根据结果更新事务消息的状态。因此事务的发起方需要给 MQ 系统提供一个事务消息状态查询接口

6.如果事务消息的状态是“可发送”，则 MQ 系统向下游参与者推送消息，推送失败会不停重试

7.下游参与者收到消息后，执行本地事务，本地事务如果执行成功，则给 MQ 系统发送 ACK 消息；如果执行失败，则不发送 ACK 消息，MQ 系统会持续推送给消息。

处理流程

解决的是本地事务的执行和发消息这两个动作满足事务的约束

在一次事务中需要发送多个消息的情况，保证多个消息之间的事务约束，即多条消息要么都发送成功，要么都发送失败

Kafka

Kafka 的事务基本上是配合其幂等机制来实现 Exactly Once 语义的，所以说 Kafka 的事务消息不是我们想的那种事务消息 RocketMQ 的才是。

中间件

事务消息

业务侵入

本地消息表

分布式事务

主观下线（Subjectively Down，简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。

客观下线（Objectively Down，简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

下线

分布式

一个类应该只有一个发生变化的原因

此原则的核心就是解耦和增强内聚性。

单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

产生原因：（职责扩散）因为某种原因，某一职责被分化为颗粒度更细的多个职责了。

软件实体的行为是可扩展的，当需求变更的时候，可以对模块进行扩展，使其满足需求变更的要求

对扩展是开放的

软件实体进行扩展的时候，不需要改动当前的软件实体

对修改是关闭的

开闭原则（Open Closed Principle，OCP）

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

子类中可以增加自己特有的方法

当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。

当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

任何基类可以出现的地方，子类一定可以出现。能保证子类完美替换基类

LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

里氏代换原则（Liskov Substitution Principle，LSP）

客户端不应该强迫依赖它不需要的接口

建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少

依赖几个专用的接口要比依赖一个综合的接口更灵活

接口隔离原则（Interface Segregation Principle，ISP）

从客户端代码调用框架代码，变成框架调用客户端代码。框架来定义接口，客户端来实现。

高层模块不依赖低层模块

抽象不应该依赖细节；细节应该依赖抽象。

TDD开发模式

依赖倒置原则的核心思想是面向接口编程。

依赖倒置原则更多是说，我们应该面向接口编程；好莱坞原则是说，低层组件将自己挂钩到系统上，由系统来主动调用。

“好莱坞原则”（Hollywood principle）

tomcat处理web请求的流程图，请求会经过 connector，coyote，engine，host，context，Servlet，层层传递最终传递到我们的应用程序里面来

实践

依赖倒转原则（Dependency Inversion Principle，DIP）

面向对象五个基本原则（SOLID）

一个软件实体应当尽可能少的与其他实体发生相互作用

门面模式和调停者模式（中介者模式）实际上就是迪米特法则的应用。

第六原则-迪米特原则

尽量使用合成/聚合达到复用，尽量少用继承。原则：一个类中有另一个类的对象。

第七原则 - 合成 / 聚合复用原则（Composite/Aggregate Reuse Principle，CARP）

"表达式"（expression）是一个单纯的运算过程，总是有返回值；"语句"（statement）是执行某种操作，没有返回值。函数式编程要求，只使用表达式，不使用语句。也就是说，每一步都是单纯的运算，而且都有返回值。

我要做什么

声明式

怎么做

命令式

与命令式编程区别

声明式编程

惰性执行

它要求你所有的数据都是不可变的，这意味着如果你想修改一个对象，那你应该创建一个新的对象用来修改，而不是修改已有的对象

数据不可变

合理性

可测试性

可移植性

并行代码

纯函数

无状态、数据不可变更

将电脑运算视为函数，强调函数计算比指令执行更重要

代码优雅适合并发

这意味着可以在编程语言中很方便地表达静态或动态的数据流，而相关的计算模型会自动将变化的值通过数据流进行传播。

把生产者消费者模式，使用简单的API表示出来，并自动处理背压（backpressure）问题。

变化传递、基于数据流、变化传播

响应式编程是一种面向数据流和变化传播的编程范式

基于发布/订阅模式的数据处理规范提供非阻塞背压的异步流处理标准的倡议

接口规范

如果生产者发出的信息比消费者能够处理消息最大量还要多，消费者可能会被迫一直在抓消息，耗费越来越多的资源，埋下潜在的崩溃风险。为了防止这一点，需要有一种机制使消费者可以通知生产者，降低消息的生成速度。生产者可以采用多种策略来实现这一要求，这种机制称为背压。

背压（back pressure）

Reactive Stream(响应式流/反应流)

链式代码

使用Netty，能够构建响应式编程的基础，加上类似lambda表达式这样的书写风格，能够完成类似WebFlux这样的响应式框架

响应式编程（Reactive Programming，RP）

编程范式

银弹

瀑布

原型

软件工程

授权框架

OAuth2

将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

JWT

localStorage 或者 cookie

服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。

Token

session 是另一种记录服务器和客户端会话状态的机制

session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

Session

安全设计

秒杀

单点

画布

常用案列

应用架构

批处理层（Batch Layer）

速度处理层（Speed Layer）

服务层（Serving Layer）

Lambda

不适用于批处理和流处理代码逻辑不一致的场景

Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用同一套代码

流式重新处理历史的吞吐能力会低于批处理

缺陷

Kappa

数据应用层

ADS

数据服务层：Data Warehouse Service，DWS；

该层是基于DWM上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

DWS

数据中间层：Data Warehouse Middle，DWM

对通用的核心维度进行聚合操作，算出相应的统计指标

DWM

数据细节层：data warehouse details，DWD

该层是业务层和数据仓库的隔离层，保持和ODS层一样的数据颗粒度；主要是对ODS数据层做一些数据的清洗和规范化的操作，比如去除空数据、脏数据、离群值等。

该层通常会才采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联。

DWD

数据运营层：Operation Data Store 数据准备区，也称为贴源层

业务库：sqoop定时抽取数据；实时方面考虑使用canal监听mysql的binlog日志，实时接入即可

埋点日志：日志一般是以文件的形式保存，可以选择使用flume来定时同步；可以使用spark streaming或者Flink、Kafka来实时接入

消息队列：来自ActiveMQ、Kafka的数据等

数据来源

ODS是后面数据仓库层的准备区

为DWD层提供原始数据

减少对业务系统的影响

主要功能

考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可

ODS

分层

Kimball维度建模

IBM-FSDM主题域模型划分

NCR FS-LDM主题域模型划分

雪花模型

星型模型

ADL数据应用层

主要职责是建设宽表模型、汇总表模型，比如商家宽表、商家时段汇总表等。主要作用是支撑数据分析查询以及支持应用所需数据。

MDL数据集市层

主要职责是划分分析主题、建设各个主题的基础指标，比如商家交易、用户活动等多个主题。这样针对同一个分析对象统一了指标口径，同时避免重复计算。

CDL层数据组件层

主要职责是：业务主题的划分、数据规范化，比如商家、交易、用户等多个主题。这一层主要起到缓冲的作用，屏蔽底层影响，尽量还原业务，统一标准。

IDL层数据集成层

主要职责是接入数据源，并做多数据源的整合

ODS层

美团数据建模规范

事实表是指存储有事实记录的表，比如系统日志、销售记录等。事实表的记录在不断地增长，比如电商的商品订单表，就是类似的情况，所以事实表的体积通常是远大于其他表。

事实表 Fact Table

一般是配置表，比如枚举字段对应的中文含义，或者日期维表等；

低基数维度数据

高基数维度数据

维表层Dimension

数据质量管理

记录和管理数据仓库中数据的含义、格式、血缘关系等元数据的系统

元数据中心

数仓建模

Spark Streaming内置的Kafka Direct API (KafkaUtils.createDirectStream)，实现精确Exactly-Once一致性

可靠的数据源端(数据可重复读取、不丢失)

基于Spark Streaming的Receiver模式，在Executor持续拉取kafka数据流kafka数据存储到Executor内存和WAL(预写日志)中WAL(预先日志)写入完成后，自动更新offset至zookeeper上

Spark Streaming 基于Receiver的Kafka高级API，实现At least Once语义

(1) 高级消费者API需要启用Receiver线程消费Kafka数据，相较于第一种增加了开销，且无法直接实现并行读取，需要使用多个Kafka Dtstream 消费同一组然后union。(2) 高级消费API在Executor本地和WAL存储两份数据<开启WAL不丢失机制>，而第一种Direct API仅在Executor中存储数据<offset存储到checkpoint中>(3) 基于Kafka Direct API的方式，因Spark集成Kafka API直接管理offset，同时依托于Kafka自身特性，实现了Exactly-Once一致性语义。因此在生产中建议使用此种方式！！

可靠的消费端(Spark内部精确一次消费)

基于RDD内存模型，启用多种一致性策略，实现Exactly-Once一致性。

序代码去重如果实时流进入到Spark消费端已经存在重复数据，可以编写Spark程序代码进行去重操作，实现Exactly-Once一致性。(1) 内存去重。采用Hashset等数据结构，读取数据中类似主键等唯一性标识字段，在内存中存储并进行去重(2) 使用Redis Key去重。借助Redis的Hset等特殊数据类型，自动完成Key去重。(3) DataFrame/SQL场景，使用group by/ over() window开窗等SQL函数去重(4) 利用groupByKey等聚合算子去重(5) 其他方法。。

幂等写入

事务写入

输出端

可靠的输出端(幂等性、事务)

Apache Spark的Exactly-Once机制

Apache Flink的Exactly-Once机制

分布式系统天生具有跨网络、多节点、高并发、高可用等特性，难免会出现节点异常、线程死亡、网络传输失败、并发阻塞等非可控情况，从而导致数据丢失、重复发送、多次处理等异常接踵而至。如何保持系统高效运行且数据仅被精确处理一次是很大的挑战。

当任意条数据流转到某分布式系统中，如果系统在整个处理过程中对该任意条数据都仅精确处理一次，且处理结果正确，则被认为该系统满足Exactly-Once一致性

正好一次exactly-once

至少一次at-least-once

最多一次at-most-once

Exactly-Once一致性语义

在自然环境中，数据的产生原本就是流式的。

低延迟、低容错

流计算系统在计算过程中，或是出现故障恢复计算后，流系统的内部状态和外部输出的数据应该处在一致的状态

定义

常见的非确定性计算包括使用了随机数、使用系统时间、字符串拼接等

流计算中的确定性指的是，给定相同的一组数据，重复运行多次或者打乱数据进入引擎的顺序，计算完成后将会输出相同的结果，否则就是非确定性计算。

确定性/非确定性计算

一致性

无重叠

滚动窗口

设置滑动步长、有重叠

滑动窗口

会话窗口

窗口

流处理

高延迟、高容错

批处理

流与批处理

大数据架构

由高效的召回规则、算法或简单的模型组成，这让推荐系统能快速从海量的候选集中召回用户可能感兴趣的物品

单策略召回

多路召回

基于Embedding召回

召回层

精排层，是利用排序模型对初筛的候选集进行精排序

排序层

推荐系统

Transformer架构

encoder-decoder架构

建模相关平台（AI 中台）

模型执行平台（模型引擎）

人工智能架构

决策引擎可以用于包括金融风控、内容风控、推荐营销、物联网监控等各个领域凡是涉及到使用规则或模型来做业务决策的场景都可以考虑使用决策引擎来实现

硬编码问题。规则调整要涉及到开发、测试、上线的流程，调整周期长。且规则逻辑维护到了代码中，难以传承，也容易造成生产中跑的规则和业务预想的规则有差异。当有大量规则或决策场景接入时，工作量巨大难以维护。

规则清单模式

复杂决策流模式

两个模式

决策引擎在规则引擎的基础上实现了更多元的决策方式，并引入了流程编排过程

Lua、Groovy、Javascript

领域特定语言 Domain Specific Language（DSL)

嵌入式脚本

drools

qlexpress

URule

规则引擎

fico

益博睿

决策引擎

govaluate（Golang）

SpEL（Java）

QLExpress（Java）

字符串表达式的执行

将规则和表达式以不同的方式组合起来，就构成了规则集、决策树、决策表等不同的组合形式（决策类型）。

决策表

决策矩阵（交叉决策表）

决策树

评分卡

决策类型

决策流

规则组合

规则引擎（专家系统、决策引擎）

架构设计

HA集群

环境搭建

Maps input key/value pairs to a set of intermediate key/value pairs. 将输入键/值对映射到一组中间键/值对。

The Hadoop Map-Reduce framework spawns one map task for each {@link InputSplit} generated by the {@link InputFormat} for the job. Hadoop Map-Reduce框架为作业的InputFormat生成的每个InputSplit生成一个map作业

Comparator

Mapper.java

combiner

hadoop-mapreduce-client-core

hadoop-mapreduce-client

hadoop-mapreduce-project

fs.trash.interval 垃圾箱清理文件间隔

dfs.namenode.handle.count hadoop启动任务线程数

mapreduce.tasktraker.http.threads map和reduce之间通过http传输数据传输的并行线程数

core-site.xml

配置优化

系统优化

combiner的个数尽量同reduce相同，数据类型保持一直，可以减少拆包和封包进度

代码优化

namenode挂了。先分析宕机后的损失，宕机后直接导致client无法访问，内存中的元数据丢失，但是硬盘中的元数据应该还存在，如果只是节点挂了，重启即可，如果是机器挂了，重启机器后看节点是否能重启，不能重启就要找到原因修复了。但是最终的解决方案应该是在设计集群的初期就考虑到这个问题，做namenode的HA。

namenode节点

Datanode宕机了后，如果是短暂的宕机，可以实现写好脚本监控，将它启动起来。如果是长时间宕机了，那么datanode上的数据应该已经被备份到其他机器了，

datanode节点

每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地

sn的主要职责是执行checkpoint操作

secondarynamenode

HDFS协议（RPC协议、流式接口协议:HTTP和TCP）

核心模块

HDFS

第一阶段是把输入文件按照一定的标准分片(InputSplit)，每个输入片的大小是固定的。默认情况下，输入片(InputSplit)的大小与数据块(Block)的大小是相同的。如果数据块(Block)的大小是默认值64MB，输入文件有两个，一个是32MB，一个是72MB。那么小的文件是一个输入片，大文件会分为两个数据块，那么是两个输入片。一共产生三个输入片。每一个输入片由一个Mapper进程处理。这里的三个输入片，会有三个Mapper进程处理。

第二阶段是对输入片中的记录按照一定的规则解析成键值对。有个默认规则是把每一行文本内容解析成键值对。“键”是每一行的起始位置(单位是字节)，“值”是本行的文本内容。

第三阶段是调用Mapper类中的map方法。第二阶段中解析出来的每一个键值对，调用一次map方法。如果有1000个键值对，就会调用1000次map方法。每一次调用map方法会输出零个或者多个键值对。

第四阶段是按照一定的规则对第三阶段输出的键值对进行分区。分区是基于键进行的。比如我们的键表示省份(如北京、上海、山东等)，那么就可以按照不同省份进行分区，同一个省份的键值对划分到一个区中。默认是只有一个区。分区的数量就是Reducer任务运行的数量。默认只有一个Reducer任务。

第六阶段Reducer任务过程

决定Mapper的数量HDFS中数据的存储是以块的形式存储的，数据块的切分是物理切分，而split是在Block的基础上进行的逻辑切分。每一个split对应着一个Mapper进程。每个Split中的每条记录调用一次map方法。一个文件被切分成多少个split就有多少个Mapper进程。

Mapper任务过程

每个Reducer任务是一个java进程。Reducer任务接收Mapper任务的输出，归约处理后写入到HDFS中，可以分为如下图所示的几个阶段。

第一阶段是Reducer任务会主动从Mapper任务复制其输出的键值对，Mapper任务可能会有很多，因此Reducer会复制多个Mapper的输出。

第二阶段是把复制到Reducer本地数据，全部进行合并，即把分散的数据合并成一个大的数据，再对合并后的数据排序。

第三阶段是对排序后的键值对调用reduce方法，键相等的键值对调用一次reduce方法，每次调用会产生零个或者多个键值对，最后把这些输出的键值对写入到HDFS文件中。

决定Reducer的数量如： 10个key可以有1个reducer，但是这个reducer只能一次处理一个key，也就是说处理10次 10个key可以有大于10个reducer ，只不过有的reduce不进行key的处理。 10个key有10个reducer，这是最合理的分配，达到并行计算。相同的key如何识别到指定的reducer进行计算呢？对输出的key、value进行分区。总结：Mapper阶段是并行读取处理的它的数量是由切片的数量决定的；Reducer阶段可以不并行，他的数量的是通过key进行规划，由人来决定。

Reducer任务过程

将maptask输出的处理结果数据，分发给reducetask，并在分发的过程中，对数据按key进行了分区和排序；

shuffle

mapreduce

资源调度

ResourceManager

ApplicationMaster

NodeManager

container

yarn

datanode首次加入cluster时候版本号不一致

问题处理

hadooop

hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。

用户接口/界面

元存储

HiveQL处理引擎

执行引擎

HDFS 或 HBASE

内部表

外部表

分区表

分桶表

视图

hive

Row Key(行键)

Column Family(列族)

Column Qualifier(列限定符)

Column(列)

Cell

核心概念

HMaster

Region Servers

集群架构

Key-Value存储会覆盖

唯一原则

HBase的Rowkey是按照ASCII有序设计的

排序原则

Reverse反转

Salt加盐

Mod

Region热点问题

散列原则

Rowkey是一个二进制，Rowkey的长度被很多开发者建议说设计在10~100个字节，建议是越短越好

长度原则

Row Key 设计原则

hbase

分布式的，开放源码的分布式应用程序协调服务文件系统+监听通知机制

这个属性表示心跳时间间隔，Leader用来监听Follower的心跳，一旦挂掉一半以上Follower，会通过Zab(消息原子广播)协议使集群所有个体状态转变为Looking（等待选举新任Leader）。此属性除了用来监听之外，还对后面的同步时间和初始化时间有影响，系统默认为2000毫秒。

tickTime

集群中的follower服务器与Leader服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），系统默认为10。

initLimit

集群中Follower服务器跟Leader服务器之间的请求和答应最多能容忍的心跳数（tickTime的数量），系统默认为5。

syncLimit

此属性表示一个路径，用来存放数据快照（即zookeeper目录）、myid文件和日志文件夹，系统默认为/tmp/data，根据自己zk安装路径进行修改并创建data目录。

dataDir

zk客户端端口号，默认2181。

clientPort

用来存放zk写日志。

dataLogDir

此处是关于zk集群的配置，index代表自定义的各服务器序号（对应写在各自机器的myid中），IP即各服务器IP，A表示集群服务器之间通讯组件的端口，B表示选举组件的端口。如果配成集群，则zk状态（mode）为leader或follower；如果只配一个单机，mode为standalone。

server.index=IP:A:B

zoo.cfg配置

安装部署

leader

follower

observer

各节点角色

永久节点

临时节点

有序节点

ZNODE

Permissions

Schemes

ACL权限

curator

Watcher

崩溃恢复

消息广播

ZAB协议

paxos算法

发布订阅

master选举

核心原理

zookeeper

topic通过文件存储，partition是目录

分区在存储层面可以看作一个可追加的日志（Log）文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量（offset）。

消息是顺序append log方式存储

消息冗余多台beoker存储，多台机器就叫一个replica集合

replica集合中，需要选出1个leader，剩下的是follower。也就是master/slave。

消息会存放一个星期，才会被删除。并且在一个partion里面，消息是按序号递增的顺序存放的，因此消费者可以回退到某一个历史的offset，进行重新消费。

offset 是消息在分区中的唯一标识，Kafka 通过它来保证消息在分区内的顺序性，不过 offset 并不跨越分区，也就是说，Kafka 保证的是分区有序性而不是主题有序性。

offset回退机制

一个topic只用一个partition，但这样很显然限制了灵活性。

所有发送的消息，用同一个key，这样同样的key会落在一个partition里面。

轮询分区策略

随机分区策略

之所以要分成多个partition，是为了提高并发度，多个partition并行的进行发送/消费，但这却没有办法保证消息的顺序问题

操作系统本身是有page cache的。即使我们用无缓冲的io，消息也不会立即落到磁盘上，而是在操作系统的page cache里面。操作系统会控制page cache里面的内容，什么时候写回到磁盘。在应用层，对应的就是fsync函数。我们可以指定每条消息都调用一次fsync存盘，但这会较低性能，也增大了磁盘IO。也可以让操作系统去控制存盘。

消息刷盘

Topics And Partition(主题与分区)

消费者去broker pull消息

同步发送异步发送

RecordAccimator

Metadata

Producer 端压缩

Broker 端保持

Consumer 端解压缩

生产者压缩算法

Producer 发送消息的过程如下图所示，需要经过拦截器，序列化器和分区器，最终由累加器批量发送至 Broker。

配置客户端，创建消费者

订阅主题

拉去消息并消费

提交消费位移

关闭消费者实例

Kafka Consumer 线程不安全，单线程消费，多线程处理

Kafka 有消费组的概念，每个消费者只能消费所分配到的分区的消息，每一个分区只能被一个消费组中的一个消费者所消费，所以同一个消费组中消费者的数量如果超过了分区的数量，将会出现有些消费者分配不到消费的分区

Producers And Consumers(生产者与消费者)

组成员发生变更（新 consumer 加入组、已有 consumer 主动离开组或已有 consumer 崩溃了——这两者的区别后面会谈到）

订阅主题数发生变更

订阅主题的分区数发生变更

rebalance 本质上是一种协议，规定了一个 consumer group 下的所有 consumer 如何达成一致来分配订阅 topic 的每个分区。比如某个 group 下有 20 个 consumer，它订阅了一个具有 100 个分区的 topic。正常情况下，Kafka 平均会为每个 consumer 分配 5 个分区。这个分配的过程就叫 rebalance。

Kafka 默认提供了两种分配策略：Range 和 Round-Robin。当然 Kafka 采用了可插拔式的分配策略，你可以创建自己的分配器以实现不同的分配策略。

rebalance

broke依赖zk，生产消费者并不依赖

Brokers And Clusters

Messages And Batches(消息与批次)

消息不会重复存储

消息不会重复消费

不会丢失存储

不会丢失消费

Exactly Once

高水位值 (High watermark)。这是控制消费者可读取消息范围的重要字段。一个普通消费者只能“看到”Leader 副本上介于 Log Start Offset 和 HW（不含）之间的所有消息。水位以上的消息是对消费者不可见的。

异步刷盘

页缓存到file时系统挂掉

设置 unclean.leader.election.enable = false。这是 Broker 端的参数，它控制的是哪些 Broker 有资格竞选分区的 Leader。如果一个 Broker 落后原先的 Leader 太多，那么它一旦成为新的 Leader，必然会造成消息的丢失。故一般都要将该参数设置成 false，即不允许这种情况的发生。

设置 replication.factor >= 3。这也是 Broker 端的参数。其实这里想表述的是，最好将消息多保存几份，毕竟目前防止消息丢失的主要机制就是冗余。

设置 min.insync.replicas > 1。这依然是 Broker 端参数，控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。在实际环境中千万不要使用默认值 1。

确保 replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。我们不仅要改善消息的持久性，防止数据丢失，还要在不降低可用性的基础上完成。推荐设置成 replication.factor = min.insync.replicas +1

broker

设置 acks = all。acks 是 Producer 的一个参数，代表了你对“已提交”消息的定义。如果设置成 all，则表明所有副本 Broker 都要接收到消息，该消息才算是“已提交”。这是最高等级的“已提交”定义。

异步发送消息-丢失消息

Producer

自动提交

确保消息消费完成再提交。Consumer 端有个参数 enable.auto.commit，最好把它设置成 false，并采用手动提交位移的方式。就像前面说的，这对于单 Consumer 多线程处理的场景而言是至关重要的。

Consumer Group：一个消费者组可以包含一个或多个消费者。使用多分区 + 多消费者方式可以极大提高数据下游的处理速度，同一消费组中的消费者不会重复消费消息，同样的，不同消费组中的消费者消息消息时互不影响。Kafka 就是通过消费组的方式来实现消息 P2P 模式和广播模式。

Consumer

消息丢失

TransactionalID

Kafka 生产者在同一个事务内提交到多个分区的消息，要么同时成功，要么同时失败。

epoch 机制

找到 Kafka 集群负责管理当前事务的事务协调者（ TransactionCoordinator ），向其申请 ProducerID 资源

initTransactions 方法初始化事务上下文

Kafka 事务机制

PID：每个新的 Producer 在初始化的时候会被分配一个唯一的 PID，这个PID 对用户完全是透明的。

Producer ID（即PID）

Sequence Number

enable.idempotence

数据的一致性

AR：Assigned Replicas。AR 是主题被创建后，分区创建时被分配的副本集合，副本个数由副本因子决定。

在 AR 中的副本可能不在 ISR 中，但 Leader 副本天然就包含在 ISR 中。关于 ISR，还有一个常见的面试题目是如何判断副本是否应该属于 ISR。目前的判断依据是：Follower 副本的 LEO 落后 Leader LEO 的时间，是否超过了 Broker 端参数 replica.lag.time.max.ms 值。如果超过了，副本就会被从 ISR 中移除。

ISR：In-Sync Replicas。Kafka 中特别重要的概念，指代的是 AR 中那些与 Leader 保持同步的副本集合。

Kafka 在所有分配的副本 (AR) 中维护一个可用的副本列表 (ISR)，Producer 向 Broker 发送消息时会根据ack配置来确定需要等待几个副本已经同步了消息才相应成功，Broker 内部会ReplicaManager服务来管理 flower 与 leader 之间的数据同步。

ISR数据同步

一方面，由于不同 Partition 可位于不同机器，因此可以充分利用集群优势，实现机器间的并行处理。另一方面，由于 Partition 在物理上对应一个文件夹，即使多个 Partition 位于同一个节点，也可通过配置让同一节点上的不同 Partition 置于不同的 disk drive 上，从而实现磁盘间的并行处理，充分发挥多磁盘的优势。

Partition 并发

400M/s

使用 Filesystem Cache PageCache 缓存来减少与磁盘的交互

使用 Zero-copy 和 MMAP 来减少内存交换

使用批量，以流的方式进行交互，直顶网卡上限

使用拉模式进行消息的获取消费，与消费端处理能力相符

顺序读写

性能

kafka

单分区

时间分区

维度分筒

复合分区

FrontEnd DorisDB的前端节点，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。

BackEnd DorisDB的后端节点，负责数据存储，计算执行，以及compaction，副本管理等工作。

DorisDB中和外部HDFS/对象存储等外部数据对接的中转服务，辅助提供导入导出功能。

Broker

数据被水平划分为若干个数据分片（Tablet，也称作数据分桶）。每个 Tablet 包含若干数据行。各个 Tablet 之间的数据没有交集，并且在物理上是独立存储的。

Tablet

DorisDB 管理工具，提供DorisDB集群管理、在线查询、故障查询、监控报警的可视化工具。

DorisManager

部署

多个 Tablet 在逻辑上归属于不同的分区（Partition）。一个 Tablet 只属于一个 Partition。而一个 Partition 包含若干个 Tablet。因为 Tablet 在物理上是独立存储的，所以可以视为 Partition 在物理上也是独立。Tablet 是数据移动、复制等操作的最小物理存储单元。

Partition

OLAP_SCAN_NODE

OlapScanner

SegmentIterator

对一个tablet数据读取操作整体的封装

负责了对一个Rowset的读取

RowsetReader

RowwiseIterator

提供了一个Rowset中所有Segment的统一访问的Iterator功能

对应了一个Segment的数据读取，Segment的读取会根据查询条件与索引进行计算找到读取的对应行号信息

SegmentIterator

物化视图

MySQL客户端执行DQL SQL命令。

其他BE调用transimit_data将中间结果发送给BE coordinator节点汇总为最终结果。

FE调用fetch_data获取最终结果。

FE将最终结果发送给MySQL client。

查询

数据流和控制流

稀疏索引

Bloom Filter（布隆过滤器）是用于判断某个元素是否在一个集合中的数据结构，优点是空间效率和时间效率都比较高，缺点是有一定的误判率。

Bloom Filter 索引

Bloom Filter（布隆过滤器）

建立在枚举值列

Bitmap索引

简单理解为就是消除程序循环的优化。

列式存储

向量化执行引擎可以减少节点间的调度，提高CPU的利用率

因为列存数据，同一列的数据放在一起，导致向量化执行引擎在执行的时候拥有了更多的机会能够利用的当前硬件与编译的新优化特征

因为列存数据存储将同类型的类似数据放在一起使得压缩比能够达到更高，这样可以拉近一些磁盘IO能力与计算能力的差距

优势

向量化执行

shuffle join

broadcast join

Doris

以Hive或者Kafka作为数据源，里面保存着真实表，而Kylin做的就是将数据进行抽象，通过引擎实现Cube的构建。将Hbase作为数据的仓库，存放Cube。因为Hbase的直接读取比较复杂，所以Kylin提供了近似SQL和HQL的形式，满足了数据读取的基本需求。对外提供了RestApi和JDBC/ODBC方便操作。

预加载

kylin.cube.algorithm.auto.threshold 默认7作为阈值

充分利用MR

逐层构建算法

一个reduce 写三维度

快速构建算法

核心算法

Cube

REST Server服务层

查询引擎

路由层

cube构建引擎

kylin

可扩展并行度的 ETL、数据分析以及事件驱动

Batch（DataSet API）

Streaming（DataStream API）

Tables API & SQL

在 Flink 中，应用程序由用户自定义算子转换而来的流式 dataflows 所组成。这些流式 dataflows 形成了有向图，以一个或多个源（source）开始，并以一个或多个汇（sink）结束。

从 Streaming 到 Batch 的一个桥梁，将无界数据划分成有界数据。我们通过定义一个窗口，收集一批数据，并对这个窗口内的数据进行聚合类的计算。

如果关心事件实际发生时间，则必须基于事件的事件时间，而不是处理时间

事件时间与处理时间

时间

用来决定某个元素被分配到哪个/哪些窗口中去。

Window Assigner

触发器。决定了一个窗口何时能够被计算或清除，每个窗口都会拥有一个自己的Trigger。

Trigger

“驱逐者”。在Trigger触发之后，在窗口被处理之前，Evictor（如果有Evictor的话）会用来剔除窗口中不需要的元素，相当于一个filter，如countTime 中evictor(size) ，其中size 为保留的元素个数

Evictor

窗口组件

处理数据从source、transform、sink中的背压和消息乱序问题---延迟触发window计算

引入watermark机制则会等待晚到的数据一段时间，等待时间到则触发计算，如果数据延迟很大，通常也会被丢弃或者另外处理。

watermark

Flink 基于 Chandy-Lamport 算法实现了自己的分布式快照算法，利用 state 和 checkpoint 机制实现了 streaming system 的 exactly-once 语义

一个Checkpoint记录着数据流中某个时刻所有operators对应的状态

Flink Checkpoint的核心元素就是数据流Barrier，Barrier会被注入到数据流中，作为数据流的一部分向前流动。Barrier将数据流中的数据切分为进入当前Checkpoint的部分和进入下一次Checkpoint的部分，每个Barrier都携带对应Checkpoint的ID。Barrier是非常轻量级的，不会中断数据流的处理。

Checkpoint Barrier

Job Manager中的Checkpoint Coordinator向所有source端发送触发Checkpoint的通知，并在source端注入barrier事件。

Source端向下游传递barrier，并将自己的状态异步地写入到持久化存储中。

Operator接收到source端传递的barrier之后，会对operator的输入流进行对齐barrier，然后向输出流传递barrier，并将自己的状态异步的写入到持久化存储中。

当sink端接收到所有输入流传递过来的barrier之后，就会向Checkpoint Coordinator通知，此次Checkpoint执行完成。

执行过程

checkpoint 机制

在缺乏类似全局时钟或者全局时钟不可靠的分布式系统中来确定一种全局状态

分布式快照算法应用到流式系统中就是确定一个 Global 的 Snapshot

将分布式系统简化成有限个进程和进程之间的 channel 组成，也就是一个有向图：节点是进程，边是 channel。因为是分布式系统，也就是说，这些进程是运行在不同的物理机器上的。那么一个分布式系统的全局状态就是有进程的状态和 channel 中的 message 组成

Flink 在 2015 发布了一篇论文 Lightweight asynchronous snapshots for distributed dataflows

Chandy-Lamport 算法

checkpoint 与 state

Event Processing（CEP）

Graphs：Gelly

Machine Learning

扩展库

处理 Job 提交、 Job 监控以及资源管理

JobManager

运行 worker 进程，负责实际任务 Tasks 的执行，而这些任务共同组成了一个 Flink Job

Flink TaskManager

Back Pressure背压

BroadcastPartitioner：广播分区器，将数据发往下游的所有节点CustomPartitionerWrapper：自定义分区器，可以自定义分区的规则ForwardPartitioner：转发分区器，将数据转发给在本地运行下游的operaterShufflePartitioner：洗牌分区器，将数据在所有output chancel随机选择一个输出GlobalPartitioner：全局分区器：默认会选择索引为0的channel进行输出KeyGroupStreamPartitioner：键组分区器，通过记录数据的值获取到分区key：keyGroupId * parallelism / maxParallelism;RebalancePartitioner：轮询分区器，适用于数据倾斜RescalePartitioner：可扩展的分区器，通过轮询的方式将数据向下游输出

分区

OperatorChain

operators.setup()

task specific init()

initialize-operator-states()

open-operators()

run()

finish-operators()

close-operators()

common cleanup

task specific cleanup()

invoke

StreamTask

tasks

优化的逻辑执行计划（Web UI中看到的就是这个）

JobGraph

jobgraph

物理执行计划

ExecutionGraph

executiongraph

runtime

原始逻辑执行计划

StreamGraph

graph

api

streaming

org.apache.flink

flink

spark基于local

spark基于standalone

spark基于yarn

spark基于metsos

DataSet

DataFrame

spark sql

Spark Streaming 流处理框架

MLlib机器学习库

Graphx图形处理库

spark core

master

运行在worker节点上的一个进程，负责运行某些task，并将数据存在内存或者磁盘上。

在executor进程中执行任务的工作单元

每个job被划分为多个stage，一个stage中包含一个taskset

stage

task

Executer

Cache

Work Node

Cluster manager

main()函数，创建SparkContext，由SparkContext进行资源申请，任务的分配和监控等。程序执行完毕后关闭SparkContext。

Driver

groupByKey

算子

一个 RDD 由一个或者多个分区（Partitions）组成。对于 RDD 来说，每个分区会被一个计算任务所处理，用户可以在创建 RDD 时指定其分区个数，如果没有指定，则默认采用程序所分配到的 CPU 的核心数；

RDD 拥有一个用于计算分区的函数 compute

RDD 会保存彼此间的依赖关系，RDD 的每次转换都会生成一个新的依赖关系，这种 RDD 之间的依赖关系就像流水线一样。在部分分区数据丢失后，可以通过这种依赖关系重新计算丢失的分区数据，而不是对 RDD 的所有分区进行重新计算；

Key-Value 型的 RDD 还拥有 Partitioner(分区器)，用于决定数据被存储在哪个分区中，目前 Spark 中支持 HashPartitioner(按照哈希分区) 和 RangeParationer(按照范围进行分区)；

transformations（转换，从现有数据集创建新数据集）

actions（在数据集上运行计算后将值返回到驱动程序）

操作RDD

窄依赖 (narrow dependency)：父 RDDs 的一个分区最多被子 RDDs 一个分区所依赖；

宽依赖 (wide dependency)：父 RDDs 的一个分区可以被子 RDDs 的多个子分区所依赖。

首先，窄依赖允许在一个集群节点上以流水线的方式（pipeline）对父分区数据进行计算，例如先执行 map 操作，然后执行 filter 操作。而宽依赖则需要计算好所有父分区的数据，然后再在节点之间进行 Shuffle，这与 MapReduce 类似。窄依赖能够更有效地进行数据恢复，因为只需重新对丢失分区的父分区进行计算，且不同节点之间可以并行计算；而对于宽依赖而言，如果数据丢失，则需要对所有父分区数据进行计算并再次 Shuffle。

宽依赖和窄依赖

弹性式数据集RDDs

基于内存计算，减少低效的磁盘交互

高效的调度算法，基于DAG

容错机制Linage，精华部分就是DAG和Lingae

防止不必要的jar包分发，提高数据的本地性，选择高效的存储格式如parquet

过滤操作符的优化降低过多小任务

降低单条记录的资源开销

处理数据倾斜

复用RDD进行缓存

作业并行化执行

启用高效的序列化方法如kyro

增大off head

将 mapper（Spark 里是 ShuffleMapTask）的输出进行 partition

不同的 partition 送到不同的 reducer（Spark 里 reducer 可能是下一个 stage 里的 ShuffleMapTask，也可能是 ResultTask）

Reducer 以内存作缓冲区，边 shuffle 边 aggregate 数据，等到数据 aggregate 好以后进行 reduce() （Spark 里可能是后续的一系列操作）

Hadoop MapReduce 是 sort-based，进入 combine() 和 reduce() 的 records 必须先 sort

Spark

Topology

spout

bolt

Nimbus

Supervisors

Storm

Hadoop Upserts anD Incrementals

在hadoop兼容的存储之上存储大量数据

Update/Delete记录：Hudi使用细粒度的文件/记录级别索引来支持Update/Delete记录，同时还提供写操作的事务保证。查询会处理最后一个提交的快照，并基于此输出结果。

变更流：Hudi对获取数据变更提供了一流的支持：可以从给定的时间点获取给定表中已updated/inserted/deleted的所有记录的增量流，并解锁新的查询姿势（类别）

两种原语

Hudi

提供统一批处理和流处理的编程范式

Beam

Webserver

ExecutorServer

job

Flow1.0

Flow2.0

Flow

Azkaban

dolphinscheduler

分布式任务调度框架

sqoop数据迁移工具

Event 数据传输的基本单元

Source 数据源

Channel 临时存储数据的管道

Sink 数据处理单元

Agent

flume数据收集工具

cboard

davinci

DVAAS（Data Visualization as a Service）平台解决方案

数据可视化

MOLAP以Cube为表现形式，但计算与管理成本较高

MOLAP(Multidimensional OLAP)

随着分布式、并行化技术成熟应用，MPP引擎逐渐表现出强大的高吞吐、低时延计算能力，号称“亿级秒开”的引擎不在少数，ROLAP模式可以得到更好的延伸。

ROLAP需要强大的关系型DB引擎支撑

ROLAP(Relational OLAP)

\t关系型数据库

HOLAP(Hybrid OLAP)

ROLLUP（上卷）

olap

依赖 kafka connect

消息体内容太多，对消息队列压力较大

每张表对应一个topic，管理起来不够方便（canal，maxwell则可以使用正则来处理）

支持快照模式(snapshot.mode)全量同步

debezium

Canal

1.mbcj 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议

2.MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 mbcj)

3.mbcj 解析 binary log 对象(原始为 byte 流)

mysql-binlog-connector-java （mbcj）

不支持truncate命令同步

Maxwell

CDC

大数据

从经验E中，解决某一任务T，进行某一性能度量P

假设函数（hypothesis） h

训练集（training set）

标注

针对单个训练样本而言

模型一开始训练时，学习速率非常慢

在一定的假设下，我们可以使用最大化似然得到均方差损失的形式

在模型输出与真实值的误差服从高斯分布的假设下，最小化均方差损失函数与极大似然估计本质上是一致的

损失呈二次方地增加

Mean Squared Error (均方误差) L2 Loss

损失呈线性增长

Mean Absolute Error Loss（平均绝对误差损失） L1 Loss

Huber Loss 结合了 MSE 和 MAE 损失，在误差接近 0 时使用 MSE，使损失函数可导并且梯度更加稳定；在误差较大时使用 MAE 可以降低 outlier 的影响，使训练对 outlier 更加健壮。缺点是需要额外地设置一个超参数。

HuberLoss（Huber 损失）

高估

低估

分段的函数

分别用不同的系数控制高估和低估的损失，进而实现分位数回归

Quantile Loss（分位数损失）

Cross Entropy Loss Function（交叉熵损失函数）

Classification Error（分类错误率）

Hinge Loss（Hinge 损失合页损失）

损失函数 Loss Function

针对整个训练集

代价函数 Cost Function

表示任意希望被优化的函数，用于机器学习领域和非机器学习领域（比如运筹优化）

目标函数 Objective Function

分类

回归

序列标注

按数据分类

模式识别

函数回归

概率密度估计

由样本定义经验风险

学习的目标、期望风险最小化

机器学习问题

一元

多元

线性回归

非线性回归

回归问题

\tPerceptron\t感知器算法

Neural Network\t神经网络

Random Forests\t随机森林

Restricted Boltzmann Machines\t有限波尔兹曼机

朴素贝叶斯

KNN（K Nearest Neighbors）

分类算法

SVM\t支持向量机

计算机如何处理无穷特征

监督学习（supervise learning）

聚类算法

svd（奇异值分解）

鸡尾酒会算法

无监督学习（unsupervise learning）

增强学习

半监督学习

按监督分类

生成式模型

判别式模型

按模型分类

基本概念和分类

Logistic Regression\t逻辑回归

松弛变量

核函数

惩罚因子

支持向量机

经典算法

对丢失数据不是很敏感，算法比较简单，经常用于文本分类。

小规模数据上表现良好

Bayesian\t贝叶斯

隐马尔科夫

最大熵

条件随机场

概率图模型

监督学习模型

层次聚类

KNN的原理就是当预测一个新的值x的时候，根据它距离最近的K个点是什么类别来判断x属于哪个类别

从选取一个较小的K值开始，不断增加K的值，然后计算验证集合的方差，最终找到一个比较合适的K值。

交叉验证

非参的意思并不是说这个算法不需要参数，而是意味着这个模型不会对数据做出任何的假设，与之相对的是线性回归（我们总会假设线性回归是一条直线）。也就是说KNN建立的模型结构是根据数据来决定的，这也比较符合现实的情况，毕竟在现实中的情况往往与理论上的假设是不相符的。

惰性又是什么意思呢？想想看，同样是分类算法，逻辑回归需要先对数据进行大量训练（tranning），最后才会得到一个算法模型。而KNN算法却不需要，它没有明确的训练数据的过程，或者说这个过程很快。

非参的，惰性的算法模型

K均值聚类

高斯混合模型

主题模型

非监督学习模型

Bagging

Boosting

随机森林

GBDT

集成学习

降维算法 &降维/维约简

采样

策略求值函数

根据值函数来更新策略

强化学习

经典机器学习模型

特征离散与归一化

特征组合

特征选择

词迁入表示

特征工程

OCTAVE

MATLAB

工具

损失函数

正则化

EM算法

随机梯度下降

梯度验证

Momentum

AdaGrad

Adam

主要思想是利用弱分类器（决策树）迭代训练以得到最优模型采用加法模型（即基函数的线性组合），以及不断减小训练过程产生的残差来达到将数据分类或者回归的算法。

点击率预测，搜索排序

Decision Tree：CART回归树

Gradient Boosting：负梯度——残差

GBDT (Gradient Boosting Decision Tree)（梯度下降树）

解决 GBDT 在海量数据遇到的问题

直方图算法的基本思想是先把连续的浮点特征值离散化成k个整数，同时构造一个宽度为k的直方图

基于 Histogram 的决策树算法

带深度限制的 Leaf-wise 的叶子生长策略

直方图做差加速

直接支持类别特征(Categorical Feature)

Cache 命中率优化

基于直方图的稀疏特征优化

多线程优化

LightGBM

对所有特征都按照特征的数值进行预排序

遍历分割点的时候用O(#data)的代价找到一个特征上的最好分割点

找到一个特征的分割点后，将数据分裂成左右子节点

决策树算法

XGBoost(eXtreme Gradient Boosting)极度梯度提升树

提升方法（Boosting）

优化算法

计算机视觉

自然语言处理

计算广告

智能游戏

局部极小

维数灾难

过拟合

模型优化点

机器学习

Geoffrey Hinton和他的学生Alex Krizhevsky

2012年. AlexNet在ImageNet比赛的胜出，他证明了深度学习在图像识别方面比其他计算机视觉的方法具备更大的优势

发展历史

当激活函数接近饱和区时，变化太缓慢，导数接近0，根据后向传递的数学依据是微积分求导的链式法则，当前导数需要之前各层导数的乘积，几个比较小的数相乘，导数结果很接近0，从而无法完成深层网络的训练

容易出现梯度消失（gradient vanishing）的现象

这会导致后层的神经元的输入是非0均值的信号，这会对梯度产生影响。以 f=sigmoid(wx+b)为例，假设输入均为正数（或负数），那么对w的导数总是正数（或负数），这样在反向传播过程中要么都往正方向更新，要么都往负方向更新，导致有一种捆绑效果，使得收敛缓慢。

Sigmoid的输出不是0均值（zero-centered）

幂运算相对耗时

Sigmoid（S 形）

Tanh（双曲正切）

函数

激活函数

反向传播

调整参数的梯度

神经网络

多层感知器

基于图像任务的平移不变性（图像识别的对象在不同位置有相同的含义）设计的，擅长应用于图像处理等任务

卷积、池化、全连接

全卷积神经网络

AlexNet、VGG、Res-Net

Inception-Net、MobileNet

CNN调参技巧

卷积神经网络（CNN）

谷歌2017年

提出

multi-head self-attention mechanism（多头 self-attention 模块）

position-wise feed-forward network（前馈神经网络层）

两部分，都有一个残差连接(residual connection)，然后接着一个Layer Normalization。

Encoder

multi-head self-attention mechanism（多头 self-attention 模块）

encoder-decoder attention 交互模块考虑encoder中上下文的信息

position-wise feed-forward network（（前馈神经网络层））

三部分，都有一个残差连接(residual connection)，后接着一个Layer Normalization。

Decoder

通过加权求和获得对上下文的全局感知

对于某个时刻的输出y，它在输入x上各个部分的注意力。这个注意力可以理解为权重。

消除QKV的初始值影响

以不同的向量QKV进行了八次计算，加权平均合成一个输出

multi-head-Attention

self-attention

Attention机制

残差连接

Add模块

在每一层计算每一个样本的均值与方差

LayerNorm

Norm 模块

归一化

算法将单词向量化嵌入位置信息同一长度

分别乘以三个训练好的向量 Q K V

过滤不想干的单词

softmax函数

乘以V向量后加权求和得到Z向量

标明权重和上下文信息

Encoder-self-attention

数据流动

线性层

梯度下降

训练

2017年 Transformer概念

双向模型

只能完成NLU任务

自编码模型

特点

2018年 BERT(Bidirectional Encoder Representation from Transformers)

在不同的无标签文本语料库上对语言模型进行生成式预训练（无监督），然后对每个特定任务进行微调（有监督），可以在这些任务上实现较大的收益

GPT是一种自回归生成式预训练语言模型（对一条句子，通过句子上文训练下一个单词的embedding，比如对前n个单词embedding后预测第n+1个单词，之后把n+1个单词也加入输入，预测第n+2个单词，预测与标签之间的KL散度作为损失函数），通过单向语言模型预训练+微调的二阶段训练方法，先使用海量无标签数据训练生成语言模型得到词向量，再使用有标签的数据通过特定任务进行学习Fine-Tuning。

语言生成：遵循提示词（prompt），然后生成补全提示词的句子。这也是今天人类与语言模型最普遍的交互方式。

上下文学习 (in-context learning)：遵循给定任务的几个示例，然后为新的测试用例生成解决方案。很重要的一点是，GPT-3虽然是个语言模型，但它的论文几乎没有谈到「语言建模」 (language modeling) —— 作者将他们全部的写作精力都投入到了对上下文学习的愿景上，这才是 GPT-3的真正重点。

世界知识：包括事实性知识 (factual knowledge) 和常识 (commonsense)。

能力

用于代码

基础模型

code-davinci-002

用于文本

指令微调

text-davinci-002

响应人类指令：以前，GPT-3 的输出主要训练集中常见的句子。现在的模型会针对指令 / 提示词生成更合理的答案（而不是相关但无用的句子）。

泛化到没有见过的任务：当用于调整模型的指令数量超过一定的规模时，模型就可以自动在从没见过的新指令上也能生成有效的回答。这种能力对于上线部署至关重要，因为用户总会提新的问题，模型得答得出来才行。

代码生成和代码理解：这个能力很显然，因为模型用代码训练过。

利用思维链 (chain-of-thought) 进行复杂推理：初代 GPT3 的模型思维链推理的能力很弱甚至没有。code-davinci-002 和 text-davinci-002 是两个拥有足够强的思维链推理能力的模型。

语言中的下个词语预测通常是非常局部的，而代码通常需要更长的依赖关系来做一些事情，比如前后括号的匹配或引用远处的函数定义

长距离依赖

与初代 GPT-3 不同的能力

GPT3.5

预训练

语言生成能力 + 基础世界知识 + 上下文学习

davinci

Codex

有监督指令微调 (supervised instruction tuned) 模型

text-davinci-003

ChatGPT

指令微调 (instruction tuning)

GPT是单向模型，无法利用上下文信息，只能利用上文

可以应用在NLU和NLG两大任务

自回归模型

Fine-Tuning 微调

instruction tuned 指令微调

翔实的回应：text-davinci-003 的生成通常比 text-davinci-002长。ChatGPT 的回应则更加冗长，以至于用户必须明确要求「用一句话回答我」，才能得到更加简洁的回答。这是 RLHF 的直接产物。

公正的回应：ChatGPT 通常对涉及多个实体利益的事件（例如政治事件）给出非常平衡的回答。这也是RLHF的产物。

拒绝不当问题：这是内容过滤器和由 RLHF 触发的模型自身能力的结合，过滤器过滤掉一部分，然后模型再拒绝一部分。

拒绝其知识范围之外的问题：例如，拒绝在2021 年 6 月之后发生的新事件（因为它没在这之后的数据上训练过）。这是 RLHF 最神奇的部分，因为它使模型能够隐式地区分哪些问题在其知识范围内，哪些问题不在其知识范围内。

RLHF 基于人类反馈的强化学习

key word

语言生成能力 + 基础世界知识 + 上下文学习都是来自于预训练（davinci）

存储大量知识的能力来自 1750 亿的参数量

遵循指令和泛化到新任务的能力来自于扩大指令学习中指令的数量（Davinci-instruct-beta)。

执行复杂推理的能力很可能来自于代码训练（code-davinci-002）

无论是有监督还是 RLHF ，模型在很多任务的性能都无法超过 code-davinci-002 ，这种因为对齐而造成性能衰退的现象叫做对齐税

建模对话历史

拒绝模型知识范围之外的问题

增加对话信息量

对话能力也来自于 RLHF（ChatGPT），具体来说它牺牲了上下文学习的能力，来换取

初代GPT-3模型通过预训练获得生成能力、世界知识和in-context learning。然后通过instruction tuning的模型分支获得了遵循指令和能泛化到没有见过的任务的能力。经过代码训练的分支模型则获得了代码理解的能力，作为代码训练的副产品，模型同时潜在地获得了复杂推理的能力。

结合这两个分支，code-davinci-002似乎是具有所有强大能力的最强GPT-3.5模型。接下来通过有监督的instruction tuning和 RLHF通过牺牲模型能力换取与人类对齐，即对齐税。RLHF 使模型能够生成更翔实和公正的答案，同时拒绝其知识范围之外的问题。

总结

分解

2020年 GPT-3（Generative Pre-Training)）

2020年

Transformer模型

深度残差网络

自组织映射神经网络

受限玻尔兹曼机

前馈神经网络

能够将之前的信息与当前的任务联系起来，例如我们可以通过之前的视频帧了解当前帧的内容。 tip：有点实时计算引擎开窗的感觉..

双向网络

随着跨度的增加，RNN 变得难以对信息之间的关联进行有效学习

具有对长期依赖进行学习的能力

第一步是决定从上一个细胞状态中丢弃什么信息

遗忘门

决定在细胞状态中存储哪些新信息

输入门

输出门

增加或删除细胞状态中的信息

sigmoid 神经网络层

点乘运算

门结构

当前时刻输入

上一时刻隐藏层状态

上一时刻细胞状态

长短期记忆模型

循环神经网络RNN

递归神经网络

CNN中没有可用的空间信息

一种新的网络

将神经元替换为胶囊

包括空间几何信息

根据图像（渲染结果）反推出物体的信息

逆渲染

胶囊网络

反卷积

对抗损失

对抗神经网络网络GAN

计算量开销大，计算速度慢，不支持在线学习

遍历全部数据集算一次损失函数，然后算函数对各个参数的梯度，更新梯度

批梯度下降

这个方法速度比较快，但是收敛性能不太好

每看一个数据就算一下损失函数，然后求梯度更新参数

batch_size

小批的梯度下降

batch

向前和向后传播中所有批次的单次训练迭代

训练过程中数据将被“轮”多少次

epoch

1个iteration等于使用batchsize个样本训练一次

iterations

深度学习

neo4j（见数据库分支）

图数据库

知识图谱

中文自动分词

词性标注

句法分析

文本分类

自然语言生成（NLG）

自然语言理解（NLU）

信息检索

信息抽取

文字校对

问答系统

机器翻译

自动摘要

文字蕴涵

语言是没有规律的，或者说规律是错综复杂的。

语言是可以自由组合的，可以组合复杂的语言表达。

语言是一个开放集合，我们可以任意的发明创造一些新的表达方式。

语言需要联系到实践知识，有一定的知识依赖。

语言的使用要基于环境和上下文。

难点

分词

词干提取

词形还原

命名实体识别

分块

英文

去停用词

中文

语料预处理

单词构成的集合，集合自然每个元素都只有一个，也即词集中的每个单词都只有一个

词集

在词集的基础上如果一个单词在文档中出现不止一次，统计其出现的次数（频数）

词袋

用以评估某一字词对于一个文件集或一个语料库的重要程度

TF * IDF。TF表示词条在文档d中出现的频率。IDF（inverse document frequency，逆向文件频率）的主要思想是：如果包含词条t的文档越少，也就是n越小，IDF越大，则说明词条t具有很好的类别区分能力

TF-IDF模型（term frequency–inverse document frequency，词频与逆向文件频率）

一个池塘有10条鱼和20只小龙虾，渔夫撒网打鱼，结果捞上来8条鱼12只小龙虾，那么准确率为8/(8+12)=40%，召回率为8/10=80%。

准确率

召回率

全体预测正确占全部样本的比例

准确度

F1-Score也是对准确率和召回率的一个均衡评价

F1-Score

ROC（Receiver Operating Characteristic Curve）受试者工作特征曲线，以真阳性率为纵坐标，假阳性率为横坐标绘制的曲线，是反映灵敏性和特效性连续变量的综合指标。一般认为ROC越光滑说明分类算法过拟合的概率越低，越接近左上角说明分类性能越好。

ROC

AUC（Area Under the Receiver Operating Characteristic Curve）就是量化衡量ROC分类性能的指标

AUC

预测真实际真

预测假实际假

预测真实际假

混淆矩阵

Bilingual evaluation understudy

分数越接近1，说明翻译的质量越高

基于精确率(Precision)

BLEU

基于召回率

在 N-gram 上计算召回率

ROUGE-N

考虑了机器译文和参考译文之间的最长公共子序列

ROUGE-L

改进了ROUGE-L，用加权的方法计算最长公共子序列

ROUGE-W

ROUGE

评定标准

选择分类器

传统

CBOW模型能够根据输入周围n-1个词来预测出这个词本身

CBOW(Continuous Bag-Of-Words）

Skip-gram模型能够根据词本身来预测周围有哪些词

Skip-Gram

可以把对文本内容的处理简化为K维向量空间中的向量运算，而向量空间上的相似度可以用来表示文本语义上的相似度

Word2Vec模型

词表征为实数值向量

设计模型

模型训练

深度学习NLP

传统模型

GPT（Generative Pre-Training)）

BERT(Bidirectional Encoder Representation from Transformers)

OPT(Open Pre-trained Transformer)

code-cushman-001

FlanT5

transformer

NLP

CNN

Vision Transformer(ViT)

基于特征的预测

基于提议的预测

Transformer模型

预测附近车辆的下一步轨迹，对于自动驾驶汽车系统了解周围环境并做出信息决策至关重要

多模态预测问题

预测一个物体与相机接触的时间

TTC

场景深度估计

光流估计方法

自动驾驶

OCR

粗排选取合适的内容，可以通过协同过滤，兴趣tag，内容最热等方式

召回

使用一个点击率预估模型（输入用户特征，内容特征，用户内容交叉特征等）对召回出来的内容进行排序

排序（CTR预估）

DeepFM是2017年哈工大和华为公司联合提出的一个模型

基于深度神经网络的FM模型

DeepFM

人工智能应用

行业专家经验很重要，否则就要做 EDA 和 UBA 分析

将行业专家的知识经验转化为特征工程，也许比上亿数据训练更有效果。

训练模型的目的是为了预测更精准，而不是覆盖所有历史数据

分布式训练框架

流式处理增量处理

大数据量

为了解决因维数过大而导致计算能力不足的缺陷，其实质是特征向量内积的平方在机器学习中

在许多情况下，我们希望我们的模型学习非线性模型。通常的方法是选择函数φ（x）将X映射到另一个空间。这里的核心是如何选择φ（x）

内核功能核函数

通过使用低精度算术降低了所需的资源

半精度浮点格式（FP16）使用16位，而单精度（FP32）使用32位。降低所需的内存可以训练更大的模型或训练时使用更大的batch size

减少所需的内存量

计算的次数或者数据存储的存储十分影响算法的执行时间。半精度使用单精度的一半内存访问，从而降低了在存储层方面所花费的时间。与单精度相比，NVIDIA GPU的半精度算术吞吐量最多提高了8倍，从而加快了数学受限层的速度。

缩短训练或推理时间

混合精度训练

AIGC

人工智能

PPG血容量脉搏

EDA皮肤电数据

RESP呼吸数据

SKT皮温数据

ACC人体姿态数据

spO2血氧饱和度

MEG脑磁数据

毫伏

EMG肌电图

20毫伏

ECG心电数据

每当数千个神经元同时放电时，它们就会产生一个强大的电场，足以穿过组织、骨骼和头骨。最终，它可以在头部表面测量

大脑的生物电活动

金标准/湿电极脑电设备--NeurOne系统

人在想象自己肢体（或肌肉）运动但没有实际运动输出时，人的特定脑区仍会有激活，目前常见的运动想象部位为：左右，右手，双脚和舌头。通过分析脑电信号，检测识别不同脑区的激活效果来判断用户意图，进而实现人脑与外部设备之间的直接通信与控制。

运动想象数据

情绪识别数据

误差相关电位(ErrP)

视觉诱发电位(VEPs)

事件相关电位(ERPs)

慢皮质电位(SCPs)

休息状态音乐与EEG

眨眼/眼动Miscellaneous

临床脑电图

脑电信号

睡眠实验室中，Delta波被用来评估睡眠深度。节奏越强，睡眠越深。Delta波功率的增加(增加的增量波记录数量)被发现与内部工作记忆任务的注意力增加有关

Delta(1-4 Hz)

Theta与广泛的认知处理相关，例如记忆编码和检索以及认知工作量[2]。每当我们遇到困难的任务时(例如，从100开始倒数，或者当回忆起下班回家的路时），Theta波就会变得更加突出。Theta也与疲劳程度增加有关

Theta(4 – 7 Hz)

Alpha(7–12 Hz)

在运动区域内，随着我们计划或执行任何身体部位的运动，Beta频率会变得更强[5]。有趣的是，随着我们观察其他人的身体运动，Beta波的这种增加也很明显。我们的大脑似乎模仿了他们的肢体运动，这表明我们大脑中存在着一个复杂的“镜像神经元系统”，该系统可能与Beta频率协调

Beta(12 – 30 Hz)

一些研究人员认为，Gamma波反映了注意力的集中，并作为载波频率来促进大脑区域之间的数据交换。其他人则将伽玛与快速的眼球运动(所谓的微扫视)联系起来，它们被认为是感觉处理和信息吸收的组成部分

Gamma(> 30 Hz，通常为40 Hz)

脑电仪

SSVEP

P300

运动想象

情感识别

图灵脑机测试

BCI脑控机器人大赛

BCI脑机接口

《10-20国际标准导联系统》

eeglab中默认的文件是 standard-10-5-cap385，指的是按照国际10-5系统排布的一共有385个电极点信息的模板

1. 定位通道数据

2.删除无用数据

高通滤波

低通滤波

带通滤波

凹陷滤波

3.滤波

只是被试在接受到某个刺激，或者做出某个反应时那段事件的信号，因此，我们要根据我们打上的mark，讲数据切分

4分段

相对平静的状态，此时的脑电活动，代表了一个平静状态下的脑电活动。所以我们将这段时间内的脑电活动当成一个基线

5.基线校正

鼻尖参考

cz或头顶中央参考

乳突就是耳朵后面一小块突起的区域

单侧乳突参考

双侧乳突平均参考

排除眼电数据

全脑平均参考

数值为通道和参考通道的电位差

6. 重参考

因为降低采样率会使我们丢失高频信息，使高频信息变得扭曲，所以最好在保留了我们感兴趣波段之后再去降低采样率，这样可以保证信号最大程度不会失真

降低采样率要在滤波之后

我们的采样率必须是我们想要分析的波段的两倍，比如我们想要分析60Hz的波，那数据采样率为120Hz就足够了。实际上，建议采样率最好在分析波段的三到四倍。

采样定理

7. 降低采样率

对通道进行校正操作，对数据不好的导联进行插值处理

横向操作

挑出数据不好的trials，删除掉。建议是先横向处理后再纵向剔除，尽量保留下更多的trials数

纵向

去除伪迹

以某通道周围几个通道的数据的平均值，来替代这个通道的数据，这种直接通过代码实现即可

8. 插值坏导

我们记录到的是头皮脑电，脑电帽上划出了一个个的点来表示位置，但是我们在FPz点记录到的数据，就真的是FPz点这个位置头皮下方的区域所产生的电活动？不一定。做过实验的都知道，眨眼会产生影响，左右看会产生影响，帽子戴得太紧导致肌肉紧张也会产生影响，还有左右的FP1，FP2处产生的电活动也会影响到FPz，甚至在离它最远的Oz点下方产生的电活动，也有可能对前方FPz点产生微弱的影响。因为真正的电活动产生于头皮下方颅骨内部，它经过了这么一层又一层的传播之后，不同源的电活动肯定会相互影响，从而导致某个记录点记录到的数据，混合了很多不同成分的电活动。而独立主成分分析，就是要对记录点的数据做一个逆运算，把每个记录点的数据，分解成一个又一个的成分组成。然后我们再从中剔除掉伪迹成分，比如眨眼的成分，肌肉紧张的成分等，从而得到一个相对干净的数据。

9. 独立主成分分析

10 剔除坏段

EEG脑电数据预处理

EEG脑电数据处理

数十微伏

主要用于睡眠和梦境研究以及抑郁症和睡眠呼吸暂停综合征的诊断

EEG脑电数据

EOG眼电图

人因记录仪

复杂生理信号的研究资源

PhysioNet

飞行是集信息感知、快速决策、操纵控制以及信息界面监测、通讯交互等多任务与一体的驾驶过程。

人机协同效能实时评估

飞行员个体及意识状态实时辨识

装备系统交互界面人机功效评估

装备系统防护性能鉴定评估

关键问题

思路

飞行驾驶

HFACS

人因工程

无限长的信号被截断以后，其频谱发生了畸变，原来集中在f(0)处的能量被分散到两个较宽的频带中

频谱能量泄漏

矩形窗使用最多，习惯上不加窗就是使信号通过了矩形窗。这种窗的优点是主瓣比较集中，缺点是旁瓣较高，并有负旁瓣，导致变换中带进了高频干扰和泄漏，甚至出现负谱现象。频率识别精度最高，幅值识别精度最低，所以矩形窗不是一个理想的窗。如果仅要求精确读出主瓣频率，而不考虑幅值精度，则可选用矩形窗。

矩形窗

汉宁窗

与汉宁窗都是余弦窗，又称改进的升余弦窗，只是加权系数不同，使旁瓣达到更小。但其旁瓣衰减速度比汉宁窗衰减速度慢。其功能和应用与汉宁窗类似。在语音信号处理中，汉明窗应用最为广泛。

汉明窗

平顶窗在频域时的表现就象它的名称一样有非常小的通带波动。由于在幅度上有较小的误差，所以这个窗可以用在校准上。

平顶窗

窗函数

连续傅里叶变换&分数傅里叶变换

将一个用系数表示的多项式转换成它的点值表示的算法

如果模型足够平滑，它们会得到光谱收敛，这意味着误差呈指数递减

赫尔德条件

（快速）傅里叶变换（FFT）可用于从均匀间隔的数据中快速计算傅里叶级数

快速傅里叶变换（FFT）

离散傅里叶变换DFT

STFT在傅里叶变换的基础上加窗，分段做FFT变换

短时傅里叶变换STFT

利用计算机计算离散傅里叶变换（DFT)的高效、快速计算方法的统称

快速傅里叶变换FFT

切比雪夫变换 / 切比雪夫多项式

从时域到频域的变化

拉普拉斯

无限数量的正弦曲线的组合从能量的角度可以非常无限逼近带有棱角的信号。

正弦曲线无法组合成一个带有棱角的信号

拉格朗日

这些正弦波的频率符合一个规律：是某个频率的整数倍。这个频率，就称为基波频率

基波频率

其它频率称为谐波频率

谐波的频率是基波频率的N倍，就称为N次谐波

直流分量的频率为零，是基波频率的零倍，也可称零次谐波

谐波频率

任意周期信号可以分解为直流分量和一组不同幅值、频率、相位的正弦波。分解的方法就是傅里叶变换。

电参量测量

任何连续周期信号可以由一组适当的正弦曲线组合而成

通过示波器观测实时波形获取，称为时域分析法

傅里叶变换是一种信号分析方法，让我们对信号的构成和特点进行深入的、定量的研究。把信号通过频谱的方式(包括幅值谱、相位谱和功率谱)进行准确的、定量的描述。

正弦波输入至线性系统，不会产生新的频率成分(非线性系统如变频器，就会产生新的频率成分，称为谐波)

傅里叶变换

数字信号处理

霍夫变换

图像识别

目标检测

图像到数字

sobel算子

roberts算子

prewitt算子

log算子

cannny算子

边缘检测

图像切割

灰度级矫正

灰度变换

直方图均衡化、规定化

点运算

邻域平均法

中值滤波

降噪消除法

梯度倒数加权

选择掩膜平滑

图像平滑

梯度化

拉普拉斯算子

掩膜匹配法

统值插值法

图像锐化

邻域增强

空域

同态滤波

带阻滤波

频域

双边滤波

导向滤波

图像增强

图像降噪

图像翻译

图像聚类

图像到图像

R - CNN

残差网络

判别模型

GAN

自编码机、波尔兹曼机

生成模型

输入图像中一个小区域中像素加权平均后成为输出图像中的每个对应像素，其中权值由一个函数定义，这个函数称为卷积核

卷积核

图像处理

强调公司对产品开发的有效投资组合分析

业务计划

Product Development Team，产品开发团队，执行产品开发项目。

LPDT（PDT经理）

IPMT（集成产品组合管理团队）

PDT

IPD(集成的产品开发)

价值主张

提供什么

客户关系

营销渠道

客户细分

为谁提供

关键业务

核心资源

合作生态

如何提供

成本结构

收入来源

盈利模式

商业画布

salesforce商业模式

用户是谁

单点突破

差异点

产品的定位

多个不同的角色互相依赖、和谐共处、不断进化

商业变现的机制

利益反馈

不同角色的“权责利”

生态

“最简单、最直观”的体验

产品体验

到具体的场景中去设计和检验产品

埋点

从用户的行为而不仅是口中获得产品反馈

品味和颜值

产品自传播

眼里不要只有“产品功能”，更要多多考虑“人”

产品

生产制造

生产

固定供应商

采购

物流在途

电商代运营

寻源

交易

合同

履约

建筑供应链

集采

招标

电商

供应链

CRM系统

客户管理

品牌互动

用户画像

精准营销

营销

财务

数据驱动

商业洞察

经营

信息化是以业务流程的优化和重构为基础，通过信息技术与实际业务的有效融合，在IT系统内将现实世界的业务对象、业务流程进行重构和固化，并记录业务事件，实现企业信息的高效共享和业务的高效协同，形成对业务的监控和洞察能力，以提高工作效率、优化资源配置、支撑高效分析决策，进而提升企业竞争力和经济效益的过程。

信息化并未改变现实业务的逻辑

信息化的过程也是对数据重视程度逐步提高的过程。

信息化

数字化是利用云计算、大数据、物联网、人工智能等新一代数字技术，构建一个全感知、全场景、全智能的数字世界，在实现数字世界对物理世界的精准映射基础上，优化再造物理世界的业务，对传统管理模式、业务模式、商业模式进行创新和重塑，实现业务成功。

数字化

智能化的本质是让机器代替人做决策。智能化解决的核心问题是人与机器的关系，未来业务决策会越来越多地依赖于机器学习、依赖于人工智能，机器在很多商业决策上将扮演非常重要的角色，它能取得的效果将超过今天人工运作带来的效果，从而降低了管理人员决策的工作难度，提高决策效率和准确性。

数智化

解决方案

产品（product）

0级销售渠道

生产者→零售商→消费者

1级销售渠道

生产者→批发商→零售商→消费者

2级销售渠道

生产者→代理商→批发商→零售商→消费者

生产者→批发商→中间商→零售商→消费者

3级销售渠道

渠道（place）

价格（price）

促销（promotion）

市场营销

阿里派个P8过来和政府谈合作，看着像来视察工作，指着我们的系统说，这不如阿里，那不如阿里。

客户需要的是你深入理解行业，做针对性的软件定制开发

一次，周芳和同事去客户现场做前期POC（原型测试），看到华为云拉了三十个人过来，气势就压倒众人。“我们才三个人，你想象下客户的感受。”周芳只能硬着头皮强调自家的技术有多成熟，但最后还是以华为中标告终。

为什么国企客户动不动就喊人过去讲方案，写报告。“在阿里，谁有时间给你写报告，那不是你自己的事吗？

华为送自家出品的手机、配件，给客户领导、项目接口人试用体验一下，很正常吧。我们呢？经过申请审批的200元以下礼品，可能连高档一点儿的淘公仔都买不到吧。

云

商业

选

有挑战的工作

团队知识分享

育

okr、kpi

用

市场薪资调研

分支主题

留

和平的分手

离

二八原则

点评日报予以肯定

软实力

人员

任务拆分

燃尽图

deadline

项目

不断的重新定义岗位角色

领导力转型

领导梯队

金字塔原理

思维导图

SMART原则

定目标

STAR原则

汇报

研发性岗位

OKR适用于实现目标方法不是特别清晰不太成熟的岗位

（1）全员设定。公司、部门、管理者和员工均从战略开始设定自己的年度目标和季度目标。

（2）从上至下。目标的设立顺序应该是公司到部门到组到个人。

（3）目标共识。目标必须是在管理者与员工直接充分沟通后的共识

（4）目标具体可衡量。

（5）有野心的目标。

（6）目标不能过多，员工通常每季度制定4到6个

1.设定目标

（1）目标要有年度KRs，也有季度KRs。年度KRs统领全年，但并非固定不变，而是可以及时调整，调整要经过批准；季度KRs则是一旦确定就不能轻易改变的。

（2）可以调整的是KRs，目标不能调整。措施和方法（KRs）可以不断完善，且KRs的设定也应是管理者与员工直接充分沟通后的共识，以员工确认为主。

（3）KR是须具备的特点：必须是能直接实现目标的；必须具有进取心、敢创新的，可以不是常规的；必须是以产出或者结果为基础的、可衡量的，并设定评分标准；不能太多，一般每个目标的KR不超过4个；必须是和时间相联系的。

2、针对每个目标设定其KR(关键结果)

（1）每项关键结果就会派生出一系列的任务，交给不同的同事负责。

（2）关键结果负责人就成了名符其实的项目经理，来组织协调大伙。

（3）关键结果的项目经理是团队非常重要的成员，他们应能够调度和影响企业资源。如果他还不具备这个权力，就把这个权力给他；

3、推进执行（从关键结果到“行动计划“）

4、OKR回顾，与绩效评估

OKR

制造业的一线操作岗位

KPI适用于一些工作目标和措施都比较明确和成熟的岗位

选了错误的KPI

无法制订KPI

没有人对最终结果负责

KPI

人员管理

戴明环

团队管理

管理工具

管理

kettle

ETL

idea

eclipse

IDE

Jenkins

ansible

package

更新本地仓库

install

更新远程和本地仓库

deploy

modules

properties

dependency

dependencies

如果在同一pom.xml文件中有2个相同的依赖；后面声明的会覆盖前面的依赖

同一个pom

在不同pom.xml中有2个相同的依赖；则先声明的依赖，会覆盖后面生命的依赖

不同pom

路径长度相同

存在两个项目依赖同个类型但不同版本的jar包，这个时候会优先选择路径短的

路径最短优先原则

当依赖的scope为compile的时候，那么当前这个依赖的包，会在编译的时候被加入进来，并且在打包（mvn package）的时候也会被加入进来。编译范围有效，在编译与打包时都会加入进去。

compile 默认

在编译时我们需要依赖servlet-api.jar，但是在运行时我们不需要该 jar包，因为这个jar 包已由web服务器提供，如果在打包时又被加入进去，那么就可能产生冲突。此时我们就可以使用 provided 进行范围修饰。

当依赖的scope为provided的时候，在编译和测试的时候有效，在执行（mvn package）进行打包时不会加入。

provided

<systemPath>${basedir}/WebContent/WEB-INF/lib/open-core.jar</systemPath>

与provided相同，不过被依赖项不会从maven仓库获取，而是从本地文件系统拿，需要配合systemPath属性使用。

system

当依赖的scope为runtime的时候，在运行的时候才会依赖，在编译的时候不会依赖。比如，在编译的时候我们不需要JDBC API的jar包，而在运行的时候我们才需要JDBC驱动包。就可以使用runtime修饰。

当依赖的scope为test的时候，指的的是在测试范围有效，在编译与打包的时候都不会使用这个依赖。

test

依赖上的多重继承

import

scope 域

依赖

dependencyManagement

repositories

pluginRepositories

plugins 下的 plugin 是真实使用的，而 pluginManagement 下的 plugins 下的 plugin 则仅仅是一种声明

pluginManagement

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin>

<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>${spring.boot.version}</version> </plugin>

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>3.0.2</version> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> <mainClass>com.glodon.scm.integrate.platform.service.IntergrateApplication</mainClass> </manifest> </archive> </configuration> </plugin>

build

packaging

parent

modelVersion

groupId

artifactId

version

name

maven

运维&CI

表单

报表

连接平台

数据大屏

酷数据

添加到群

宜搭

低代码

界面

jmeter

postman

yapi

单元

测试

tapd

禅道

jira

项目管理

swagger

接口管理

rebase

merge

git

svn

代码版本控制

监控指标

SkyWalking

链路追踪

听云

zabbix

探针

APM

phantomjs

页面截图

它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入的恶意html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。但是随着前端技术的不断进步富客户端的应用越来越多，这方面的问题越来越受关注。举个简单例子：假如你现在是sns站点上一个用户，发布信息的功能存在漏洞可以执行js 你在此刻输入一个恶意脚本，那么当前所有看到你新信息的人的浏览器都会执行这个脚本弹出提示框（很爽吧弹出广告：）），如果你做一些更为激进行为呢后果难以想象。

XSS (Cross Site Script) ，跨站脚本攻击

让用户以自己的身份来完成攻击者需要达到的一些目的。csrf 的攻击不同于xss csrf 需要被攻击者的主动行为触发。这样听来似乎是有“被钓鱼”的嫌疑哈哈。

CSRF(Cross Site Request Forgery)，跨站点伪造请求

tcp

udp

DoS

DDoS

文件上传漏洞

触发数据库返回错误。

N/ A

永真，返回所有行。

') OR ('1' = '1