首页  思维导图  详情

大厂资深架构师专家技术树（12w字）强烈建议下载本地编辑

2022-10-20 11:48:22   1  举报





AI智能生成

架构设计

程序开发

大数据

人工智能

微服务

作者其他创作

大纲/内容

计算机硬件

计算机系统底层架构

电控开关

1+1=2 加法器

先行进位&并行进位

组成原理

CPU

架构

服务器

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

对称多处理器结构

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

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

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

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

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

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

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

存储器共享方式

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

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

品牌

ARM公司: arm架构

intel公司: intelx86系列架构

AMD公司: amdx86系列架构

SIMD

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

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

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

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

只支持整数操作

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

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

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

AVX指令集

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

AVX2

AVX512

512-bit

组成

寄存器

指令指针寄存器

控制器

指令寄存器（IR ）

存放指令

指令译码器（ ID ）

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

操作用户程序数据段

操作控制器（ OC ）

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

运算器

总线

缓存一致性协议

内存屏障(Memory Barrier)

Intel 的MESI协议

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

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

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状态

多级缓存

L1 data cache（DL1）

L1 instruction cache（IL1）

32KB

256KB

3MB

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

伪共享”(False Sharing)

这个缓存行可以被许多线程访问。如果其中一个修改了v2，那么会导致Thread1和Thread2都会重新加载整个缓存行。你可能会疑惑为什么修改了v2会导致Thread1和Thread2重新加载该缓存行，毕竟只是修改了v2的值啊。虽然说这些修改逻辑上是互相独立的，但同一缓存行上的数据是统一维护的，一致性的粒度并非体现在单个元素上。这种不必要的数据共享就称之为“伪共享”(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的时候，就会产生一次时钟中断，这个初始值由编程的时候指定。

GPU

CUDA

NVIDIA推出的运算平台

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

MCU

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

树莓派

Raspberry Pi（中文名为“树莓派”,简写为RPi），（或者RasPi / RPI） [1] 是为学习计算机编程教育而设计，只有信用卡大小的微型电脑，其系统基于Linux

计算机基础

数据结构

数组

树

二叉树

遍历

先序

中序

后序

层序

二叉树层序遍历

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树

LSM树

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

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

MemTable

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

Immutable MemTable

SSTable(Sorted String Table)

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

链表

队列

Queue

offer，add

添加 add会抛出异常

poll，remove

删除对头元素

peek，element

查询头部元素

栈

堆

图

存储

邻接表

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

邻接矩阵

算法

朴素的算法

归纳演绎法

排序算法

插入排序

选择排序

希尔排序

快速排序

归并排序

堆排序

图算法

多叉树的延伸

图的最短路径

广度优先

深度优先

回溯算法

问题

全排列

N皇后

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

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

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

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

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

迪杰斯特拉算法

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

问题

岛屿问题

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

字符串匹配

暴力算法BF算法

哈希值进行比较的RK算法

KMP

最长可匹配后缀子串

最长可匹配前缀子串

next数组

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

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

动态规划

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

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

三要素

状态转移方程

递推公式

通项公式

备忘录

DP table

重叠子问题

最优子结构

问题

斐波那契数列

凑零钱问题

最长递增子序列

最小编辑距离

背包9讲

01背包

分布式算法

一致性hash

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

余数hash

伸缩性很差

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

hash环

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

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

数据倾斜

虚拟节点机制

加密算法

对称

编码

MD5

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

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

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

3.4*10^38

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

超损压缩

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

BASE64

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

技巧

反转链表（单链表）

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 int maxLength (int[] arr) { Queue<Integer> queue = new LinkedList<>(); int res = 0; for (int c : arr) { while (queue.contains(c)) { queue.poll(); } queue.add(c); res = Math.max(res, queue.size()); } return res; }

翻转字符串

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节点

相交链表

链表的中间节点

操作系统

linux

线上调优

CPU

业务逻辑问题(死循环)

频繁 gc

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

上下文切换过多

使用vmstat命令

vmstat 1

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

对特定的 pid 进行监控

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

方案

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

top -H -p pid

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

printf '%x\n'

jstack 中找到相应的堆栈信息

jstack pid |grep 'nid' -C5 –color

关注 WAITING 、TIMED_WAITING、BLOCKED

磁盘

查看文件系统状态

df -hl

磁盘性能

iostatiostat -d -k -x

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

定位文件读写的来源

iotop

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

cat /proc/pid/io

具体的文件读写情况

lsof -p pid

内存

OOM

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

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

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

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

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

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

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

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

jstack+jmap

Caused by: java.lang.OutOfMemoryError: Meta space

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

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

Stack Overflo

Exception in thread "main" java.lang.StackOverflowError

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

GC 问题

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

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

看下总体线程

通过pstreee -p pid |wc -l。

/proc/pid/task

堆外内存

往往是和 NIO

DirectByteBuffer

OutOfMemoryError: Direct buffer memory。

OutOfDirectMemoryError

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

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

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

gdb

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

网络

火焰图

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

命令

系统查看

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

top 查看附载

cpu过高

查询进程中,那个线程的cpu占用率高记住TID ps -mp pid -o THREAD,tid,time

top -Hp

查看资源占用过高的线程

tar -zxvf 解压

vim

：set nu 显示行号

ln -s 软链接

fdisk -l

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

mount /dev/vdb1 /mnt/data

挂载盘

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

SSH

文件系统

文件描述符

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

文件内核API

文件的打开

int open(const char *pathname, int flags)参数填上要打开的文件的名字（甚至可以不存在），会返回打开的fd

文件的关闭

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

文件定位

off_t lseek(int fd, off_t offset, int whence) 参数whence指定了偏移地址（开始点SEEK_SET 当前点SEEK_CUR 结束点SEET_END），另一个参数offset是从参考点开始的偏移量（可正可负）。返回新的偏移地址。

空洞文件

文件写入

ssize_t write(int fd, const void* buf, size_t nbytes) 返回写入的字节数。一般和nbytes相同。

文件读取

ssize_t read(int fd, void *buf, size_t nbytes) 返回读取到的字节数。

文件属性编辑

int fcntl(int fd, int cmd, ... /* arg */ ) 提供了编辑fd属性标志的方法。

多线程读取

进程中的文件表，记录着进程打开的所有文件。每个文件用了一个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的文件长度，这样就可以写到尾端。

内核的I/O Cache

缓冲区缓存 Buffer Cache

页缓存 Page Cache

buffer和cache区别

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

零拷贝

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

socket buffer

报文数据

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

管理数据

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

swap分区

虚拟内存的磁盘空间

IO事件处理机制

epoll

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

O(1)利用FD的回调

两种模型

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

同时支持 block 和 non-block socket

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

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

只支持no-block socket

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

路径

构建epoll对象

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

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

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

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

poll

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

select

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

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

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

虚拟内存

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

虚拟地址

虚拟地址可通过每个进程的页表与物理地址进行映射,获得真正的物理地址

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

触发缺页中断函数

是否有空闲的物理内存

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

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

有低地址到高地址

只读段

数据段

全局变量、静态变量

堆

动态内存

文件映射区

动态库

栈

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

内核虚拟空间

页表

虚拟地址空间

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

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

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

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

锁

自旋转锁

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

MCS

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

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

CLH

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

概念

同步&异步

异步：内核空间发起IO

同步：用户空间发起IO

阻塞&非阻塞

用户空间执行状态

I/O模型

阻塞式I/O

非阻塞式I/O

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

同步非阻塞

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

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

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

信号驱动式I/O

异步I/O

线程

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

线程的基本状态

新建（new Thread）

就绪（runnable）

运行（running）

堵塞（blocked）

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

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

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

死亡（dead）

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

点对点设计

网络

计算机网络模型

TCP/IP协议

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

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

三次握手

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

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

Client responds with an ACK (acknowledge) message, and the connection is established.

tcp洪流

攻击者使用假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/IP）

数据库读写分离负载

跳板机端口映射

HTTP

HTTP1.0

HTTP1.1

HTTP2.0

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

server pushing

User-Agent

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

状态码

301

永久重定向

302

临时重定向

报文

WebService

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

描述Web服务发布的XML格式

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

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

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

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

Part：消息参数

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

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

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

SOAP（简单对象访问协议）

XML

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

UDDI

管理，分发，查询webService

HTTPS

重定向

客户端两次请求

服务的行为

车载以太网

AVB（音频视频桥接技术）

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

时间同步

调度和流量整形

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

架构设计

应用架构

应用架构发展

单体架构

垂直架构

SOA服务化架构

SOA代表面向服务的架构，将应用程序按照不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。这样将整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有组件通过交互来满足整体的业务需求。服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。这个阶段一般使用Web Service或者Dubbo来服务治理。

SOA和微服务的区别

1.微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以单独对外提供服务

2.微服务不再强调传统SOA架构里面比较重要的ESB企业服务总线

3.微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。

4.微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调HTTP Rest API的方法进行

5.微服务的切分粒度会更小。

微服务

domain driven design DDD

域建模

使用域分析对微服务建模

应该围绕业务功能而不是数据访问或消息传递等水平层来设计微服务

两个阶段

战略

定义系统的大规模结构

战术（策略）

提供一组可用于创建域模型的设计模式

包括实体、聚合和领域服务。借助这些战术模式，可以设计低耦合高内聚的微服务。

步骤

1.分析业务领域

有助于避免组织边界或技术选择左右你的设计

创建的系统的鸟瞰图

构建业务域并创建域模型

在填充关系图时，可以开始标识离散的子域

哪些功能密切相关

哪些功能是业务的核心

哪些功能提供辅助服务

什么是依赖项关系图？

2.定义领域的边界上下文

3.在边界上下文中，应用战术 DDD 模式以定义实体、聚合和域服务。

4.使用前一步骤的结果可以标识应用程序中的微服务

从域模型派生微服务

验证设计

每个服务承担单一责任

服务之间不存在琐碎的调用。

每个服务足够小，独立工作的小团队即可构建它

两个或更多个服务的部署不应该存在相互依赖的关系

服务未紧密耦合，可独立演变

服务边界不会造成数据一致性或完整性方面的问题

几种类型

充血

贫血

分层架构

整洁架构 - Clean Architecture

提出了一种单向依赖关系，从而从逻辑上形成一种向上的抽象系统

洋葱架构

洋葱架构是由多个同心层构成，它们相互连接，并朝向代表领域的核心

CQRS架构（命令查询的责任分离Command Query Responsibility Segregation）

CQRS，全称Command Query Responsibility Segregation。直译过来就是命令查询的职责分离。

Command指的是增加/更新数据的处理。

Query指的是查询数据的处理。它不会造成数据的变更。

COLA 架构（整洁面向对象分层架构 (Clean Object-Oriented and Layered Architecture)）

interface接口层

Facade

外观模式 feignClient接口包含DTO对象独立模块

controller

web层

application应用层

负责接收web层指令，对领域层的逻辑调用。应用层负责将逻辑流程进行组装。而不负责具体的逻辑处理可包含日志，消息，邮件等负责对外转换

ApplicationService

可根据CQRS设计拆分cammand与query

ApplicationServiceImpl

assembler

围绕model到外部DTO的转换类

domain领域层

负责逻辑处理

model

实体

实体逻辑较多的时候，向下拆分值对象

Factory

实例的构造逻辑拆分

值对象

构造方法中进行参数验证

聚合根aggregate

仓库接口

同aggregate对应

可规约模式（Specification）与CQRS冲突

规约模式提倡将验证和查询复用同一个逻辑单元

service

简化可以没有

Infrastructure基础设施

converter

围绕model到外部DO的转换类

Repository

仓库接口的实现

entity

DO(data Object)

mapper

xml

持久化层

领域对象

视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

VO与DTO的区别

DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。

对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。

DTO

展示层与服务层之间的数据传输对象。

DTO与DO的区别

对于一个getUser方法来说，本质上它永远不应该返回用户的密码

为什么不在服务层中直接返回DO呢

两者在本质上的区别可能导致彼此并不一一对应，一个DTO可能对应多个DO，反之亦然，甚至两者存在多对多的关系。

DO具有一些不应该让展示层知道的数据

领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

DO与PO的区别

关系表业务实体等也非一一对应

持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系

六边形架构（端口和适配器）

明确区分应用程序，领域和基础结构三个层

依赖关系是从应用程序和基础结构再到领域

使用端口和适配器隔离它们的边界

Active Record 设计模式

导致制造大量的于数据表对应的类，这些类一般不会有行为，而描述业务逻辑的职责就会到很多service类上

Saga

外交官模式（Ambassador）

可以用与语言无关的方式处理常见的客户端连接任务，如监视，日志记录，路由和安全性（如 TLS）。

反腐层（Anti-corruption layer）

介于新应用和遗留应用之间，用于确保新应用的设计不受遗留应用的限制。

不共享相同语义的不同子系统之间实施外观或适配器层。此层转换一个子系统向另一个子系统发出的请求。使用反腐层（Anti-corruption layer）模式可确保应用程序的设计不受限于对外部子系统的依赖

反腐层（Anti-corruption layer）模式最先由 Eric Evans 在 Domain-Driven Design（域驱动的设计）中描述。

BFF 后端服务前端（Backends for Frontends）

为不同类型的客户端（如桌面和移动设备）创建单独的后端服务。

舱壁模式（Bulkhead）

隔离了每个工作负载或服务的关键资源，如连接池、内存和 CPU。

轮船底下船舱一个个都是互相隔离的，这样一旦哪个舱壁出现漏水也影响不到其他的船舱

Hystrix线程池舱壁模式

网关聚合（Gateway Aggregation）

将对多个单独微服务的请求聚合成单个请求

聚合服务与 BFF有些类似

网关卸载（Gateway Offloading）

网关路由（Gateway Routing）

边车模式（Sidecar）

将应用程序的辅助组件部署为单独的容器或进程以提供隔离和封装。

例：给原有php服务封装一个边车注册在java注册中心

绞杀者模式（Strangler）

通过逐步重构单体应用（而不是推到重来的方式），逐渐构建出一个新的应用程序。

Istio（服务网格）

进化

多语言技术栈不统一：C++、Java、PHP、Go。Spring Cloud无法提出非Java语言的微服务治理。

服务治理周期长：微服务治理框架与业务耦合，上线周期长，策略调整周期长。

Spring Cloud或者Dubbo的成熟框架，直接搞定服务注册，服务发现，负载均衡，熔断等基础功能。然后自己开发服务路由等高级功能，接入Zipkin等Apm做全链路监控，自己做加密、认证、授权。想办法搞定灰度方案，用Redis等实现限速、配额。诸如此类，一大堆的事情，都需要自己做

产品能力弱：Spring Cloud缺乏平台化和产品化的能力，可视化能力弱。

Istio 的出现为负责的微服务架构减轻了很多的负担，开发者不用关心服务调用的超时、重试、Rate Limit 的实现，服务之间的安全、授权也自动得到了保证。

概念

Pilot

为 Envoy 提供了服务发现，流量管理和智能路由（AB 测试、金丝雀发布等），以及错误处理（超时、重试、熔断）功能。用户通过 Pilot 的 API 管理网络相关的资源对象，Pilot 会根据用户的配置和服务的信息把网络流量管理变成 Envoy 能识别的格式分发到各个 Sidecar 代理中。

Mixer

为整个集群执行访问控制（哪些用户可以访问哪些服务）和 Policy 管理（Rate Limit，Quota 等），并且收集代理观察到的服务之间的流量统计数据。

citadel

为服务之间提供认证和证书管理，可以让服务自动升级成 TLS 协议。

Envoy

理论技巧

软件工程

银弹

瀑布

原型

设计模式

创建型模式

单例

构造函数设为私有的

懒汉

类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例。

线程不安全

饿汉

线程安全

类加载时就初始化，浪费内存。

懒汉线程安全

synchronized

双检锁/双重校验锁（DCL，即 double-checked locking）

安全且在多线程情况下能保持高性能。

双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”，

B b = new B();

一部分是new一个B对象,一部分是将new出来的对象赋值给b. 非原子性

登记式/静态内部类

枚举

工厂方法模式

抽象工厂模式

建造者模式

原型模式

结构型模式

适配器Adapter

实现被适配接口，拥有适配的引用

双向适配

装饰器模式

代理模式

外观模式

组合模式

享元模式

桥接模式

行为型模式

策略模式

模板方法模式

观察者模式

迭代子模式

责任链模式

命令模式

备忘录模式

状态模式

访问者模式

中介者模式

解释器模式

高可用

限流

服务降级

熔断

防止雪崩

高并发

队列

缓存

缓存策略

缓存预热

缓存预热是指系统启动后，直接查询热点数据并缓存

缓存更新

先删除缓存，再更新数据库

先更新数据库，再删除缓存

meta

compile code

comprssed class space

feild&Method data

native

JNI Memory

Direct Memory

stack Memory

code cache

JIT Compile

JIT code

基本功能

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

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

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

垃圾回收器

Parallel GC

版本

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

专注

吞吐量

概念

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

概念

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

解释

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

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

ParNew

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

CMS

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

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

步骤

1 初始标记(STW)

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

2 并发标记

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

3 并发预清理

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

4 重标记(STW)

暂停所有用户线程，重新扫描堆中的对象，进行可达性分析,标记活着的对象。有了前面的基础，这个阶段的工作量被大大减轻，停顿时间因此也会减少。注意这个阶段是多线程的。

5 并发清理

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

6 重置

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

1.CMS只能回收老年代

CMS + ParNew

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

版本

JDK6~ 9

专注

平衡

概念

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

解释

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

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

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

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

-XX:MaxGCPauseMillis

设置最大GC停顿时间(GC pause time)指标(target). 这是一个软性指标(soft goal), JVM 会尽量去达成这个目标.

-XX:InitiatingHeapOccupancyPercent

启动并发GC周期时的堆内存占用百分比. G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示"一直执行GC循环". 默认值为 45

-XX:ParallelGCThreads

设置垃圾收集器在并行阶段使用的线程数,默认值随JVM运行的平台不同而不同

XX:G1ReservePercent

ZGC

版本

JDK 15

专注

延迟

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

概念

多重映射

染色指针

子主题 1

读屏障

Shenandoah GC

版本

JDK 12

专注

延迟

跨代引用

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

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

并发过程的对象变化

Full GC

CMS Full GC

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

G1 Full GC

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

TLAB

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

Card Table

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

性能调优

目的

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

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

措施

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

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

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

选择合适的GC收集器

指标

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

ClassLoader

Bootstrap ClassLoader

Extention ClassLoader

Appclass Loader

自定义ClassLoader

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

复写它的findClass()方法。

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

子主题 4

类加载步骤

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

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

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

分配对象

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

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

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

编译

基于栈的指令集架构（Instruction Set Architecture,ISA）

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

字节码

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

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

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

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

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

收集对象

识别垃圾

引用计数法

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

可达性分析

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

收集算法

Mark-Sweep（标记 - 清除）

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

Mark-Compact（标记 - 整理）

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

Copying（复制）

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

分代收集器

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：根据虚方法表调用虚方法。

invokespecial,：调用实例构造方法（方法），私有方法，父类继承方法。

invokeinteface：调用接口方法

invokestatic：调用静态方法

invokedynamic 动态语言支持 lamda

JDK tools

jconsole

jstack -l

jstack(查看线程)、

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

jmap(查看内存)

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

jmap -dump:format=b,file=filename pid来导出 dump 文件

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

jmap -histo pid(查看实例)

jstat(性能分析)

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

监控线程状态

运行

休眠

等待

驻留

监视

版本升级特性

Lambda

依托

匿名内部类（VM Anonymous Class）

invokedynamic

MethodHandle

字节码

常量池

JVM_CONSTANT_InvokeDynamic

JVM_CONSTANT_MethodHandle

JVM_CONSTANT_MethodType

类属性

BootstrapMethods

多一个lambda方法

函数式编程

Optional

Streams

MetaSpace代替了永久代

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

方法引用

String存储结构

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

G1为JVM默认垃圾收集器

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

支持http2.0的API

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

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

ZGC

Flight Recorder（飞行记录器）

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

Shenandoah GC

Switch 表达式表达式

问题排查

进程挂了

查看系统资源情况

Linux进行OOM-killer机制

是否触发OOM

/var/log/message

JVM

dump

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

python

2.x

3.x

基础

列表

元组

字典

语法

classmethod

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

模块

request

HTTP 请求库

BeautifulSoup

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

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

time

pandas

Numpy

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

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

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

.dim

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

.shape

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

.size

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

.dtype

对象的类型

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

数组的创建方法

np.arange(n)

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

np.ones(shape)

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

np.zeros(shape)

根据shape生成一个全0数组

np.full(shape,val)

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

np.eye(n)

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

np.linspace(b,e,n)

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

pathlib

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

typing

Union

类型检查

logging

爬虫

web框架

djingo

flask

语法

if __name__ == '__main__':

文件作为脚本直接执行

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

Anaconda

Anaconda是一个包含180+的科学包及其依赖项的发行版本。其包含的科学包包括：conda, numpy, scipy, ipython notebook等。

channel

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

conda

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

pip

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

c++

MFC

框架组件库

java

spring

AOP

动态代理

CGLIB

fast

JDK

IOC

bean的生命周期

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()方法

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

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

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

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

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

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

注入

变量注入

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

不能有效的指明依赖,对象为null

构造器注入

set方法注入

lang

Nullable

NonNull

NonNullApi

NonNullFields

DependsOn

控制Bean加载顺序

org.springframework

core

ResourceLoader

与ApplicationContext相同的策略

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

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

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

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

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

web.servlet

拦截器（Interceptor）

context

support

AbstractApplicationContext

refresh （）

prepareRefresh()

Prepare this context for refreshing.

obtainFreshBeanFactory()

Tell the subclass to refresh the internal bean factory.

prepareRefresh()

Prepare the bean factory for use in this context.

注册了可解析依赖项

beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory); beanFactory.registerResolvableDependency(ResourceLoader.class, this); beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this); beanFactory.registerResolvableDependency(ApplicationContext.class, this);

DefaultListableBeanFactory.registerResolvableDependency

private final Map<Class<?>, Object> resolvableDependencies;

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

postProcessBeanFactory(beanFactory)

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

invokeBeanFactoryPostProcessors(beanFactory)

Invoke factory processors registered as beans in the context

registerBeanPostProcessors(beanFactory)

initMessageSource()

initApplicationEventMulticaster()

onRefresh()

registerListeners()

finishBeanFactoryInitialization(beanFactory)

finishRefresh()

annotation

EnableAspectJAutoProxy

boolean proxyTargetClass() default false;

默认接口代理

@Import

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

例如@EnableAspectJAutoProxy

导入

@Configuration标注的配置类

例子 @EnableRetry

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

实现ImportSelector接口的类

例如@EnableTransactionManagemen

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

实现ImportBeanDefinitionRegistrar接口的类

例如@EnableAspectJAutoProxy注解

按需注册额外的BeanDefinition

@component类

@Autowired

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

基于 field 注入的坏处

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

依赖注入与容器本身耦合

方法

强制依赖就用构造器方式

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

transaction

TransactionInterceptor

TransactionAspectSupport

interceptor

TransactionAspectSupport

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

invokeWithinTransaction

getTransactionAttribute

获取事务属性

determineTransactionManager(txAttr)

确定事务管理器

createTransactionIfNecessary

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

AbstractPlatformTransactionManager

retVal = invocation.proceedWithInvocation();

调用真实方法

support

AbstractPlatformTransactionManager

abstract Object doGetTransaction()

abstract void doBegin(Object transaction, TransactionDefinition definition)

abstract void doCommit(DefaultTransactionStatus status)

abstract void doRollback(DefaultTransactionStatus status)

TransactionSynchronizationManager

private static final ThreadLocal<Map<Object, Object>> resources

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

jdbc

datasource

DataSourceTransactionManager extends AbstractPlatformTransactionManager

doGetTransaction()

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

beans

factory

support

DefaultListableBeanFactory

springboot

@SpringBootConfiguration

Refresh

@EnableAutoConfiguration

@AutoConfigurationPackage

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

@Import(AutoConfigurationImportSelector.class)

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

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

DeferredImportSelector

getImportGroup

AopAutoConfiguration

2.0.x默认CGlib动态代理

BeanClassLoaderAware

ResourceLoaderAware

BeanFactoryAware

EnvironmentAware

Ordered

判断是否开启自动配置

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

获取所有的配置列表

@ComponentScan

@EnableFeignClients

FeignClientsRegistrar.class

registerFeignClient

registerBeanDefinition

SpringApplication

createApplicationContext

SERVLET

AnnotationConfigServletWebServerApplicationContext

REACTIVE

AnnotationConfigReactiveWebServerApplicationContext

NONE

AnnotationConfigApplicationContext

run

configureHeadlessProperty()

设置java.awt.headless

即使没有检测到显示器,也允许其启动

getRunListeners(args)

getSpringFactoriesInstances

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

EventPublishingRunListener

SimpleApplicationEventMulticaster

listeners.starting()

prepareEnvironment

listeners.environmentPrepared

multicastEvent

configureIgnoreBeanInfo

printBanner

createApplicationContext

prepareContext

refreshContext

ConfigurableApplicationContext.refresh()

见 spring bean加载过程

afterRefresh

listeners.started(context)

callRunners

执行

ApplicationRunner.class

CommandLineRunner.class

listeners.running(context)

ApplicationEvent

SpringApplicationRunListener

context

event

EventPublishingRunListener

AbstractApplicationEventMulticaster

DefaultListenerRetriever

Set<ApplicationListener<?>> applicationListeners

spring-mvc

前端控制器(DispatcherServlet)

doService

doDispatch

RequestMappingHandlerAdapter

处理器映射器(HandlerMapping)

Handler处理器

拦截器

处理器适配器(HandlerAdapter)

视图解析器(ViewResolver)

视图(View)

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

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

基于mvc拦截器

spring-webflux

DispatcherHandler

handle

链式调用

return Flux.fromIterable(this.handlerMappings) // 1.遍历所有的 handlerMapping

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

.switchIfEmpty(createNotFoundError()) .flatMap(handler -> invokeHandler(exchange, handler)) // 3.获取对应的适配器，调用对应的处理器

HandlerAdapter

SimpleHandlerAdapter

webHandler.handle

处理所有过滤器链的方法

filter

globalFilters

负载均衡

LoadBalancerClientFilter

转发路由网关过滤器

ForwardRoutingFilter

HTTP

NettyRoutingFilter

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

NettyWriteResponseFilter

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

websocket

WebsocketRoutingFilter

webclient

WebClientHttpRoutingFilter

WebClientWriteResponseFilter

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

网关适配器

见gatway

.flatMap(result -> handleResult(exchange, result)); // 4.返回处理结果

AbstractHandlerMethodMapping

AbstractUrlHandlerMapping

RouterFunctions

PropertySourcesPropertyResolver

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

Reactor

反应式 HTTP

服务器推送事件

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

reactor-core实现响应式

springcloud

注册中心

cap原理

nacos

DelegateConsistencyServiceImpl

EphemeralConsistencyService

DistroConsistencyServiceImpl

Distro

服务端注册

心跳

特殊场景

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

验证任务startVerifyTask()

同步任务startLoadTask();

纯内存保存

PersistentConsistencyService

RaftConsistencyServiceImpl

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传来的数据删除操作

Raft

consul

zookeeper（见hadoop分支）

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

熔断限流

hystrix

线程隔离

SPI重写线程池获取ThreadLocal值

信号量隔离

hystrix舱壁模式

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

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

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

构建HystrixCommand或HystrixObservableCommand

Connection reset

服务器返回了RST

Connection reset by peer

sentinel

dashboard

限流、隔离、降级、熔断

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

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

ProcessorSlotChain

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

statistic

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

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

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

rule checking

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

SystemSlot：负责系统保护规则

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

FlowSlot：负责限流规则

DegradeSlot：负责降级规则

网关

gateway

actuator

RoutePredicateHandlerMapping

extends AbstractHandlerMapping（spring-webflux）

getHandlerInternal

寻找路由匹配返回 webHandler

lookupRoute

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

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

FilteringWebHandler

implements WebHandler（spring-web）

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

spring-webflux

见 spring

配置

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

servlet

过滤器

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

http

HttpServletResponse

sendRedirect(String url)

HttpServletRequest

netty

概念

模型

NioEventLoopGroup

NioEventLoop

Selector（多路复用器）

注册NioServerSocketChannel

注册NioSocketChannel

组成

管道(SelectableChannel)

选择器(Selector)

选择键(SelectorKey)

Channel

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

Channe

EventLoop

ChannelPipeline

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

sendUpstream

NettyInbound

sendDownstream

ChannelSink

NettyOutbound

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

ChannelHandler

ChannelUpstreamHandler

ChannelDownstreamHandler

客户端

ClientGroup

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

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

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

服务端

BossGroup

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

创建一个NioSocketChannel实例

ServerBootStrapAcceptor

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

WorkGroup

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

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

IO事件类型

SelectionKey.OP_READ

SelectionKey.OP_WRITE

SelectionKey.OP_ACCEPT

SelectionKey.OP_CONNECT

多线程的Reactor模式

BossGroup

对应 mainReactor

WorkGroup

对应 subReactor

多路复用

NioEventLoop

EpollEventLoop

reactor

core

publisher

Flux

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

just

Mono

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

mybatis

结果嵌套

collection

执行流程

SqlSessionFactoryBuilder（构造器）

SqlSessionFactory：依靠工厂来生成SqlSession。

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

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

组成

日志

异常

缓存

解析

org.apache.ibatis.parsing

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

类型处理器

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

绑定

注解

映射

执行器

事务

org.apache.ibatis.transaction org.apache.ibatis.transaction.jdbc org.apache.ibatis.transaction.managed

数据源

会话

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

BindingException

Invalid bound statement (not found)

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

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

Mapper.xml没有构建进去

配置文件导不出来

mapper-locations 配置 xml

org

generator

apache.ibatis

exceptions

PersistenceException

session

defaults

selectList（）

executor

Executor

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

CachingExecutor

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

BaseExecutor

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

SimpleExecutor

BatchExecutor

plugin

Plugin

interceptor

Interceptor

MybatisPlusInterceptor（mybaits-plus实现）

PageInterceptor（pagehelper实现）

PaginationInterceptor（mybatis-plus作废的实现）

mybatis

spring

SqlSessionTemplate

mybatisplus

com.baomidou.mybatisplus

extension

plugins

PaginationInterceptor

protected long limit = 500L;

Druid

源码

getConnectionDirect

Exception

GetConnectionTimeoutException

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

配置

initialSize

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

maxActive

最大连接池数量

minIdle

最小连接池数量

maxWait

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

poolPreparedStatements

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

testOnBorrow

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

默认 true

testOnReturn

默认 false

timeBetweenEvictionRunsMillis

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

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

testWhileIdle

transaction

TX-LCN

锁定事务单元（lock）

确认事务模块状态(confirm)

通知事务(notify)

Seata

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 对应的全局事务下的所有分支事务完成分支提交或回滚。

MetricsMonitor

监控

google-guava

multimap

multiset

mysql-connect-java

ConnectionImpl

log

logback

标签

scan

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

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

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

常用的 appender 类型

RollingFileAppender

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

对日志进行格式化

rpc

gRPC

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

Dubbo

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

泛化调用

json

fastjson

JSONPath

使用表达式访问Json数据

Jackson

JsonTypeInfo

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

JSqlParser

reflections

python

Keras

TensorFlow

内核功能

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

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

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

指数核。

拉普拉斯内核。

方差分析内核。

乙状结肠

Wave内核

三角核

日志内核

mne

数据结构

Raw

Raw对象主要用来存储连续型数据，核心数据为n_channels和times,也包含Info对象。

Epochs

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

创建Epochs对象方式

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

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

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

Evoked

Evoked potential(EP)诱发电

dataset

sleep_physionet

参考电极

子主题 1

torch

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

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

张量 Tensors

torch.optim

优化算法的库

adam

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

适应性梯度算法（AdaGrad）

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

均方根传播（RMSProp）

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

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

util

data

DataLoader

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

torch.nn

nn.DataParallel

多个GPU来加速训练

sklearn

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

监督学习

广义线性模型

普通最小二乘法

LinearRegression 拟合一个带有系数 w = (w_1, ..., w_p) 的线性模型，使得数据集实际观测数据和预测数据（估计值）之间的残差平方和最小。其数学表达式为:

pipeline

NumPy

OpenCV

Scikit-learn

Pandas

Matplotlib

PyTorch

PaddlePaddle

服务器

resin

nginx

反向代理

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

负载均衡

限流

证书配置

缓冲区

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

嵌套Frame

X-Frame-Options

架构

事件驱动架构

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

epoll 模型

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

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

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

静态文件

sendfile

零拷贝

tomcat

架构

顶层容器 server

包含多个服务 service

service

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

Connector

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

ProtocolHandler

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

Endpoint

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

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

Processor

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

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），后者用于处理外部扩展的升级协议支持。

Adapter

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

coyote

Coyote是Tomcat链接器框架的名称

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

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

Container

Catalina servlet容器

Engine

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

Host

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

Context

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

Wrapper

每一Wrapper封装着一个Servlet；

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

Pipeline-Value是责任链模式

模式

BIO

NIO

基于JDK的java.nio包

APR

CGI

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

select 模型

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

参数

maxThreads

acceptCount

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

CDN

回源

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

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

•回源域名

工作方法

•回源域名

边缘层

中心层

源站

http标准协议

数据库

nosql

redis

单线程

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

数据结构

String（字符串）

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

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

哈希（Hash）类型:(map<string,string>)

用户信息

List类型

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

时间轴、简单队列

set类型

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

赞、踩

Sorted-Sets类型

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

排行榜

位图

HLL

GEO（地理信息）

设计

链表

字典

跳跃表

底层结构

跳跃列表（skipList）

stream

添加消息

xadd mystream * name zhangsan age 18;

创建消费组

xgroup create mystream cg1 $

消费消息

xreadgroup group cg1 godconsumer streams mystream >

ACK

xack mystream cg1 1636612497298-0

查询未消费消息

XPENDING mystream cg1

设计

Consumer Group

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

last_delivered_id

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

pending_ids

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

多路 I/O 复用机制

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

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

持久化

RDB 全量持久化

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

AOF 增量持久化

数据迁移方式

aof（日志文件）

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

rdb（快照文件）

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

replication（主从复制）

淘汰策略

FIFO 淘汰最早数据

First In First Out，先进先出。

LRU 剔除最近最少使用

Least Recently Used，最近最少使用。

LFU 剔除最近使用频率最低

Least Frequently Used，最不经常使用。

指令

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

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

volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。

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

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

volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。

删除策略

定期删除

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

惰性删除

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

高可用

Sentine l哨兵

数据不一致

异步补偿

跳表

事务

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

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

不保证原子性

Lua脚本

没有隔离级别

且没有回滚

命令

watch key1 key2 ... : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断（类似乐观锁）

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

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

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

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

redlock 红锁

多套环境

Tair

neo4j

mysql

逻辑架构

服务层

Binary log

解释器

优化器

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

索引扫描

核心服务

存储引擎

引擎事务日志

系统文件层

引擎

InnoDB

插入缓冲（insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)

系统内部字段

主键ID

事务ID

回滚指针

数据库事务

原理

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

trx_sys

事务链表和集合

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所对应的事务对象创建记录锁，通过该集合可以快速获得事务对象

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

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

事务回滚段

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

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

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

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

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

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

事务特性

Atomicity(原子性)

undo log

Consistency （一致性）

doublewrite buffer

保证数据页的准确性

crash recovery

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

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

Isolation(隔离性)

读未提交(READ UNCOMMITED)

脏读

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

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

读已提交(READ COMMITTED)

不可重复读

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

每次select都生成一个快照读

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

可重复读(REPEATABLE READ)

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

幻读（当前读）

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

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

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

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

序列化(SERIALIZABLE)

Durability(持久性)

WAL（Write-Ahead Logging）的原则

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

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

事务类型

只读事务

读写事务

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

事务开启

BEGIN

START TRANSACTION READ ONLY

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

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

START TRANSACTION READ WRITE

START TRANSACTION WITH CONSISTENT SNAPSHOT

innobase_start_trx_and_assign_read_view

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

AUTOCOMMIT = 0

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

事务回滚

回滚的方式是提取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子系统，则主要用于在事务提交后，进行垃圾回收，以及数据页的无效数据清理。

事务ID

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

多版本并发控制MVCC

undo日志

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

Readview

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

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

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

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

快照读

当前读

加排他锁

间隙锁

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

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

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

场景

update ... (更新操作)

delete ... (删除操作)

insert ... (插入操作)

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

select ... for update (写锁)

可见性判断

聚集索引

二级索引

锁

表锁

LOCK_X（排他锁）

LOCK_S（共享锁）

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

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

行锁

记录锁(RK)

LOCK_REC_NOT_GAP

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

类型

间隙锁(GK) LOCK_GAP

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

LOCK_ORDINARY(Next-Key Lock)

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

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

INSERT INTENTION锁是GAP锁的一种，如果有多个session插入同一个GAP时，他们无需互相等待，例如当前索引上有记录4和8，两个并发session同时插入记录6，7。他们会分别为(4,8)加上GAP锁，但相互之间并不冲突（因为插入的记录不冲突）。

隐式锁

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

存储

页

16k

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

Row size too large (> 8126).

最小存储单元

推荐自增 id 做主键

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

指针

6字节

text

64K

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

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

流程

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

buffer pool

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

LOB

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

8.0前

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

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

8.0

LOB index 来索引 LOB page

MVCC

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

参数

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

sync_binlog

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

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

innodb_flush_log_at_trx_commit

它控制了重做日志（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中

MyISAM

区别

InnoDB支持事务，MyISAM不支持

InnoDB支持外键，而MyISAM不支持

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

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

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

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

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

因为InnoDB的事务特性

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

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

sql

select

from

join

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

Simple Nested-Loop Join

Index Nested-Loop Join

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

Block 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。

Sort Merge Join

Hash Join

where

order by

limit

group by

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

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

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

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

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

使用临时表实现 GROUP BY

having

with

MySQL8的新特性CTE

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

parttion by

Replace into

并发死锁

约束

主键约束

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

唯一约束

某一列或多个列不能有相同的两行或者两行以上的数据存在，和主键约束不同，唯一约束允许为NULL，只是只能有一行

非空约束

外键约束

索引

唯一索引

可以为NULL

状态检查

show processlist

state

Sending data

Writing to net

wait_timeout

8小时问题

用户量小

修改配置

用户量大

修改数据库连接池check连接时间

查看事务

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条件和order by同时出现时，如果where中字段A使用了索引，而order by的字段是B，查看执行计划时，就会出现filesort文件排序

8.X新特性

速度2倍

窗口函数

parttion

隐藏索引

降序索引

通用表表达式(Common Table Expressions CTE)

在复杂的查询中使用嵌入式表时，使用 CTE 使得查询语句更清晰。

可靠性

InnoDB 现在支持表 DDL 的原子性

日志

binlog

格式

Statement

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

Row

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

缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。

Mixed

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

查看

show binlog events;

【Log_name】:日志名称

【pos】上次操作点的序号

【event_type】事件类型

TABLE_MAP_EVENT

FORMAT_DESCRIPTION_EVENT

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

ROTATE_EVENT

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

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

QUERY_EVENT

记录更新操作的语句

ROWS_EVENT

WRITE_ROWS_EVENT

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

UPDATE_ROWS_EVENT

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

DELETE_ROWS_EVENT

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

XID_EVENT

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

GTID_LOG_EVENT

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

PREVIOUS_GTIDS_LOG_EVENT

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

STOP_EVENT

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

日志解析

# 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' /*!*/;

postion（描述）

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

timestamp（事件发生的时间戳）

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

server id（服务器标识）

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

end_log_pos（结束字节数）

结束的字节位置639

Query（类型）

事件类型。

thread_id

处理的线程编号(13)

exec_time

执行花费的时间

error_code

错误码

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

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

删除binlog

(1) 使用reset master,该命令将会删除所有日志，并让日志文件重新从000001开始。

（2）使用命令

purge master logs to "binlog_name.00000X"

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

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

事务日志

redo

存储

redo log block

512字节

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

组成

日志头

12字节

日志体

492字节

日志尾

8字节

undo

作用

旧版本数据读取

purge时扫描undo log record

崩溃恢复时扫描undo log record

大事务回滚

存储

undo log segment

回滚

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

binlog 与事务日志一致性

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

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

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

两种XA事务方式

隐式XA

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

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

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

显式XA

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

崩溃提交或回退

binlog与 redolog的顺序性

5.6前

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

5.6

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

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

流式查询

分页对sql要求高

tidb

SQL

JOIN

CROSS JOIN

交叉连接，计算笛卡儿积

INNER JOIN

内连接，返回满足条件的记录

OUTER JOIN

LEFT

返回左表所有行，右表不存在补NULL

RIGHT

返回右表所有行，左边不存在补NULL

FULL

返回左表和右表的并集，不存在一边补NULL

SELF JOIN

自连接，将表查询时候命名不同的别名。

中间件与容器

ActiveMQ

RabbitMQ

convertAndSend

convertSendAndReceive

当确认了所有的消费者都接收成功之后，才触发另一个convertSendAndReceive(…)，也就是才会接收下一条消息。RPC调用方式

持久化

事务

高并发、持久化、支持集群、社区活跃、综合技术

client

Channel

basicAck

basicNack

顺序性

多个队列或者单个消费

防止重复

幂等

为什么会重复

网络延迟

confirm模式

概念

Binding

一套绑定规则，用于告诉Exchange消息应该被存储到哪个Queue。

Exchange交换器

DIRECT

直连

FANOUT

广播

TOPIC

一个队列多个模糊匹配多个 routingkey

HEADERS

Queue

Routing Key

生产者在向Exchange发送消息时，需要指定一个Routing Key来设定该消息的路由规则。 Routing Key需要与Exchange类型及Binding Key联合使用才能生效

由于消费者读取消息之后可能会把消息放回（或者重传）到队列中（例如，处理失败的情况），这样就会导致消息的顺序无法保证。

当开发复杂的软件系统时，我们可能被诱导使用同一个消息平台去实现所有必须的消息用例。但是，从我的经验看，通常同时使用这两个消息平台能够带来更多的好处。例如，在一个事件驱动的架构系统中，我们可以使用RabbitMQ在服务之间发送命令，并且使用Kafka实现业务事件通知。原因是事件通知常常用于事件溯源，批量操作（ETL风格），或者审计目的，因此Kafka的消息留存能力就显得很有价值。相反，命令一般需要在消费者端做额外处理，并且处理可以失败，所以需要高级的容错处理能力。

virtual host

RocketMQ

Kafka（见hadoop分支）

经验

AMQP协议

amqp的事务机制

为什么用

解耦、异步、削峰

缺点

系统可用性降低

系统复杂度提高

一致性问题

高可用

重复消费

幂等性

Elasticsearch

基本概念

索引

类型

文档

元数据

_index

_type

_id

词条（Term）

索引里面最小的存储和查询单元，对于英文来说是一个单词，对于中文来说一般指分词后的一个词。

词典（Term Dictionary）

或字典，是词条 Term 的集合。搜索引擎的通常索引单位是单词，单词词典是由文档集合中出现过的所有单词构成的字符串集合，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。

倒排表（Post list）

一个文档通常由多个词组成，倒排表记录的是某个词在哪些文档里出现过以及出现的位置。

倒排文件（Inverted File）

所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件被称之为倒排文件，倒排文件是存储倒排索引的物理文件。

映射（Mapping）

映射是用于定义 ES 对索引中字段的存储类型、分词方式和是否存储等信息，就像数据库中的 Schema ，描述了文档可能具有的字段或属性、每个字段的数据类型。

Text

Text 用于索引全文值的字段，例如电子邮件正文或产品说明。这些字段是被分词的，它们通过分词器传递，以在被索引之前将字符串转换为单个术语的列表。

分析过程允许 Elasticsearch 搜索单个单词中每个完整的文本字段。文本字段不用于排序，很少用于聚合。

Keyword

Keyword 用于索引结构化内容的字段，例如电子邮件地址，主机名，状态代码，邮政编码或标签。它们通常用于过滤，排序，和聚合。Keyword 字段只能按其确切值进行搜索。

搜索

确切值

全文文本

将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。

倒排索引

由文档中出现的唯一单词列表以及每个单词在文档中的位置决定

每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合。例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。

倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。

must

should

must not

写数据

客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）

　shard = hash(document_id) % (num_of_primary_shards)

coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。[路由的算法是？]

当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem 　　Cache的过程就叫做refresh；

flush

　当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；

　flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；

lucene

lucene 就是一个 jar 包，里面包含了封装好的各种建立倒排索引的算法代码

全文检索引擎

更新和删除文档

磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。

在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

集群

发现机制

ES 内部是如何通过一个相同的设置 cluster.name 就能将不同的节点连接到同一个集群的？答案是 Zen Discovery。

存储原理

优化

translog flush

默认设置下,translog 的持久化策略为:每个请求都flush:

refresh_interval

默认情况下索引的refresh_interval为1秒,这意味着数据写1秒后就可以被搜索到,每次索引的 refresh 会产生一个新的 lucene 段,这会导致频繁的 segment merge 行为,如果你不需要这么高的搜索实时性,应该降低索引refresh 周期

分词器

中文分词

中文分词有特定的难点，不像英文，单词有自然的空格作为分隔，在中文句子中，不能简单地切分成一个个的字，而是需要分成有含义的词

支持自定义词库，支持热更新分词字典

jieba

Python 中最流行的分词系统，支持分词和词性标注

THULAC

清华大学自然语言处理和社会人文计算实验室的一套中文分词器

Standard Analyzer - 默认分词器，按词切分，小写处理 Simple Analyzer - 按照非字母切分（符号被过滤），小写处理 Stop Analyzer - 小写处理，停用词过滤（the ，a，is） Whitespace Analyzer - 按照空格切分，不转小写 Keyword Analyzer - 不分词，直接将输入当做输出 Pattern Analyzer - 正则表达式，默认 \W+ Language - 提供了 30 多种常见语言的分词器 Customer Analyzer - 自定义分词器

Logstash

Kibana

Kubernetes

容器和集群管理的标准

YAML 文件规定了组成一个应用所需的容器和其他资源。Kubernetes 提供了调度、伸缩、服务发现、健康检查、密文管理和配置管理等功能。

架构

节点代理kubelet

负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；

Master组件(APIs, scheduler, etc)

etcd

保存了整个集群的状态

apiserver

提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

controller manager

负责维护集群的状态，比如故障检测、自动扩展、滚动更新等

scheduler

负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上

kube-proxy

负责为Service提供cluster内部的服务发现和负载均衡

Container runtime

负责镜像管理以及Pod和容器的真正运行（CRI）

分层架构

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）

管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）

接口层：kubectl命令行工具、客户端SDK以及集群联邦

生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等

Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

安装方式

kubeadm

kubeflow 机器学习（ML）工作流程

概念

Kubernetes 集群是由多个计算机（可以是物理机、云主机或虚拟机）组成的一个独立系统，通过 Kubernetes 容器管理系统，实现部署、运维和伸缩 Docker 容器等功能，它允许您的组织对应用进行自动化运维。

node agent（kubelet）

Pod

容器

使用GPU

k8s device plugin

不支持GPU的共享和隔离

Helm

包管理工具

主流的Kubernetes集群管理平台

rancher

Rancher的核心竞争力在于其强大的多集群管理能力，提供了极其简便的K8s部署及管理能力。同时提供了集成开源监控、日志、Git CI的能力，虽然学习成本较高，但提供了一站式的解决方案，对运维更加友好。

提供Kubernetes、Mesos和Swarm三种调度工具的企业级分发版和商业技术支持的容器管理平台

Kubesphere

KubeSphere定位是以应用为中心的容器平台，提供简单易用的操作界面，一定程度上降低了学习成本，同时集成了原生istio等功能，更加符合开发的使用习惯。

seldon

seldon 通过将你的模型部署为K8S上的微服务，来提供 HTTP/GRPC 接口给业务调用。

基于 K8S 的集成的模型部署方案，内置了很多通用的例如 tfserving、 sklearn server、mlflow server、triton这样的模型推理服务器(inference server)。除了这些还可以通过自己实现自定义的 inference server 提供一些额外的模型服务支持。

docker

容器打包和运行时系统的标准

主要用于管理各个节点上的容器。开发者在 Dockerfiles 中构建容器镜像，上传到镜像仓库中，用户只需从镜像仓库下载该镜像文件，就可以开始使用。

serverless

faas （function as a service）

微虚机

Firecracker

Prometheus

指标暴露

PushGateWay

Prometheus 再从这个网关里 Pull 指标

Exporter

指标抓取

Pull 模型

Push 模型

存储和可视化

内置的时序数据库

PromQL

监控告警

alertmanageer 基于 promql 来做系统的监控告警

工作原理

服务注册

静态注册：静态的将服务的 IP 和抓取指标的端口号配置在 Prometheus yaml 文件的 scrape_configs 配置下

动态注册：动态注册就是在 Prometheus yaml 文件的 scrape_configs 配置下配置服务发现的地址和服务名，Prometheus 会去该地址，根据你提供的服务名动态发现实例列表，在 Prometheus 中，支持 consul，DNS，文件，K8s 等多种服务发现机制。

配置更新

Metric 指标

攻击

XSS (Cross Site Script) ，跨站脚本攻击

它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入的恶意html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。但是随着前端技术的不断进步富客户端的应用越来越多，这方面的问题越来越受关注。举个简单例子：假如你现在是sns站点上一个用户，发布信息的功能存在漏洞可以执行js 你在此刻输入一个恶意脚本，那么当前所有看到你新信息的人的浏览器都会执行这个脚本弹出提示框（很爽吧弹出广告：）），如果你做一些更为激进行为呢后果难以想象。

CSRF(Cross Site Request Forgery)，跨站点伪造请求

让用户以自己的身份来完成攻击者需要达到的一些目的。csrf 的攻击不同于xss csrf 需要被攻击者的主动行为触发。这样听来似乎是有“被钓鱼”的嫌疑哈哈。

DoS

tcp

udp

DDoS

文件上传漏洞

SQL

内联注入

N/ A

触发数据库返回错误。

' OR '1' = '1

') OR ('1' = '1

永真，返回所有行。

value' OR '1' = '2

value') OR ('1' = '2

空，不影响返回结果。

' AND '1' = '2

') AND ('1' = '2

永假，返回空。

' OR 'ab' = 'a''b

') OR ('ab' = 'a''b

字符串连接，结果同永真。

实例

用户名输入

' OR 1 = 1 OR '1' = '1

SELECT * FROM usertable WHERE username = '' OR 1 = 1 OR '1' = '1' AND password = ''

密码输入

' OR '1' = '1

SELECT * FROM usertable WHERE username = '' AND password = '' OR '1' = '1'

软实力

商业

IPD(集成的产品开发)

强调公司对产品开发的有效投资组合分析

PDT

Product Development Team，产品开发团队，执行产品开发项目。

业务计划

LPDT（PDT经理）

IPMT（集成产品组合管理团队）

salesforce商业模式

商业画布

提供什么

价值主张

为谁提供

客户关系

营销渠道

客户细分

如何提供

关键业务

核心资源

合作生态

盈利模式

成本结构

收入来源

产品

产品的定位

用户是谁

差异点

单点突破

生态

多个不同的角色互相依赖、和谐共处、不断进化

不同角色的“权责利”

商业变现的机制

利益反馈

产品体验

“最简单、最直观”的体验

到具体的场景中去设计和检验产品

从用户的行为而不仅是口中获得产品反馈

埋点

品味和颜值

产品自传播

眼里不要只有“产品功能”，更要多多考虑“人”

管理

人员

选

育

有挑战的工作

团队知识分享

用

okr、kpi

留

市场薪资调研

分支主题

离

和平的分手

软实力

二八原则

点评日报予以肯定

项目

任务拆分

燃尽图

deadline

领导梯队

不断的重新定义岗位角色

领导力转型

管理工具

金字塔原理

思维导图

定目标

SMART原则

汇报

STAR原则

人员管理

OKR

OKR适用于实现目标方法不是特别清晰不太成熟的岗位

研发性岗位

1.设定目标

（1）全员设定。公司、部门、管理者和员工均从战略开始设定自己的年度目标和季度目标。

（2）从上至下。目标的设立顺序应该是公司到部门到组到个人。

（3）目标共识。目标必须是在管理者与员工直接充分沟通后的共识

（4）目标具体可衡量。

（5）有野心的目标。

（6）目标不能过多，员工通常每季度制定4到6个

2、针对每个目标设定其KR(关键结果)

（1）目标要有年度KRs，也有季度KRs。年度KRs统领全年，但并非固定不变，而是可以及时调整，调整要经过批准；季度KRs则是一旦确定就不能轻易改变的。

（2）可以调整的是KRs，目标不能调整。措施和方法（KRs）可以不断完善，且KRs的设定也应是管理者与员工直接充分沟通后的共识，以员工确认为主。

（3）KR是须具备的特点：必须是能直接实现目标的；必须具有进取心、敢创新的，可以不是常规的；必须是以产出或者结果为基础的、可衡量的，并设定评分标准；不能太多，一般每个目标的KR不超过4个；必须是和时间相联系的。

3、推进执行（从关键结果到“行动计划“）

（1）每项关键结果就会派生出一系列的任务，交给不同的同事负责。

（2）关键结果负责人就成了名符其实的项目经理，来组织协调大伙。

（3）关键结果的项目经理是团队非常重要的成员，他们应能够调度和影响企业资源。如果他还不具备这个权力，就把这个权力给他；

4、OKR回顾，与绩效评估

KPI

KPI适用于一些工作目标和措施都比较明确和成熟的岗位

制造业的一线操作岗位

选了错误的KPI

无法制订KPI

没有人对最终结果负责

团队管理

戴明环

工具

ETL

kettle

IDE

idea

eclipse

运维&CI

Jenkins

ansible

maven

生命周期

package

install

更新本地仓库

deploy

更新远程和本地仓库

modules

properties

dependencyManagement

dependencies

dependency

依赖

路径长度相同

同一个pom

如果在同一pom.xml文件中有2个相同的依赖；后面声明的会覆盖前面的依赖

不同pom

在不同pom.xml中有2个相同的依赖；则先声明的依赖，会覆盖后面生命的依赖

路径最短优先原则

存在两个项目依赖同个类型但不同版本的jar包，这个时候会优先选择路径短的

scope 域

compile 默认

当依赖的scope为compile的时候，那么当前这个依赖的包，会在编译的时候被加入进来，并且在打包（mvn package）的时候也会被加入进来。编译范围有效，在编译与打包时都会加入进去。

provided

当依赖的scope为provided的时候，在编译和测试的时候有效，在执行（mvn package）进行打包时不会加入。

在编译时我们需要依赖servlet-api.jar，但是在运行时我们不需要该 jar包，因为这个jar 包已由web服务器提供，如果在打包时又被加入进去，那么就可能产生冲突。此时我们就可以使用 provided 进行范围修饰。

system

与provided相同，不过被依赖项不会从maven仓库获取，而是从本地文件系统拿，需要配合systemPath属性使用。

<systemPath>${basedir}/WebContent/WEB-INF/lib/open-core.jar</systemPath>

runtime

当依赖的scope为runtime的时候，在运行的时候才会依赖，在编译的时候不会依赖。比如，在编译的时候我们不需要JDBC API的jar包，而在运行的时候我们才需要JDBC驱动包。就可以使用runtime修饰。

test

当依赖的scope为test的时候，指的的是在测试范围有效，在编译与打包的时候都不会使用这个依赖。

import

依赖上的多重继承

repositories

pluginRepositories

build

pluginManagement

plugins 下的 plugin 是真实使用的，而 pluginManagement 下的 plugins 下的 plugin 则仅仅是一种声明

plugins

<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>

packaging

parent

modelVersion

groupId

artifactId

version

name

低代码

宜搭

表单

流程

报表

连接平台

酷数据

数据大屏

添加到群

测试

压测

jmeter

postman

项目管理

tapd

禅道

jira

接口管理

yapi

swagger

代码版本控制

git

rebase

merge

svn

监控

监控指标

链路追踪

SkyWalking

APM

探针

听云

zabbix

页面截图

phantomjs

大数据

hadooop

环境搭建

HA集群

源码

hadoop-mapreduce-project

hadoop-mapreduce-client

hadoop-mapreduce-client-core

Mapper.java

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作业

All intermediate values associated with a given output key are subsequently grouped by the framework, and passed to a {@link Reducer} to determine the final output. Users can control the grouping by specifying a <code>Comparator</code> via {@link JobConf#setOutputKeyComparatorClass(Class)}. 与给定输出键关联的所有中间值随后由框架进行分组，并传递给Reduce以确定最终输出。用户可以通过{@link jobconf# setOutputKeyComparatorClass(Class)}指定Comparator来控制分组。

Comparator

Users can optionally specify a <code>combiner</code>, via {@link JobConf#setCombinerClass(Class)}, to perform local aggregation of the intermediate outputs, which helps to cut down the amount of data transferred from the <code>Mapper</code> to the <code>Reducer</code>. 用户可以选择指定一个combiner，通过 jobconf#setCombinerClass以执行本地聚合中间输出，有助于减少从mapper到reduce的数据传输

combiner

优化

配置优化

core-site.xml

fs.trash.interval 垃圾箱清理文件间隔

dfs.namenode.handle.count hadoop启动任务线程数

mapreduce.tasktraker.http.threads map和reduce之间通过http传输数据传输的并行线程数

系统优化

代码优化

combiner的个数尽量同reduce相同，数据类型保持一直，可以减少拆包和封包进度

HDFS

核心模块

namenode节点

namenode挂了。先分析宕机后的损失，宕机后直接导致client无法访问，内存中的元数据丢失，但是硬盘中的元数据应该还存在，如果只是节点挂了，重启即可，如果是机器挂了，重启机器后看节点是否能重启，不能重启就要找到原因修复了。但是最终的解决方案应该是在设计集群的初期就考虑到这个问题，做namenode的HA。

datanode节点

Datanode宕机了后，如果是短暂的宕机，可以实现写好脚本监控，将它启动起来。如果是长时间宕机了，那么datanode上的数据应该已经被备份到其他机器了，

secondarynamenode

sn的主要职责是执行checkpoint操作

每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地

客户端

HDFS协议（RPC协议、流式接口协议:HTTP和TCP）

mapreduce

Mapper任务过程

第一阶段是把输入文件按照一定的标准分片(InputSplit)，每个输入片的大小是固定的。默认情况下，输入片(InputSplit)的大小与数据块(Block)的大小是相同的。如果数据块(Block)的大小是默认值64MB，输入文件有两个，一个是32MB，一个是72MB。那么小的文件是一个输入片，大文件会分为两个数据块，那么是两个输入片。一共产生三个输入片。每一个输入片由一个Mapper进程处理。这里的三个输入片，会有三个Mapper进程处理。

第二阶段是对输入片中的记录按照一定的规则解析成键值对。有个默认规则是把每一行文本内容解析成键值对。“键”是每一行的起始位置(单位是字节)，“值”是本行的文本内容。

第三阶段是调用Mapper类中的map方法。第二阶段中解析出来的每一个键值对，调用一次map方法。如果有1000个键值对，就会调用1000次map方法。每一次调用map方法会输出零个或者多个键值对。

第四阶段是按照一定的规则对第三阶段输出的键值对进行分区。分区是基于键进行的。比如我们的键表示省份(如北京、上海、山东等)，那么就可以按照不同省份进行分区，同一个省份的键值对划分到一个区中。默认是只有一个区。分区的数量就是Reducer任务运行的数量。默认只有一个Reducer任务。

第五阶段是对每个分区中的键值对进行排序。首先，按照键进行排序，对于键相同的键值对，按照值进行排序。比如三个键值对<2,2>、<1,3>、<2,1>，键和值分别是整数。那么排序后的结果是<1,3>、<2,1>、<2,2>。如果有第六阶段，那么进入第六阶段；如果没有，直接输出到本地的linux文件中。

第六阶段Reducer任务过程

决定Mapper的数量 HDFS中数据的存储是以块的形式存储的，数据块的切分是物理切分，而split是在Block的基础上进行的逻辑切分。每一个split对应着一个Mapper进程。每个Split中的每条记录调用一次map方法。一个文件被切分成多少个split就有多少个Mapper进程。

Reducer任务过程

每个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进行规划，由人来决定。

shuffle

将maptask输出的处理结果数据，分发给reducetask，并在分发的过程中，对数据按key进行了分区和排序；

map的主要输入是一对<key , value>值，经过map计算后输出一对<key , value>值；然后将相同key合并，形成<key , value集合>；再将这个<key , value集合>输入reduce，经过计算输出零个或多个<key , value>对。

yarn

资源调度

ResourceManager

ApplicationMaster

NodeManager

container

问题处理

datanode首次加入cluster时候版本号不一致

hive

hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。

架构

用户接口/界面

元存储

HiveQL处理引擎

执行引擎

HDFS 或 HBASE

内部表

外部表

分区表

分桶表

视图

索引

hbase

核心概念

Row Key(行键)

Column Family(列族)

Column Qualifier(列限定符)

Column(列)

Cell

集群架构

HMaster

Region Servers

Row Key 设计原则

唯一原则

Key-Value存储会覆盖

排序原则

HBase的Rowkey是按照ASCII有序设计的

散列原则

Region热点问题

Reverse反转

Salt加盐

Mod

长度原则

Rowkey是一个二进制，Rowkey的长度被很多开发者建议说设计在10~100个字节，建议是越短越好

zookeeper

分布式的，开放源码的分布式应用程序协调服务文件系统+监听通知机制

安装部署

zoo.cfg配置

tickTime

这个属性表示心跳时间间隔，Leader用来监听Follower的心跳，一旦挂掉一半以上Follower，会通过Zab(消息原子广播)协议使集群所有个体状态转变为Looking（等待选举新任Leader）。此属性除了用来监听之外，还对后面的同步时间和初始化时间有影响，系统默认为2000毫秒。

initLimit

集群中的follower服务器与Leader服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），系统默认为10。

syncLimit

集群中Follower服务器跟Leader服务器之间的请求和答应最多能容忍的心跳数（tickTime的数量），系统默认为5。

dataDir

此属性表示一个路径，用来存放数据快照（即zookeeper目录）、myid文件和日志文件夹，系统默认为/tmp/data，根据自己zk安装路径进行修改并创建data目录。

clientPort

zk客户端端口号，默认2181。

dataLogDir

用来存放zk写日志。

server.index=IP:A:B

此处是关于zk集群的配置，index代表自定义的各服务器序号（对应写在各自机器的myid中），IP即各服务器IP，A表示集群服务器之间通讯组件的端口，B表示选举组件的端口。如果配成集群，则zk状态（mode）为leader或follower；如果只配一个单机，mode为standalone。

各节点角色

leader

follower

observer

ZNODE

永久节点

临时节点

有序节点

ACL权限

Permissions

Schemes

curator

会话

Watcher

核心原理

ZAB协议

崩溃恢复

消息广播

paxos算法

发布订阅

分布式锁

master选举

kafka

概念

Topics And Partition(主题与分区)

topic通过文件存储，partition是目录

消息是顺序append log方式存储

分区在存储层面可以看作一个可追加的日志（Log）文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量（offset）。

消息冗余多台beoker存储，多台机器就叫一个replica集合

replica集合中，需要选出1个leader，剩下的是follower。也就是master/slave。

offset回退机制

消息会存放一个星期，才会被删除。并且在一个partion里面，消息是按序号递增的顺序存放的，因此消费者可以回退到某一个历史的offset，进行重新消费。

offset 是消息在分区中的唯一标识，Kafka 通过它来保证消息在分区内的顺序性，不过 offset 并不跨越分区，也就是说，Kafka 保证的是分区有序性而不是主题有序性。

之所以要分成多个partition，是为了提高并发度，多个partition并行的进行发送/消费，但这却没有办法保证消息的顺序问题

一个topic只用一个partition，但这样很显然限制了灵活性。

所有发送的消息，用同一个key，这样同样的key会落在一个partition里面。

轮询分区策略

随机分区策略

消息刷盘

操作系统本身是有page cache的。即使我们用无缓冲的io，消息也不会立即落到磁盘上，而是在操作系统的page cache里面。操作系统会控制page cache里面的内容，什么时候写回到磁盘。在应用层，对应的就是fsync函数。我们可以指定每条消息都调用一次fsync存盘，但这会较低性能，也增大了磁盘IO。也可以让操作系统去控制存盘。

Producers And Consumers(生产者与消费者)

消费者去broker pull消息

同步发送异步发送

RecordAccimator

Metadata

生产者压缩算法

Producer 端压缩

Broker 端保持

Consumer 端解压缩

Producer 发送消息的过程如下图所示，需要经过拦截器，序列化器和分区器，最终由累加器批量发送至 Broker。

Kafka 有消费组的概念，每个消费者只能消费所分配到的分区的消息，每一个分区只能被一个消费组中的一个消费者所消费，所以同一个消费组中消费者的数量如果超过了分区的数量，将会出现有些消费者分配不到消费的分区

配置客户端，创建消费者

订阅主题

拉去消息并消费

提交消费位移

关闭消费者实例

Kafka Consumer 线程不安全，单线程消费，多线程处理

rebalance

rebalance 本质上是一种协议，规定了一个 consumer group 下的所有 consumer 如何达成一致来分配订阅 topic 的每个分区。比如某个 group 下有 20 个 consumer，它订阅了一个具有 100 个分区的 topic。正常情况下，Kafka 平均会为每个 consumer 分配 5 个分区。这个分配的过程就叫 rebalance。

组成员发生变更（新 consumer 加入组、已有 consumer 主动离开组或已有 consumer 崩溃了——这两者的区别后面会谈到）

订阅主题数发生变更

订阅主题的分区数发生变更

Kafka 默认提供了两种分配策略：Range 和 Round-Robin。当然 Kafka 采用了可插拔式的分配策略，你可以创建自己的分配器以实现不同的分配策略。

Brokers And Clusters

broke依赖zk，生产消费者并不依赖

Messages And Batches(消息与批次)

Exactly Once

消息不会重复存储

消息不会重复消费

不会丢失存储

不会丢失消费

高水位值 (High watermark)。这是控制消费者可读取消息范围的重要字段。一个普通消费者只能“看到”Leader 副本上介于 Log Start Offset 和 HW（不含）之间的所有消息。水位以上的消息是对消费者不可见的。

消息丢失

broker

异步刷盘

页缓存到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

Producer

异步发送消息-丢失消息

不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。记住，一定要使用带有回调通知的 send 方法。

设置 acks = all。acks 是 Producer 的一个参数，代表了你对“已提交”消息的定义。如果设置成 all，则表明所有副本 Broker 都要接收到消息，该消息才算是“已提交”。这是最高等级的“已提交”定义。

Consumer

自动提交

确保消息消费完成再提交。Consumer 端有个参数 enable.auto.commit，最好把它设置成 false，并采用手动提交位移的方式。就像前面说的，这对于单 Consumer 多线程处理的场景而言是至关重要的。

Consumer Group：一个消费者组可以包含一个或多个消费者。使用多分区 + 多消费者方式可以极大提高数据下游的处理速度，同一消费组中的消费者不会重复消费消息，同样的，不同消费组中的消费者消息消息时互不影响。Kafka 就是通过消费组的方式来实现消息 P2P 模式和广播模式。

数据的一致性

Kafka 事务机制

Kafka 生产者在同一个事务内提交到多个分区的消息，要么同时成功，要么同时失败。

TransactionalID

epoch 机制

步骤

initTransactions 方法初始化事务上下文

找到 Kafka 集群负责管理当前事务的事务协调者（ TransactionCoordinator ），向其申请 ProducerID 资源

幂等

Producer ID（即PID）

PID：每个新的 Producer 在初始化的时候会被分配一个唯一的 PID，这个PID 对用户完全是透明的。

Sequence Number

配置

enable.idempotence

ISR数据同步

AR：Assigned Replicas。AR 是主题被创建后，分区创建时被分配的副本集合，副本个数由副本因子决定。

ISR：In-Sync Replicas。Kafka 中特别重要的概念，指代的是 AR 中那些与 Leader 保持同步的副本集合。

在 AR 中的副本可能不在 ISR 中，但 Leader 副本天然就包含在 ISR 中。关于 ISR，还有一个常见的面试题目是如何判断副本是否应该属于 ISR。目前的判断依据是：Follower 副本的 LEO 落后 Leader LEO 的时间，是否超过了 Broker 端参数 replica.lag.time.max.ms 值。如果超过了，副本就会被从 ISR 中移除。

Kafka 在所有分配的副本 (AR) 中维护一个可用的副本列表 (ISR)，Producer 向 Broker 发送消息时会根据ack配置来确定需要等待几个副本已经同步了消息才相应成功，Broker 内部会ReplicaManager服务来管理 flower 与 leader 之间的数据同步。

性能

Partition 并发

一方面，由于不同 Partition 可位于不同机器，因此可以充分利用集群优势，实现机器间的并行处理。另一方面，由于 Partition 在物理上对应一个文件夹，即使多个 Partition 位于同一个节点，也可通过配置让同一节点上的不同 Partition 置于不同的 disk drive 上，从而实现磁盘间的并行处理，充分发挥多磁盘的优势。

顺序读写

400M/s

Kafka 每一个 partition 目录下的文件被平均切割成大小相等（默认一个文件是 500 兆，可以手动去设置）的数据文件，每一个数据文件都被称为一个段（segment file）, 每个 segment 都采用 append 的方式追加数据。

使用 Filesystem Cache PageCache 缓存来减少与磁盘的交互

使用 Zero-copy 和 MMAP 来减少内存交换

使用批量，以流的方式进行交互，直顶网卡上限

使用拉模式进行消息的获取消费，与消费端处理能力相符

Doris

单分区

复合分区

时间分区

维度分筒

部署

FrontEnd DorisDB的前端节点，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。

BackEnd DorisDB的后端节点，负责数据存储，计算执行，以及compaction，副本管理等工作。

Broker

DorisDB中和外部HDFS/对象存储等外部数据对接的中转服务，辅助提供导入导出功能。

Tablet

数据被水平划分为若干个数据分片（Tablet，也称作数据分桶）。每个 Tablet 包含若干数据行。各个 Tablet 之间的数据没有交集，并且在物理上是独立存储的。

DorisManager

DorisDB 管理工具，提供DorisDB集群管理、在线查询、故障查询、监控报警的可视化工具。

Partition

多个 Tablet 在逻辑上归属于不同的分区（Partition）。一个 Tablet 只属于一个 Partition。而一个 Partition 包含若干个 Tablet。因为 Tablet 在物理上是独立存储的，所以可以视为 Partition 在物理上也是独立。Tablet 是数据移动、复制等操作的最小物理存储单元。

OLAP_SCAN_NODE

OlapScanner

SegmentIterator

OlapScanner

对一个tablet数据读取操作整体的封装

RowsetReader

负责了对一个Rowset的读取

RowwiseIterator

提供了一个Rowset中所有Segment的统一访问的Iterator功能

SegmentIterator

对应了一个Segment的数据读取，Segment的读取会根据查询条件与索引进行计算找到读取的对应行号信息

物化视图

数据流和控制流

查询

MySQL客户端执行DQL SQL命令。

FE解析, 分析, 改写, 优化和规划, 生成分布式执行计划。

分布式执行计划由若干个可在单台be上执行的plan fragment构成， FE执行exec_plan_fragment, 将plan fragment分发给BE，并指定其中一台BE为coordinator。

BE执行本地计算, 比如扫描数据。

其他BE调用transimit_data将中间结果发送给BE coordinator节点汇总为最终结果。

FE调用fetch_data获取最终结果。

FE将最终结果发送给MySQL client。

稀疏索引

Bloom Filter（布隆过滤器）

Bloom Filter（布隆过滤器）是用于判断某个元素是否在一个集合中的数据结构，优点是空间效率和时间效率都比较高，缺点是有一定的误判率。

布隆过滤器是由一个Bit数组和n个哈希函数构成。Bit数组初始全部为0，当插入一个元素时，n个Hash函数对元素进行计算, 得到n个slot，然后将Bit数组中n个slot的Bit置1。当我们要判断一个元素是否在集合中时，还是通过相同的n个Hash函数计算Hash值，如果所有Hash值在布隆过滤器里对应的Bit不全为1，则该元素不存在。当对应Bit全1时, 则元素的存在与否, 无法确定. 这是因为布隆过滤器的位数有限, 由该元素计算出的slot, 恰好全部和其他元素的slot冲突. 所以全1情形, 需要回源查找才能判断元素的存在性。

Bloom Filter 索引

DorisDB的建表时, 可通过PROPERTIES{"bloom_filter_columns"="c1,c2,c3"}指定需要建BloomFilter索引的列，查询时, BloomFilter可快速判断某个列中是否存在某个值。如果Bloom Filter判定该列中不存在指定的值，就不需要读取数据文件；如果是全1情形，此时需要读取数据块确认目标值是否存在。另外，Bloom Filter索引无法确定具体是哪一行数据具有该指定的值。

Bitmap索引

Bitmap是元素为1个bit的, 取值为0,1两种情形的, 可对某一位bit进行置位(set)和清零(clear)操作的数组

建立在枚举值列

向量化执行

简单理解为就是消除程序循环的优化。

列式存储

每列的数据存储在一起，可以认为这些数据是以数组的方式存储的，基于这样的特征，当该列数据需要进行某一同样操作，可以使用SIMD进一步提升计算效率，即便运算的机器上不支持SIMD, 也可以通过一个循环来高效完成对这个数据块各个值的计算。

优势

向量化执行引擎可以减少节点间的调度，提高CPU的利用率

因为列存数据，同一列的数据放在一起，导致向量化执行引擎在执行的时候拥有了更多的机会能够利用的当前硬件与编译的新优化特征

因为列存数据存储将同类型的类似数据放在一起使得压缩比能够达到更高，这样可以拉近一些磁盘IO能力与计算能力的差距

join

shuffle join

broadcast join

参与join的两张表的数据行, 若满足join条件, 则需要将它们汇合在一台节点上, 完成join; 这两种join方式, 都无法避免节点间数据网络传输带来额外的延迟和其他开销

kylin

以Hive或者Kafka作为数据源，里面保存着真实表，而Kylin做的就是将数据进行抽象，通过引擎实现Cube的构建。将Hbase作为数据的仓库，存放Cube。因为Hbase的直接读取比较复杂，所以Kylin提供了近似SQL和HQL的形式，满足了数据读取的基本需求。对外提供了RestApi和JDBC/ODBC方便操作。

预加载

Cube

核心算法

kylin.cube.algorithm.auto.threshold 默认7作为阈值

逐层构建算法

从最大维开始,基于上一层,只需要读取一次数据

充分利用MR

缺点,MR多,磁盘消耗大

快速构建算法

一个reduce 写三维度

架构

REST Server服务层

查询引擎

路由层

元数据

cube构建引擎

flink

可扩展并行度的 ETL、数据分析以及事件驱动

Batch（DataSet API）

Streaming（DataStream API）

Tables API & SQL

概念

在 Flink 中，应用程序由用户自定义算子转换而来的流式 dataflows 所组成。这些流式 dataflows 形成了有向图，以一个或多个源（source）开始，并以一个或多个汇（sink）结束。

窗口

从 Streaming 到 Batch 的一个桥梁，将无界数据划分成有界数据。我们通过定义一个窗口，收集一批数据，并对这个窗口内的数据进行聚合类的计算。

时间

事件时间与处理时间

如果关心事件实际发生时间，则必须基于事件的事件时间，而不是处理时间

窗口组件

Window Assigner

用来决定某个元素被分配到哪个/哪些窗口中去。

Trigger

触发器。决定了一个窗口何时能够被计算或清除，每个窗口都会拥有一个自己的Trigger。

Evictor

“驱逐者”。在Trigger触发之后，在窗口被处理之前，Evictor（如果有Evictor的话）会用来剔除窗口中不需要的元素，相当于一个filter，如countTime 中evictor(size) ，其中size 为保留的元素个数

watermark

处理数据从source、transform、sink中的背压和消息乱序问题---延迟触发window计算

引入watermark机制则会等待晚到的数据一段时间，等待时间到则触发计算，如果数据延迟很大，通常也会被丢弃或者另外处理。

checkpoint 与 state

Flink 基于 Chandy-Lamport 算法实现了自己的分布式快照算法，利用 state 和 checkpoint 机制实现了 streaming system 的 exactly-once 语义

checkpoint 机制

一个Checkpoint记录着数据流中某个时刻所有operators对应的状态

Checkpoint Barrier

Flink Checkpoint的核心元素就是数据流Barrier，Barrier会被注入到数据流中，作为数据流的一部分向前流动。Barrier将数据流中的数据切分为进入当前Checkpoint的部分和进入下一次Checkpoint的部分，每个Barrier都携带对应Checkpoint的ID。Barrier是非常轻量级的，不会中断数据流的处理。

执行过程

Job Manager中的Checkpoint Coordinator向所有source端发送触发Checkpoint的通知，并在source端注入barrier事件。

Source端向下游传递barrier，并将自己的状态异步地写入到持久化存储中。

Operator接收到source端传递的barrier之后，会对operator的输入流进行对齐barrier，然后向输出流传递barrier，并将自己的状态异步的写入到持久化存储中。

当sink端接收到所有输入流传递过来的barrier之后，就会向Checkpoint Coordinator通知，此次Checkpoint执行完成。

Chandy-Lamport 算法

在缺乏类似全局时钟或者全局时钟不可靠的分布式系统中来确定一种全局状态

分布式快照算法应用到流式系统中就是确定一个 Global 的 Snapshot

将分布式系统简化成有限个进程和进程之间的 channel 组成，也就是一个有向图：节点是进程，边是 channel。因为是分布式系统，也就是说，这些进程是运行在不同的物理机器上的。那么一个分布式系统的全局状态就是有进程的状态和 channel 中的 message 组成

Flink 在 2015 发布了一篇论文 Lightweight asynchronous snapshots for distributed dataflows

扩展库

Event Processing（CEP）

Graphs：Gelly

Machine Learning

JobManager

处理 Job 提交、 Job 监控以及资源管理

Flink TaskManager

运行 worker 进程，负责实际任务 Tasks 的执行，而这些任务共同组成了一个 Flink Job

Back Pressure背压

分区

BroadcastPartitioner：广播分区器，将数据发往下游的所有节点 CustomPartitionerWrapper：自定义分区器，可以自定义分区的规则 ForwardPartitioner：转发分区器，将数据转发给在本地运行下游的operater ShufflePartitioner：洗牌分区器，将数据在所有output chancel随机选择一个输出 GlobalPartitioner：全局分区器：默认会选择索引为0的channel进行输出 KeyGroupStreamPartitioner：键组分区器，通过记录数据的值获取到分区key：keyGroupId * parallelism / maxParallelism; RebalancePartitioner：轮询分区器，适用于数据倾斜 RescalePartitioner：可扩展的分区器，通过轮询的方式将数据向下游输出

org.apache.flink

streaming

runtime

tasks

OperatorChain

StreamTask

invoke

Create basic utils (config, etc) and load the chain of operators

operators.setup()

task specific init()

initialize-operator-states()

open-operators()

run()

finish-operators()

close-operators()

common cleanup

task specific cleanup()

jobgraph

JobGraph

优化的逻辑执行计划（Web UI中看到的就是这个）

executiongraph

ExecutionGraph

物理执行计划

api

graph

StreamGraph

原始逻辑执行计划

Spark

模式

spark基于local

spark基于standalone

spark基于yarn

spark基于metsos

spark core

spark sql

DataSet

DataFrame

Spark Streaming 流处理框架

MLlib机器学习库

Graphx图形处理库

集群架构

master

Work Node

集群中可以运行Application代码的节点,在Spark on Yarn模式中指的就是NodeManager节点

Executer

运行在worker节点上的一个进程，负责运行某些task，并将数据存在内存或者磁盘上。

task

在executor进程中执行任务的工作单元

stage

每个job被划分为多个stage，一个stage中包含一个taskset

Cache

Cluster manager

Driver

main()函数，创建SparkContext，由SparkContext进行资源申请，任务的分配和监控等。程序执行完毕后关闭SparkContext。

算子

distinct

groupByKey

弹性式数据集RDDs

一个 RDD 由一个或者多个分区（Partitions）组成。对于 RDD 来说，每个分区会被一个计算任务所处理，用户可以在创建 RDD 时指定其分区个数，如果没有指定，则默认采用程序所分配到的 CPU 的核心数；

RDD 拥有一个用于计算分区的函数 compute

RDD 会保存彼此间的依赖关系，RDD 的每次转换都会生成一个新的依赖关系，这种 RDD 之间的依赖关系就像流水线一样。在部分分区数据丢失后，可以通过这种依赖关系重新计算丢失的分区数据，而不是对 RDD 的所有分区进行重新计算；

Key-Value 型的 RDD 还拥有 Partitioner(分区器)，用于决定数据被存储在哪个分区中，目前 Spark 中支持 HashPartitioner(按照哈希分区) 和 RangeParationer(按照范围进行分区)；

操作RDD

transformations（转换，从现有数据集创建新数据集）

actions（在数据集上运行计算后将值返回到驱动程序）

宽依赖和窄依赖

窄依赖 (narrow dependency)：父 RDDs 的一个分区最多被子 RDDs 一个分区所依赖；

宽依赖 (wide dependency)：父 RDDs 的一个分区可以被子 RDDs 的多个子分区所依赖。

首先，窄依赖允许在一个集群节点上以流水线的方式（pipeline）对父分区数据进行计算，例如先执行 map 操作，然后执行 filter 操作。而宽依赖则需要计算好所有父分区的数据，然后再在节点之间进行 Shuffle，这与 MapReduce 类似。窄依赖能够更有效地进行数据恢复，因为只需重新对丢失分区的父分区进行计算，且不同节点之间可以并行计算；而对于宽依赖而言，如果数据丢失，则需要对所有父分区数据进行计算并再次 Shuffle。

性能

基于内存计算，减少低效的磁盘交互

高效的调度算法，基于DAG

容错机制Linage，精华部分就是DAG和Lingae

优化

防止不必要的jar包分发，提高数据的本地性，选择高效的存储格式如parquet

过滤操作符的优化降低过多小任务

降低单条记录的资源开销

处理数据倾斜

复用RDD进行缓存

作业并行化执行

JVM

启用高效的序列化方法如kyro

增大off head

shuffle

将 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 中，没有这样功能明确的阶段，只有不同的 stage 和一系列的 transformation()，所以 spill, merge, aggregate 等操作需要蕴含在 transformation() 中。

Storm

核心概念

Topology

spout

bolt

stream

集群架构

Nimbus

Supervisors

Hudi

Hadoop Upserts anD Incrementals

在hadoop兼容的存储之上存储大量数据

两种原语

Update/Delete记录：Hudi使用细粒度的文件/记录级别索引来支持Update/Delete记录，同时还提供写操作的事务保证。查询会处理最后一个提交的快照，并基于此输出结果。

变更流：Hudi对获取数据变更提供了一流的支持：可以从给定的时间点获取给定表中已updated/inserted/deleted的所有记录的增量流，并解锁新的查询姿势（类别）

Beam

提供统一批处理和流处理的编程范式

分布式任务调度框架

Azkaban

架构

Webserver

ExecutorServer

核心概念

job

Flow

Flow1.0

Flow2.0

dolphinscheduler

sqoop数据迁移工具

flume数据收集工具

Event 数据传输的基本单元

Source 数据源

Channel 临时存储数据的管道

Sink 数据处理单元

Agent

数据仓库

事实表

维度表

数据可视化

cboard

davinci

DVAAS（Data Visualization as a Service）平台解决方案

olap

MOLAP(Multidimensional OLAP)

MOLAP以Cube为表现形式，但计算与管理成本较高

ROLAP(Relational OLAP)

ROLAP需要强大的关系型DB引擎支撑

随着分布式、并行化技术成熟应用，MPP引擎逐渐表现出强大的高吞吐、低时延计算能力，号称“亿级秒开”的引擎不在少数，ROLAP模式可以得到更好的延伸。

HOLAP(Hybrid OLAP)

关系型数据库

ROLLUP（上卷）

CDC

debezium

缺点

依赖 kafka connect

消息体内容太多，对消息队列压力较大

每张表对应一个topic，管理起来不够方便（canal，maxwell则可以使用正则来处理）

优势

支持快照模式(snapshot.mode)全量同步

Canal

mysql-binlog-connector-java （mbcj）

原理

1.mbcj 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议

2.MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 mbcj)

3.mbcj 解析 binary log 对象(原始为 byte 流)

Maxwell

不支持truncate命令同步

人工智能

机器学习

基本概念和分类

从经验E中，解决某一任务T，进行某一性能度量P

基本概念

假设函数（hypothesis） h

训练集（training set）

标注

损失函数 Loss Function

针对单个训练样本而言

Mean Squared Error (均方误差) L2 Loss

模型一开始训练时，学习速率非常慢

在一定的假设下，我们可以使用最大化似然得到均方差损失的形式

在模型输出与真实值的误差服从高斯分布的假设下，最小化均方差损失函数与极大似然估计本质上是一致的

损失呈二次方地增加

Mean Absolute Error Loss（平均绝对误差损失） L1 Loss

损失呈线性增长

HuberLoss（Huber 损失）

Huber Loss 结合了 MSE 和 MAE 损失，在误差接近 0 时使用 MSE，使损失函数可导并且梯度更加稳定；在误差较大时使用 MAE 可以降低 outlier 的影响，使训练对 outlier 更加健壮。缺点是需要额外地设置一个超参数。

Quantile Loss（分位数损失）

分段的函数

高估

低估

分别用不同的系数控制高估和低估的损失，进而实现分位数回归

Cross Entropy Loss Function（交叉熵损失函数）

Classification Error（分类错误率）

Hinge Loss（Hinge 损失合页损失）

代价函数 Cost Function

针对整个训练集

目标函数 Objective Function

表示任意希望被优化的函数，用于机器学习领域和非机器学习领域（比如运筹优化）

按数据分类

分类

回归

序列标注

机器学习问题

模式识别

函数回归

概率密度估计

学习的目标、期望风险最小化

经验风险最小化（Empirical Risk Minimzation,ERM）

由样本定义经验风险

按监督分类

监督学习（supervise learning）

回归问题

线性回归

一元

多元

非线性回归

分类

分类算法

Perceptron 感知器算法

Neural Network 神经网络

Random Forests 随机森林

Restricted Boltzmann Machines 有限波尔兹曼机

朴素贝叶斯

KNN（K Nearest Neighbors）

计算机如何处理无穷特征

SVM 支持向量机

无监督学习（unsupervise learning）

聚类算法

鸡尾酒会算法

svd（奇异值分解）

增强学习

半监督学习

按模型分类

生成式模型

判别式模型

经典机器学习模型

监督学习模型

经典算法

Logistic Regression 逻辑回归

支持向量机

松弛变量

惩罚因子

核函数

决策树

概率图模型

Bayesian 贝叶斯

对丢失数据不是很敏感，算法比较简单，经常用于文本分类。

小规模数据上表现良好

隐马尔科夫

最大熵

条件随机场

非监督学习模型

层次聚类

K均值聚类

KNN（K Nearest Neighbors）

KNN的原理就是当预测一个新的值x的时候，根据它距离最近的K个点是什么类别来判断x属于哪个类别

交叉验证

从选取一个较小的K值开始，不断增加K的值，然后计算验证集合的方差，最终找到一个比较合适的K值。

非参的，惰性的算法模型

非参的意思并不是说这个算法不需要参数，而是意味着这个模型不会对数据做出任何的假设，与之相对的是线性回归（我们总会假设线性回归是一条直线）。也就是说KNN建立的模型结构是根据数据来决定的，这也比较符合现实的情况，毕竟在现实中的情况往往与理论上的假设是不相符的。

惰性又是什么意思呢？想想看，同样是分类算法，逻辑回归需要先对数据进行大量训练（tranning），最后才会得到一个算法模型。而KNN算法却不需要，它没有明确的训练数据的过程，或者说这个过程很快。

高斯混合模型

主题模型

集成学习

Bagging

Boosting

随机森林

GBDT

降维算法 &降维/维约简

采样

强化学习

策略求值函数

根据值函数来更新策略

特征工程

特征离散与归一化

特征组合

特征选择

词迁入表示

工具

OCTAVE

MATLAB

优化算法

损失函数

正则化

EM算法

梯度下降

GBDT (Gradient Boosting Decision Tree)（梯度下降树）

主要思想是利用弱分类器（决策树）迭代训练以得到最优模型采用加法模型（即基函数的线性组合），以及不断减小训练过程产生的残差来达到将数据分类或者回归的算法。

点击率预测，搜索排序

LightGBM

解决 GBDT 在海量数据遇到的问题

基于 Histogram 的决策树算法

直方图算法的基本思想是先把连续的浮点特征值离散化成k个整数，同时构造一个宽度为k的直方图

带深度限制的 Leaf-wise 的叶子生长策略

直方图做差加速

直接支持类别特征(Categorical Feature)

Cache 命中率优化

基于直方图的稀疏特征优化

多线程优化

XGBoost

决策树算法

对所有特征都按照特征的数值进行预排序

遍历分割点的时候用O(#data)的代价找到一个特征上的最好分割点

找到一个特征的分割点后，将数据分裂成左右子节点

随机梯度下降

梯度验证

Momentum

AdaGrad

Adam

应用

计算机视觉

自然语言处理

推荐系统

计算广告

智能游戏

模型优化点

局部极小

维数灾难

过拟合

深度学习

发展历史

2012年. AlexNet在ImageNet比赛的胜出，他证明了深度学习在图像识别方面比其他计算机视觉的方法具备更大的优势

Geoffrey Hinton和他的学生Alex Krizhevsky

神经网络

激活函数

函数

Sigmoid（S 形）

将取值为 (−∞,+∞) 的数映射到 (0,1) 之间

缺点

容易出现梯度消失（gradient vanishing）的现象

当激活函数接近饱和区时，变化太缓慢，导数接近0，根据后向传递的数学依据是微积分求导的链式法则，当前导数需要之前各层导数的乘积，几个比较小的数相乘，导数结果很接近0，从而无法完成深层网络的训练

Sigmoid的输出不是0均值（zero-centered）

这会导致后层的神经元的输入是非0均值的信号，这会对梯度产生影响。以 f=sigmoid(wx+b)为例，假设输入均为正数（或负数），那么对w的导数总是正数（或负数），这样在反向传播过程中要么都往正方向更新，要么都往负方向更新，导致有一种捆绑效果，使得收敛缓慢。

幂运算相对耗时

Tanh（双曲正切）

调整参数的梯度

反向传播

前馈神经网络

多层感知器

卷积神经网络（CNN）

基于图像任务的平移不变性（图像识别的对象在不同位置有相同的含义）设计的，擅长应用于图像处理等任务

卷积、池化、全连接

全卷积神经网络

AlexNet、VGG、Res-Net

Inception-Net、MobileNet

CNN调参技巧

深度残差网络

自组织映射神经网络

受限玻尔兹曼机

循环神经网络RNN

能够将之前的信息与当前的任务联系起来，例如我们可以通过之前的视频帧了解当前帧的内容。 tip：有点实时计算引擎开窗的感觉..

双向网络

长短期记忆模型

随着跨度的增加，RNN 变得难以对信息之间的关联进行有效学习

具有对长期依赖进行学习的能力

门结构

增加或删除细胞状态中的信息

遗忘门

第一步是决定从上一个细胞状态中丢弃什么信息

输入门

决定在细胞状态中存储哪些新信息

输出门

sigmoid 神经网络层

点乘运算

当前时刻输入

上一时刻隐藏层状态

上一时刻细胞状态

递归神经网络

胶囊网络

一种新的网络

CNN中没有可用的空间信息

将神经元替换为胶囊

逆渲染

根据图像（渲染结果）反推出物体的信息

包括空间几何信息

对抗神经网络网络GAN

反卷积

对抗损失

参数

batch

批梯度下降

遍历全部数据集算一次损失函数，然后算函数对各个参数的梯度，更新梯度

计算量开销大，计算速度慢，不支持在线学习

随机梯度下降

每看一个数据就算一下损失函数，然后求梯度更新参数

这个方法速度比较快，但是收敛性能不太好

小批的梯度下降

batch_size

epoch

向前和向后传播中所有批次的单次训练迭代

训练过程中数据将被“轮”多少次

iterations

1个iteration等于使用batchsize个样本训练一次

知识图谱

图数据库

neo4j（见数据库分支）

人工智能应用

NLP

中文自动分词

词性标注

句法分析

文本分类

自然语言生成（NLG）

信息检索

信息抽取

文字校对

问答系统

机器翻译

自动摘要

文字蕴涵

难点

语言是没有规律的，或者说规律是错综复杂的。

语言是可以自由组合的，可以组合复杂的语言表达。

语言是一个开放集合，我们可以任意的发明创造一些新的表达方式。

语言需要联系到实践知识，有一定的知识依赖。

语言的使用要基于环境和上下文。

流程

传统

语料预处理

英文

分词

词干提取

词形还原

词性标注

命名实体识别

分块

中文

中文分词

词性标注

命名实体识别

去停用词

特征工程

词集

单词构成的集合，集合自然每个元素都只有一个，也即词集中的每个单词都只有一个

词袋

在词集的基础上如果一个单词在文档中出现不止一次，统计其出现的次数（频数）

TF-IDF模型（term frequency–inverse document frequency，词频与逆向文件频率）

用以评估某一字词对于一个文件集或一个语料库的重要程度

TF * IDF。TF表示词条在文档d中出现的频率。IDF（inverse document frequency，逆向文件频率）的主要思想是：如果包含词条t的文档越少，也就是n越小，IDF越大，则说明词条t具有很好的类别区分能力

选择分类器

评定标准

准确率

一个池塘有10条鱼和20只小龙虾，渔夫撒网打鱼，结果捞上来8条鱼12只小龙虾，那么准确率为8/(8+12)=40%，召回率为8/10=80%。

召回率

准确度

全体预测正确占全部样本的比例

F1-Score

F1-Score也是对准确率和召回率的一个均衡评价

ROC

ROC（Receiver Operating Characteristic Curve）受试者工作特征曲线，以真阳性率为纵坐标，假阳性率为横坐标绘制的曲线，是反映灵敏性和特效性连续变量的综合指标。一般认为ROC越光滑说明分类算法过拟合的概率越低，越接近左上角说明分类性能越好。

AUC

AUC（Area Under the Receiver Operating Characteristic Curve）就是量化衡量ROC分类性能的指标

混淆矩阵

预测真实际真

预测假实际假

预测真实际假

预测假实际假

BLEU

Bilingual evaluation understudy

分数越接近1，说明翻译的质量越高

基于精确率(Precision)

ROUGE

基于召回率

ROUGE-N

在 N-gram 上计算召回率

ROUGE-L

考虑了机器译文和参考译文之间的最长公共子序列

ROUGE-W

改进了ROUGE-L，用加权的方法计算最长公共子序列

深度学习NLP

语料预处理

设计模型

词表征为实数值向量

Word2Vec模型

CBOW(Continuous Bag-Of-Words）

CBOW模型能够根据输入周围n-1个词来预测出这个词本身

Skip-Gram

Skip-gram模型能够根据词本身来预测周围有哪些词

可以把对文本内容的处理简化为K维向量空间中的向量运算，而向量空间上的相似度可以用来表示文本语义上的相似度

模型训练

transformer

CNN

Vision Transformer(ViT)

自动驾驶

多模态预测问题

预测附近车辆的下一步轨迹，对于自动驾驶汽车系统了解周围环境并做出信息决策至关重要

基于特征的预测

基于提议的预测

Transformer模型

光流估计方法

TTC

预测一个物体与相机接触的时间

场景深度估计

OCR

经验

将行业专家的知识经验转化为特征工程，也许比上亿数据训练更有效果。

行业专家经验很重要，否则就要做 EDA 和 UBA 分析

训练模型的目的是为了预测更精准，而不是覆盖所有历史数据

大数据量

分布式训练框架

流式处理增量处理

内核功能核函数

为了解决因维数过大而导致计算能力不足的缺陷，其实质是特征向量内积的平方在机器学习中

在许多情况下，我们希望我们的模型学习非线性模型。通常的方法是选择函数φ（x）将X映射到另一个空间。这里的核心是如何选择φ（x）

混合精度训练

通过使用低精度算术降低了所需的资源

减少所需的内存量

半精度浮点格式（FP16）使用16位，而单精度（FP32）使用32位。降低所需的内存可以训练更大的模型或训练时使用更大的batch size

缩短训练或推理时间

计算的次数或者数据存储的存储十分影响算法的执行时间。半精度使用单精度的一半内存访问，从而降低了在存储层方面所花费的时间。与单精度相比，NVIDIA GPU的半精度算术吞吐量最多提高了8倍，从而加快了数学受限层的速度。

图像处理

图像到数字

图像识别

霍夫变换

目标检测

图像到图像

图像切割

边缘检测

sobel算子

roberts算子

prewitt算子

log算子

cannny算子

图像降噪

图像增强

空域

点运算

灰度级矫正

灰度变换

直方图均衡化、规定化

邻域增强

图像平滑

邻域平均法

中值滤波

降噪消除法

梯度倒数加权

选择掩膜平滑

图像锐化

梯度化

拉普拉斯算子

高通滤波

掩膜匹配法

统值插值法

频域

同态滤波

低通滤波

高通滤波

带阻滤波

傅里叶变换

双边滤波

导向滤波

图像翻译

图像聚类

判别模型

CNN

R - CNN

残差网络

生成模型

GAN

自编码机、波尔兹曼机

概念

卷积核

输入图像中一个小区域中像素加权平均后成为输出图像中的每个对应像素，其中权值由一个函数定义，这个函数称为卷积核

数学

概率论

区间估计

置信区间

分别以统计量的置信上限和置信下限为上下界构成的区间

变量

Α α：阿尔法 Alpha2

Β β：贝塔 Beta3

Γ γ：伽玛 Gamma4

Δ δ：德尔塔 Delte5

Ε ε：艾普西龙 Epsilon6

Ζ ζ ：捷塔 Zeta7

Ε η：依塔 Eta8

Θ θ：西塔 Theta9

Ι ι：艾欧塔 Iota10

Κ κ：喀帕 Kappa11

∧ λ：拉姆达 Lambda12

Μ μ：缪 Mu13

Ν ν：拗 Nu14

Ξ ξ：克西 Xi15

Ο ο：欧麦克轮 Omicron16

∏ π：派 Pi17

Ρ ρ：柔 Rho18

∑ σ：西格玛 Sigma19

Τ τ：套 Tau20

Υ υ：宇普西龙 Upsilon21

Φ φ：fai Phi22

Ψ ψ：普赛 Psi24

Ω ω：欧米伽 Omega

古典概率

概率分布

贝叶斯

"逆概"问题

自然语言的二义性

子主题 3

假设检验

联合概率分布

线性代数

矩阵和向量

加法和标量乘法

矩阵向量乘法

矩阵乘法

矩阵乘法特征

逆和转置

矩阵的特征值与特征向量

几何学

射影几何

点列

指一条直线上所有点的集合

该直线称为点列的底

基本点列

收敛点列

极限点

点列的收敛子列的极限

收敛子列

在这个数列里，任取无穷多项，不改变它们在原来数列中的先后次序，得到的数列称为是原来数列的一个子数列，任何一个数列都存在无穷多个子数列。

统计学

运筹学

经典案例

田忌赛马

欧拉七桥

泛函分析

高等数学

微积分

极限与积分

导数和二阶导数

方向导数与梯度

凸函数与极值

最优化方法

定积分

不定积分

多元函数

函数论

函数逼近

小波变换

换基

傅里叶变换

术语

量

标量（Scalar）

是只有大小，没有方向的量，如1，2，3等

0 维度张量（Tensor）

向量（Vector）

是有大小和方向的量，其实就是一串数字，如(1,2)

矩阵（Matrix）

是好几个向量拍成一排合并而成的一堆数字，如[1,2;3,4]

张量（Tensor）

先贤

欧几里得

公元前330

欧式几何

约翰伯努利

1667

变分法创始人之一

詹姆士伯努利

1654

变分法和概率论创始人之一

拉普拉斯

1749

概率论、拉普拉斯变换、天体力学

约瑟夫·拉格朗日

1736

分析力学、拉格朗日内插公式

巴拿赫

1736

Banach空间理论创始人

冯诺依曼

1903

算子代数博弈论创始人

数字信号处理

频谱能量泄漏

无限长的信号被截断以后，其频谱发生了畸变，原来集中在f(0)处的能量被分散到两个较宽的频带中

窗函数

分类

矩形窗

矩形窗使用最多，习惯上不加窗就是使信号通过了矩形窗。这种窗的优点是主瓣比较集中，缺点是旁瓣较高，并有负旁瓣，导致变换中带进了高频干扰和泄漏，甚至出现负谱现象。频率识别精度最高，幅值识别精度最低，所以矩形窗不是一个理想的窗。如果仅要求精确读出主瓣频率，而不考虑幅值精度，则可选用矩形窗。

汉宁窗

主瓣加宽并降低，旁瓣则显著减小，从减小泄漏观点出发，汉宁窗优于矩形窗．但汉宁窗主瓣加宽，相当于分析带宽加宽，频率分辨力下降。它与矩形窗相比，泄漏、波动都减小了,并且选择性也提高。如果信号有多个频率分量，频谱表现的十分复杂，且测试的目的更多关注频率点而非能量的大小，需要选择汉宁窗。

汉明窗

与汉宁窗都是余弦窗，又称改进的升余弦窗，只是加权系数不同，使旁瓣达到更小。但其旁瓣衰减速度比汉宁窗衰减速度慢。其功能和应用与汉宁窗类似。在语音信号处理中，汉明窗应用最为广泛。

平顶窗

平顶窗在频域时的表现就象它的名称一样有非常小的通带波动。由于在幅度上有较小的误差，所以这个窗可以用在校准上。

傅里叶变换

连续傅里叶变换&分数傅里叶变换

离散傅里叶变换DFT

快速傅里叶变换（FFT）

（快速）傅里叶变换（FFT）可用于从均匀间隔的数据中快速计算傅里叶级数

概念

将一个用系数表示的多项式转换成它的点值表示的算法

如果模型足够平滑，它们会得到光谱收敛，这意味着误差呈指数递减

赫尔德条件

短时傅里叶变换STFT

STFT在傅里叶变换的基础上加窗，分段做FFT变换

快速傅里叶变换FFT

利用计算机计算离散傅里叶变换（DFT)的高效、快速计算方法的统称

切比雪夫变换 / 切比雪夫多项式

概念

从时域到频域的变化

任何连续周期信号可以由一组适当的正弦曲线组合而成

拉普拉斯

拉格朗日

正弦曲线无法组合成一个带有棱角的信号

无限数量的正弦曲线的组合从能量的角度可以非常无限逼近带有棱角的信号。

电参量测量

任意周期信号可以分解为直流分量和一组不同幅值、频率、相位的正弦波。分解的方法就是傅里叶变换。

基波频率

这些正弦波的频率符合一个规律：是某个频率的整数倍。这个频率，就称为基波频率

谐波频率

其它频率称为谐波频率

谐波的频率是基波频率的N倍，就称为N次谐波

直流分量的频率为零，是基波频率的零倍，也可称零次谐波

通过示波器观测实时波形获取，称为时域分析法

傅里叶变换是一种信号分析方法，让我们对信号的构成和特点进行深入的、定量的研究。把信号通过频谱的方式(包括幅值谱、相位谱和功率谱)进行准确的、定量的描述。

正弦波输入至线性系统，不会产生新的频率成分(非线性系统如变频器，就会产生新的频率成分，称为谐波)

机械电子工程

新能源汽车

电力驱动系统

电动机

电动机控制器

传动机构

驱动方式

电动机中央驱动

电动轮驱动

分类

机械传动型

无变速器型

无差速器型

电动轮型

NVH

噪声、振动与声振粗糙度（Noise、Vibration、Harshness）

OBD(On-Board Diagnostics)车载自动诊断系统

机电作动器

人因工程

人因记录仪

PPG血容量脉搏

EDA皮肤电数据

RESP呼吸数据

SKT皮温数据

ACC人体姿态数据

spO2血氧饱和度

MEG脑磁数据

EMG肌电图

毫伏

ECG心电数据

20毫伏

EEG脑电数据

EEG脑电数据处理

大脑的生物电活动

每当数千个神经元同时放电时，它们就会产生一个强大的电场，足以穿过组织、骨骼和头骨。最终，它可以在头部表面测量

脑电仪

金标准/湿电极脑电设备--NeurOne系统

脑电信号

运动想象数据

人在想象自己肢体（或肌肉）运动但没有实际运动输出时，人的特定脑区仍会有激活，目前常见的运动想象部位为：左右，右手，双脚和舌头。通过分析脑电信号，检测识别不同脑区的激活效果来判断用户意图，进而实现人脑与外部设备之间的直接通信与控制。

情绪识别数据

误差相关电位(ErrP)

视觉诱发电位(VEPs)

事件相关电位(ERPs)

慢皮质电位(SCPs)

休息状态音乐与EEG

眨眼/眼动Miscellaneous

临床脑电图

Delta(1-4 Hz)

睡眠实验室中，Delta波被用来评估睡眠深度。节奏越强，睡眠越深。Delta波功率的增加(增加的增量波记录数量)被发现与内部工作记忆任务的注意力增加有关

Theta(4 – 7 Hz)

Theta与广泛的认知处理相关，例如记忆编码和检索以及认知工作量[2]。每当我们遇到困难的任务时(例如，从100开始倒数，或者当回忆起下班回家的路时），Theta波就会变得更加突出。Theta也与疲劳程度增加有关

Alpha(7–12 Hz)

每当我们闭上眼睛,让自己进入平静状态时，Alpha波就会接管。处于放松清醒状态时，Alpha值会增加。生物反馈训练通常使用Alpha波来监测放松情况。它们也与抑制和注意有关

Beta(12 – 30 Hz)

在运动区域内，随着我们计划或执行任何身体部位的运动，Beta频率会变得更强[5]。有趣的是，随着我们观察其他人的身体运动，Beta波的这种增加也很明显。我们的大脑似乎模仿了他们的肢体运动，这表明我们大脑中存在着一个复杂的“镜像神经元系统”，该系统可能与Beta频率协调

Gamma(> 30 Hz，通常为40 Hz)

一些研究人员认为，Gamma波反映了注意力的集中，并作为载波频率来促进大脑区域之间的数据交换。其他人则将伽玛与快速的眼球运动(所谓的微扫视)联系起来，它们被认为是感觉处理和信息吸收的组成部分

BCI脑机接口

BCI脑控机器人大赛

SSVEP

P300

运动想象

情感识别

图灵脑机测试

EEG脑电数据预处理

1. 定位通道数据

《10-20国际标准导联系统》

eeglab中默认的文件是 standard-10-5-cap385，指的是按照国际10-5系统排布的一共有385个电极点信息的模板

2.删除无用数据

3.滤波

高通滤波

低通滤波

带通滤波

凹陷滤波

4分段

只是被试在接受到某个刺激，或者做出某个反应时那段事件的信号，因此，我们要根据我们打上的mark，讲数据切分

5.基线校正

相对平静的状态，此时的脑电活动，代表了一个平静状态下的脑电活动。所以我们将这段时间内的脑电活动当成一个基线

6. 重参考

参考电极

鼻尖参考

cz或头顶中央参考

单侧乳突参考

乳突就是耳朵后面一小块突起的区域

双侧乳突平均参考

全脑平均参考

排除眼电数据

数值为通道和参考通道的电位差

7. 降低采样率

降低采样率要在滤波之后

因为降低采样率会使我们丢失高频信息，使高频信息变得扭曲，所以最好在保留了我们感兴趣波段之后再去降低采样率，这样可以保证信号最大程度不会失真

采样定理

我们的采样率必须是我们想要分析的波段的两倍，比如我们想要分析60Hz的波，那数据采样率为120Hz就足够了。实际上，建议采样率最好在分析波段的三到四倍。

8. 插值坏导

去除伪迹

横向操作

对通道进行校正操作，对数据不好的导联进行插值处理

纵向

挑出数据不好的trials，删除掉。建议是先横向处理后再纵向剔除，尽量保留下更多的trials数

以某通道周围几个通道的数据的平均值，来替代这个通道的数据，这种直接通过代码实现即可

9. 独立主成分分析

我们记录到的是头皮脑电，脑电帽上划出了一个个的点来表示位置，但是我们在FPz点记录到的数据，就真的是FPz点这个位置头皮下方的区域所产生的电活动？不一定。做过实验的都知道，眨眼会产生影响，左右看会产生影响，帽子戴得太紧导致肌肉紧张也会产生影响，还有左右的FP1，FP2处产生的电活动也会影响到FPz，甚至在离它最远的Oz点下方产生的电活动，也有可能对前方FPz点产生微弱的影响。因为真正的电活动产生于头皮下方颅骨内部，它经过了这么一层又一层的传播之后，不同源的电活动肯定会相互影响，从而导致某个记录点记录到的数据，混合了很多不同成分的电活动。而独立主成分分析，就是要对记录点的数据做一个逆运算，把每个记录点的数据，分解成一个又一个的成分组成。然后我们再从中剔除掉伪迹成分，比如眨眼的成分，肌肉紧张的成分等，从而得到一个相对干净的数据。

10 剔除坏段

数十微伏

多导睡眠图（Polysomnography,PSG）睡眠脑电图

主要用于睡眠和梦境研究以及抑郁症和睡眠呼吸暂停综合征的诊断

EOG眼电图

PhysioNet

复杂生理信号的研究资源

生物学

脑科学

布罗德曼分区

额叶

思维，计划和中央执行职能；运动执行；