操作系统

Linux常用指令

1. Linux 中查看进程运行状态的指令

   查看进程运行状态：ps命令。(process status，提供了进程的一次性查看，所提供的查看结果是不动态连续的，如果想对进程时间监控，应该用top工具)

   grep命令（global search regular expression and print out the line，全面检索正则表达式并把行打印出来）能使用正则表达式搜索文本，并把匹配的行打印出来。

   ps -aux|grep PID 用来查看某PID进程状态。

   ps -aux 输出格式：USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

   ps的所有指令：

   1. ps a 显示现行终端机下的所有程序，包括其他用户的程序。
      2）ps -A 显示所有程序。
      3）ps c 列出程序时，显示每个程序真正的指令名称，而不包含路径，参数或常驻服务的标示。
      4）ps -e 此参数的效果和指定”A”参数相同。
      5）ps e 列出程序时，显示每个程序所使用的环境变量。
      6）ps f 用ASCII字符显示树状结构，表达程序间的相互关系。
      7）ps -H 显示树状结构，表示程序间的相互关系。
      8）ps -N 显示所有的程序，除了执行ps指令终端机下的程序之外。
      9）ps s 采用程序信号的格式显示程序状况。
      10）ps S 列出程序时，包括已中断的子程序资料。
      11）ps -t 指定终端机编号，并列出属于该终端机的程序的状况。
      12）ps u 以用户为主的格式来显示程序状况。
      13）ps x 显示所有程序，不以终端机来区分。

2. 查看内存使用情况：free命令

   

   如果加上 -h 选项，输出的结果会友好很多：

   

   有时我们需要持续的观察内存的状况，此时可以使用 -s 选项并指定间隔的秒数：

   1	$ free -h -s 3

   

   上面的命令每隔 3 秒输出一次内存的使用情况，直到你按下 ctrl + c。

3. tar 解压文件的参数

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   # 五个命令中必选一个 -c：建立压缩 -x：解压 -t：查看内容 -r：向压缩归档文件末尾追加文件 -u：更新原压缩包中的文件 # 这几个参数是可选的 -z：有 gzip 属性的 -j：有 bz2 属性的 -Z：有 compress 属性的 -v：显示所有过程 -o：将文件解开到标准输出 # -f参数是必须的

   压缩：tar –cvf jpg.tar *.jpg //将目录里所有jpg文件打包成tar.jpg

   ​ tar –czf jpg.tar.gz *.jpg //将目录里所有jpg文件打包成jpg.tar后，并且将其用gzip压缩，生成一个gzip压缩过的包，命名为jpg.tar.gz

   解压：tar –xvf file.tar //解压 tar包

   ​ tar -xzvf file.tar.gz //解压tar.gz

4. 如何修改文件权限

   ① 文件权限描述

   ​ Linux中的基本权限有9个，分别是owner/group/others三种身份各有自己的read/write/execute权限

   ② 修改权限指令： chomd

   

   ③ chmod语法：

   1 2 3 4 5 6

   chmod [-R] xyz 文件或目录 选项与参数： xyz： 就是数字模型的权限属性，为 rwx 属性数值的相加。 -R：进行递归（recursive）的持续变更，亦即连同次目录下的所有文件都会变更 例： chmod 770 dy.c # 即修改 dy.c 文件的权限为 770

5. 如何以root权限运行某个程序

   su：(switch user 切换用户)

   sudo：

   1 2	sudo chown root app(文件名) sudo chmod u+s app(文件名)

进程与线程

进程的状态

​ 上图interrupt的箭头方向反了。

1. 创建状态（new）

   进程正在被创建，还未到就绪状态

2. 就绪状态 （ready）

   进程已经处于准备运行状态，即进程已经获得了除了处理器之外的一切所需资源，一旦得到处理器资源即可运行。

3. 运行状态（running）

   进程正在处理器上运行

4. 阻塞状态（waiting）

   进程正在等待某一事件而暂停运行如等待某资源为可用或者等待IO操作完成。即使处理器空闲，这个进程也不能运行。

5. 结束状态（terminated）

   进程正在从系统中消失。可能是进程正常结束或其他原因中断退出运行。

进程间的通信方式（7种）

每个进程有不同的用户地址空间，任何一个进程的全局变量其他进程都看不到，进程之间的数据交换必须依赖内核，进程1将数据拷贝到内核缓冲区，然后进程2从内核缓冲区将数据读走，内核提供的这种机制叫做进程间通信（IPC）。

管道/匿名管道（pipe）

• 管道是半双工的，数据只能向一个方向流动；需要双方通信时，需要建立起两个管道。

• 只能用于父子进程或者兄弟进程之间(具有亲缘关系的进程);

• 单独构成一种独立的文件系统：管道对于管道两端的进程而言，就是一个文件，但它不是普通的文件，它不属于某种文件系统，而是自立门户，单独构成一种文件系统，并且只存在与内存中。

• 数据的读出和写入：一个进程向管道中写的内容被管道另一端的进程读出。写入的内容每次都添加在管道缓冲区的末尾，并且每次都是从缓冲区的头部读出数据。

  总结：匿名，只能在有亲缘关系的进程之间通信，半双工，存在于内存，当在一端写数据时必须确定另一端有进程

有名管道（FIFO）

​ 提供了一个路径名与之关联，以有名管道的文件形式存在于文件系统中，那么即使与有名管道不存在亲缘关系的进程，只要可以访问该路径，就能够彼此通过有名管道相互通信。

总结：有名管道以文件的形式存储在磁盘上，进程可以通过访问路径名来与创建线程进行通信，但是由于管道是一种特殊的文件，因此使用前需要用open()打开，如果以读写方式（O_RDWR）打开则一定不会阻塞；以只读（O_RDONLY）方式打开时，调用open()的函数会被阻塞直到其他某个进程为写而打开它为止；如果以只写方式（O_WRONLY）打开时同样也会被阻塞，直到有以读方式打开该管道

信号

信号的生命周期：

① 信号被某个进程产生，并设置此信号传递的对象（一般为对应进程的PID），并传递给操作系统

② 操作系统判断PID所对应的进程是否被阻塞，若阻塞，就先保留该信号，一旦不阻塞，传递给对应进程

③ 对应进程接收到信号后，保存上下文，暂停当前代码的执行，执行对应的中断服务程序

消息队列

存在于内核中的消息链表，在读写数据时，不需要另外某个进程在队列上等待消息的到达。

共享内存

​ 多个进程通过读写同一内存进行通信。每个进程都有属于自己的进程控制块和地址空间，并且都有一个与之对应的页表，负责将进程的虚拟地址与物理地址进行映射，通过内存管理单元（MMU）进行管理。两个不同的虚拟地址通过页表映射到物理空间的同一区域，它们所指向的这块区域即共享内存。

当两个进程通过页表将虚拟地址映射到物理地址时，在物理地址中有一块共同的内存区，即共享内存，这块内存可以被两个进程同时看到。这样当一个进程进行写操作，另一个进程读操作就可以实现进程间通信。但是，我们要确保一个进程在写的时候不能被读，因此我们使用信号量来实现同步与互斥。

信号量

​ 信号量是用来解决进程之间的同步与互斥问题的一种进程之间的通信机制，包括一个称为信号量的变量和该信号量下等待资源的进程等待队列，以及对信号量进行的两个原子操作。信号量对应于某一种资源，取一个非负的整形值。信号量的值是指当前可用的资源数量。

由于信号量只有两种操作，一种是等待信号，另一种是发送信号。即P和V，它们的行为如下：

• P(sv)：如果sv的值大于零，就给它减1；如果它的值为零，就挂起该进程的执行。
• V(sv)：如果有其他进程因等待sv而被挂起，就让它恢复运行，如果没有进程因等待sv而挂起，就给它加1。

套接字

​ 套接字是支持TCP/IP的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点，简单的说就是通信的两方的一种约定，用套接字中的相关函数来完成通信过程。

线程间的同步方式

​ 线程同步是两个或者多个共享关键资源的线程的并发执行。（共享是一个动词）

互斥量

采用互斥对象机制，只有拥有互斥对象的线程可以拥有访问公共资源的权限。因为互斥对象一般只有一个，就能保证公共资源不会被多个线程同时访问，例如Java的synchronized和各种Lock都是采用这种机制。

信号量

允许同一时刻多个线程访问统一资源，但是会控制统一时刻访问资源的最大线程数量，由信号量变量（sv）确定。

事件

wait/notify 通过通知操作的方式来保证多线程同步。事件一般用来控制线程的先后顺序。

事件被分为：手动置位和自动置位。手动置位是同时向所有该事件的等待线程发信号通知，某一操作已经做完了，使他们都处于有信号的状态，都成为可调度线程；自动置位是向某一线程发信号，使它为有信号状态，成为可调度线程。

进程调度

进程调度是指操作系统按照某种策略或规则选择进程占用CPU进行运行的过程。

调度的时机（什么时候会发生进程调度？）

1. 正在执行的进程执行完毕
2. 执行中的进程因提出IO请求或者发出等事件而暂停执行
3. 时间片完成
4. 高优先者进入

调度的方式

1. 先来先服务（FCFS）调度算法

   从就绪队列中选择最先进入队列的进程为之分配资源

2. 短作业优先的调度算法

   从就绪队列中选择一个估计运行时间最短的进程为之分配资源

3. 时间片轮转调度算法

4. 多级反馈队列调度算法

5. 优先级调度算法

   ① 高优先权优先调度算法

   ② 高响应比优先调度算法 优先级=（服务时间+等待时间）/服务时间=1+等待时间/服务时间

   等待时间一定时，服务时间越短，优先级越高，有利于短作业

   服务时间一定时，等待时间越长，优先级越高，有利于先到先服务

   对于长作业，作业的优先级会随着等待时间的增加而增加，因此该算法既照顾了短作业，又考虑了作业到达的先后顺序，不会使长作业长时间得不到响应。

死锁

​ 多个进程/线程同时被阻塞，他们其中的一个或者全部都在等待某个资源被释放。由于进程/线程被无限期的阻塞，因此程序不可能正常终止。

死锁产生的必要条件

1. 互斥：资源必须在一个时间只能有一个进程可以使用。
2. 占有并等待：一个进程至少占有一个资源并等待另一资源，而该资源被其他进程所占有
3. 非抢占：资源不能被抢占，只有等持有该资源的进程执行完任务后，资源才可以被释放
4. 循环等待：一组等待进程，循环占有资源并等待其他线程释放资源

解决死锁的方法

预防：限制并发进程对资源的请求

一般通过破坏2和4来预防死锁。

1. 静态分配策略破坏第二个条件（占有并等待）。在执行前获取到该进程所需要的所有资源。

2. 层次分配策略破坏第四个条件（循环等待）。一个进程得到某个资源后，只能再申请更高一级的资源；而在释放的时候也要先释放较高层的资源。

避免：对资源的使用情况做出预测，避免死锁产生

银行家算法：当一个进程申请使用资源的时候，银行家算法先试探分配给该进程资源，然后通过安全性算法判断分配后系统是否处于安全状态

（预测分配后系统是否安全）

检测：检测死锁的发生，精确的确定与死锁有关的进程和资源

系统定时运行“死锁检测”程序，判断系统是否发生了死锁，如果发生了再去解除它。

如果进程—资源图无环路，未发生死锁；有环路而且每个资源只有一份，发生死锁；有环路但有资源有多份，要具体分析。

解除：将进程从死锁状态下解脱出来

1. 立即结束所有的进程，重新启动操作系统
2. 撤销涉及死锁的进程，解除死锁后继续运行。但是这种方法也会付出很大的代价，可能其中的一些进程已经计算了很长时间。
3. 逐个撤销涉及死锁的进程，直到解除死锁
4. 抢占资源

内存管理

内存管理(Memory Management)是操作系统设计中最重要和最复杂的内容之一。虽然计算机硬件一直在飞速发展，内存容量也在不断增长，但是仍然不可能将所有用户进程和系统所需要的全部程序和数据放入主存中，所以操作系统必须将内存空间进行合理地划分和有效地动态分配。操作系统对内存的划分和动态分配，就是内存管理的概念。

内存管理功能

1. 内存的分配与回收：malloc、free 创建进程后为他们分配内存空间，当结束后内存空间也会被回收

2. 地址转换：将程序中的逻辑地址转换为内存中的物理地址

3. 内存空间的扩充：利用虚拟存储技术或自动覆盖技术，从逻辑上扩充内存

   覆盖技术：解决程序大小超过物理内存总和的问题，内存中分为一个“固定区”和若干个“覆盖区”，需要常驻内存的段放在“固定区”中，调入后就不再调出（除非运行结束）

   将程序分为多个段（多个模块）常用的段常驻内存，不常用的段在需要时调入内存。

   

   交换技术：

   设计思想：内存空间紧张时，系统将内存中某些进程暂时换出外存，把外存中某些已具备运行条件的进程换入内存（进程在内存与磁盘间动态调度）
   中级调度（内存调度），就是要决定将哪个处于挂起状态的进程重新调入内存。
   暂时换出外存等待的进程状态为挂起状态（挂起态， suspend）挂起态又可以进一步细分为就绪挂起、阻塞挂起两种状态
   

4. 存储保护：保证各个作业在自己的内存中运行，互不干扰

   (内存保护)内存分配前，需要保护操作系统不受用户进程的影响，同时保护用户进程不受其他用户进程的影响。通过釆用重定位寄存器和界地址寄存器来实现这种保护。重定位寄存器含最小的物理地址值，界地址寄存器含逻辑地址值。每个逻辑地址值必须小于界地址寄存器；内存管理机构动态地将逻辑地址与界地址寄存器进行比较，如果未发生地址越界，则加上重定位寄存器的值后映射成物理地址，再送交内存单元。每一个逻辑地址都需要与这两个寄存器进行核对，以保证操作系统和其他用户程序及数据不被该进程的运行所影响。

逻辑地址和物理地址

逻辑地址：CPU所生成的地址。逻辑地址是内部和编程使用的、并不唯一。例如，你在进行C语言指针编程中，可以读取指针变量本身值(&操作)，实际上这个值就是逻辑地址，它是相对于当前进程数据段的地址（偏移地址），不和绝对物理地址相干。

物理地址：加载到内存地址寄存器中的地址，内存单元的真正地址。在前端总线上传输的内存地址都是物理内存地址，编号从0开始一直到可用物理内存的最高端。这些数字被北桥(Nortbridge chip)映射到实际的内存条上。物理地址是明确的、最终用在总线上的编号，不必转换，不必分页，也没有特权级检查(no translation, no paging, no privilege checks)。

物理地址=重定位寄存器中的地址+逻辑地址

内存管理机制

连续分配管理方式

单一连续分配

内存分为系统区和用户区，系统区提供给操作系统使用，通常在低地址部分；用户区提供给用户使用，是内存中除系统区之外的内存空间。这种方式无需进行内存保护。

优点：简单、不会产生外部碎片；

缺点：只能用于单用户、单任务的操作系统中，有内部碎片，存储器的效率极低。

固定分区分配

将用户内存空间划分为若干个固定大小的区域，每个区域装入一道作业。当有空闲分区后，就可以从外存的后备作业队列中，选择适当大小的作业装入该分区，如此循环。

该分配方式分为两种方法：

1. 分区大小相等
2. 分区大小不等

特点：可能程序太大放不进任何一个分区内，需要使用覆盖技术进行扩容。会产生内部碎片

动态分区分配

这种分区方法不预先将内存划分，而是在进程装入内存时，根据进程的大小动态地建立分区，并使分区的大小正好适合进程的需要。因此系统中分区的大小和数目是可变的。动态分区在开始分配时是很好的，但是之后会导致内存中出现许多小的内存块，产生外部碎片。

非连续分配管理方式

分页存储管理

分页存储管理方式中，又根据运行作业时是否要把作业的所有页面都装入内存才能运行分为基本分页存储管理方式和请求分页存储管理方式。

固定分区会产生内部碎片，动态分区会产生外部碎片，这两种技术对内存的利用率都比较低。我们希望内存的使用能尽量避免碎片的产生。

这就引入了分页的思想：把主存空间划分为大小相等且固定的块，块相对较小，作为主存的基本单位。每个进程也以块为单位进行划分，进程在执行时，以块为单位逐个申请主存中的块空间。

由于块很小，这样只会在为最后一个不完整的进程块分配内存时会产生内部碎片，这种碎片相对于进程来说是非常小的。

基本概念

内存中的块称为页框，进程中的块称为页。进程在执行时需要申请内存时，为每一页匹配一个页框。为方便地址转换，页面的大小应为2的整数幂。同时页面大小应适中，如果页面太小，每个进程的页面数量就会增加，那么页表就过长，占用大量内存，而且会增加逻辑地址到物理地址转换的开销。页面过大又会使页内碎片增大，降低内存使用率。

按字节编址，假设用来存放页的地址长度为32位（即进程有4G），其中0-11位为页内地址，因此每页大小为4kB；12-31为页号，地址空间最多允许有2^20页。

页表

我们对数据页进行编址时，每页大小为4kB，而我们应该对每页都设置一个页表中的页表项与之对应，那么也就是一共有2^20个页表项。

页表项：在页表中，一个页号以及与其对应的物理块号称之为一个页表项。（红框框起来的部分）

页表项大小为4B，也就是32位，其中页号占20位，那么物理块号应该占12位，也就是页框号有2^12个。我们可以发现页框号的数目要小于页数，说明划分进程为页，每一页都有自己的代号，但调入内存时并不是把全部进程都调入。

我们知道页表项大小为4B，数量为2^20个，那么页表占用的内存等于4B*2^20=4MB，并且这4MB的内存必须连续。但是对于内存来说4M已经是一个不小的内存，没必要让所有的页表项都存储在内存中，因为进程在一段时间内只会访问某些特定的进程页。(后面引入二级页表的概念，在后面会提到)

地址变换机构

系统中一般会设置一个页表寄存器，其中存放页表的起始地址F以及页表长度M(即该进程一共有多少页)。当进程未执行时，页表的起始位置和页表长度存放在进程控制块中，进程执行时，才将页表起始位置和长度存入页表寄存器。设页面大小为L，逻辑地址A到物理地址E的转换过程如下：

1. 计算页号P=A/L和页内偏移量W=A%L；
2. 判断页号P和页表长度M的大小，如果P>=M，说明越界，就产生越界中断；否则继续执行；
3. 页表中页号P对应的页表项地址=页表起始地址F+页号P*页表项长度，取出页表项中的物理块号b。
4. 计算E=b*L+W，用得到的物理地址E去访问内存。

分页存储管理方式存在的两个问题

1. 每个访问操作都涉及到逻辑地址到物理地址的转换，因此地址转换要足够快，否则访问速度会降低。

   具有快表的地址变换机构

   根据上面介绍的地址变换过程可知，若页表全部存在内存中，则存取一个数据或者一条指令至少要访问两次内存：一次时访问页表，确定所存取的数据或指令的物理地址，第二次才根据地址存取数据和指令。

   为此，在地址变换机构中增设了一个具有并行查找能力的高速缓冲存储器—快表（TLB），用来存放当前访问的若干页表项，以加快地址变换的过程。而与此对应，内存中的页表一般称为慢表。

   

   在具有快表的分页机制中，地址的变换过程为：

   1. CPU给出逻辑地址后，由硬件进行地址转换并将页号送入高速缓存寄存器，并将页号和快表中的所有页号做比较
   2. 如果找到了匹配的页号，说明访问的页表项在快表中，就直接从快表中取出该页对应的页框号，与页内偏移量拼接形成物理地址，这样数据仅通过一次访存便可实现。
   3. 如果没有找到，就需要访问主存中的页表，在读出页表项之后，同时将其存到快表中，以便后面有可能的再次访问。但若快表已满，则必须按照一定的算法对旧的页表项进行替换。

   一般快表的命中率可以达到90%以上，这样，分页带来的速度损失就降低到10%以下。快表主要利用了局部性原理。

2. 每个进程引入了页表，用于存储映射机制，页表不能太大，否则内存利用率会降低。（时间换空间）

   由于引入了分页管理，进程在执行的过程中不需要将所有页都调入内存页框中，而只要将保存有映射关系的页表调入内存即可。但我们仍然需要考虑页表的大小。

   举例：逻辑地址有32位，页面大小为4kB，页表项大小为

   ，那么该进程的页表大小为4B*2^20，约100w个页表项，每个进程的页表大小为4M，这明显不符合实际条件。而即使不考虑对全部逻辑地址空间进行映射的情况，一个逻辑地址空间稍大的进程，其页表大小也可能是过大的。

   再假设一个40Mb的进程，页表项也就有40kb，如果将所有的页表项内容全部保存在内存中，那么需要10个内存页框来保存（一个页框保存4kB）。整个进程大约有1w个页面，而在实际执行中只需要几十个页面进入内存页框就可以运行，但如果把10个页面大小的页框全部装入内存，这相对实际执行时的几十个进程页面的大小来说，降低了内存利用率。从另一方面来说，这10页的页表项也并不需要同时保存在内存中，大多数情况下，映射所需要的页表项都在页表的同一页面中。

   将页表映射的思想进一步延伸，就可以得到二级分页：将页表的10页空间也进行地址映射，建立上一级页表，用于存储页表的映射关系。这里对页表的10个页面进行映射只需要10个页表项，所以上一级页表只需要1页就足够，可以存储2^10=1024个页表项。在进程执行时，只需要将这个上一级页表调入内存即可，进程的页表和进程本身的页面，可以在后面的执行中再调入内存。

   在32位系统中，全部32位逻辑地址空间，按字节编码，每页2^12字节，也就是4kB，共有2^20个页面，这些页面也就是会有2^20个页表项，每个页表项是32bit，也就是4B。我们知道一个页面可以放置4kB的数据，也就是1个页面可以存放2^10个页表项，那么一共需要2^10个页面去存放这些页表项，我们就可以为这2^10个页面构建上级页表，也就恰好是一个页面就可以存放。

   

举例：32位系统中进程分页的工作过程：假定内核已经给一个正在运行的进程分配的逻辑地址空间是0x20000000到0x2003FFFF，这个空间由64个页面（0x00-0x3F）组成。在进程运行时，我们不需要知道全部这些页的页框的物理地址，很可能其中很多页还不在主存中。这里我们只注意在进程运行到某一页时，硬件是如何计算得到这一页的页框的物理地址即可。现在进程需要读逻辑地址0x20021406中的字节内容，这个逻辑地址按如下进行处理：
逻辑地址： 0x20021406 (0010 0000 0000 0010 0001 0100 0000 0110 B)
顶级页表字段：0x80 (00 1000 0000 B)
二级页表字段：0x21 (00 0010 0001B)
页内偏移量字段：0x406 (0100 0000 0110 B)

分段存储管理

段式管理方式按照用户进程中的自然段划分逻辑空间。例如，用户进程由主程序、两个子程序、栈和一段数据组成，于是可以把这个用户进程划分为5个段，每段从0开始编址，并分配一段连续的地址空间（段内要求连续，段间不要求连续，因此整个作业的地址空间是二维的）。其逻辑地址由段号S与段内偏移量W两部分组成。

如图，段号为16位，段内偏移量为16位，则一个作业最多可有2^16=65536个段，最大段长为64KB。

在页式系统中，逻辑地址的页号和页内偏移量对用户是透明的，但在段式系统中，段号和段内偏移量必须由用户显示提供，在高级程序设计语言中，这个工作由编译程序完成。

段表

每个进程都有一张逻辑空间与内存空间映射的段表，其中每一个段表项对应进程的一个段，段表项记录该段在内存中的起始地址和段的长度。段表的内容如图所示。

在配置了段表后，执行中的进程可以通过查找段表，找到每个段所对应的内存区。

段页式存储管理

页式存储管理能有效地提高内存利用率，而分段存储管理能反映程序的逻辑结构并有利于段的共享。如果将这两种存储管理方法结合起来，就形成了段页式存储管理方式。

在段页式系统中，作业的地址空间首先被分成若干个逻辑段，每段都有自己的段号，然后再将每一段分成若干个大小固定的页。对内存空间的管理仍然和分页存储管理一样，将其分成若干个和页面大小相同的存储块，对内存的分配以存储块为单位。

​ 为了实现地址变换，系统为每个进程建立一张段表，而每个分段有一张页表。段表表项中至少包括段号、页表长度和页表起始地址，页表表项中至少包括页号和块号。

分页和分段机制的共同点和区别

1. 共同点
   • 分页机制和分段机制都是为了提高内存利用率，减少内存碎片。
   • 页和段都是离散存储的，所以两者都是离散分配内存的方式。但是，每个页和段中的内存是连续的。
2. 区别
   • 页的大小是固定的，由操作系统决定；而段的大小不固定，取决于我们当前运行的程序。
   • 分页仅仅是为了满足操作系统内存管理的需求，而段是逻辑信息的单位，在程序中可以体现为代码段，数据段，能够更好满足用户的需要。

CPU寻址

每个CPU的寻址能力是要看其地址线的数量，32位CPU一般有32根地址总线，那么就一共可以寻232个地址=也就是4x1024x1024x1024=4G个地址，1个地址对应1字节的存储单位，对应到内存上就是4GB（4GByte）

1. 寻址方式：现代的处理器使用的都是一种叫做虚拟地址寻址的寻址方式。

2. 内存管理单元（MMU）：CPU内部的一个硬件，负责完成虚拟地址到物理地址的转换。

   TLB( Translation Look- aside buffer)专门用于缓存内存中的页表项,一般在MMU单元内部。

为什么要使用虚拟地址空间？

如果不使用虚拟地址空间，程序直接访问和操作的都是物理内存。

1. 用户程序可以访问任意内存，寻址内存的每一个字节，这样就有意无意地破坏操作系统，造成操作系统崩溃。
2. 想要同时运行多个程序特别困难，例如想同时运行一个微信和一个QQ音乐都不行。例如：微信在运行的时候给内存地址1xxx赋值，QQ音乐也同样给内存地址1xxx赋值，那么QQ音乐对内存的赋值就会覆盖掉微信之前所赋的值，这就造成了微信程序的崩溃。

使用虚拟地址访问内存的优势

1. 程序可以使用相邻的虚拟地址访问物理内存中不相邻的大物理缓冲区。
2. 程序可以使用虚拟地址来访问大于可用物理内存的内存缓冲区。当物理内存的供应量变小时，内存管理器会将物理内存页保存到磁盘中。数据页和代码页会根据需要在内存和磁盘之间移动。
3. 不同进程之间的虚拟地址相互隔离。一个进程中的代码无法更改另一个进程正在使用的物理内存。

虚拟内存

虚拟内存和虚拟地址空间

​ 前面提到了虚拟地址，实际上虚拟地址空间和虚拟内存并不是一个概念。

虚拟内存

​ 虚拟内存是在磁盘上划分出一块空间由操作系统管理，当内存耗尽时充当内存来用。

虚拟地址空间

​ 操作系统会给每个进程分配一个虚拟地址空间（vitural address），每个进程包含的栈、堆、代码段这些都会从这个地址空间中被分配一个地址，这个地址就被称为虚拟地址。MMU会将虚拟地址转换为物理地址。

​ CPU在寻址的时候，按照虚拟地址来寻址，通过MMU将虚拟地址转换为物理地址。因为只有程序的一部分加入了内存中，那么就会出现所寻找的地址不在内存中的情况。如果在内存不足的情况下，就会通过页面调度算法来将内存中的页面置换出来，将外存中的页面加入到内存中，使程序继续正常运行。

页面置换算法

1. OPT页面置换算法（最佳页面置换算法）：所选择的被淘汰页面将是以后永不使用的，或者是在长时间内不再被访问的，这样可以保证最低的缺页率。
2. FIFO页面置换算法（先进先出页面置换算法）：总先淘汰最先进入内存的页面，即选择在内存中驻留时间最久的页面进行淘汰。
3. LRU页面置换算法（最近最久未使用页面置换算法）
4. LFU页面置换算法（最少使用页面置换算法）

IO管理

排序算法

冒泡排序

冒泡排序的思想是从头遍历，让最大的一直向后交换，让最大的沉底

1
2
3
4
5
6
7
8
9
10
11

public void sort_bubble(int[] nums){
    for(int i=0;i<nums.length-1;i++){
        for(int j=0;j<nums.length-i-1;j++){
            if(nums[j]>nums[j+1]){
                int tmp = nums[j];
                nums[j] = nums[j+1];
                nums[j+1] = tmp;
            }
        }
	}
}

选择排序

在未排序的子数组中找到最小值放到未排序数组的第一个位置

不稳定排序，因为在比较的时候会产生交换，有可能把在前面的值换到后面去

1
2
3
4
5
6
7
8
9
10
11
12
13

public void sort_select(int[] nums){
    for(int i=0;i<nums.length-1;i++){
        int minIndex = i;
        for(int j=i+1;j<nums.length;j++){
            if(nums[j]<nums[minIndex]){
                minIndex = j;
            }
        }
        int temp = nums[i];
        nums[i] = nums[minIndex];
        nums[minIndex] = temp;
    }
}

插入排序

插入排序是一种最简单直观的排序算法，它的工作原理是通过构建有序序列，对于未排序数据，在已排序序列中从后向前扫描，找到相应位置并插入。

1
2
3
4
5
6
7
8
9
10
11

public void sort_insert(int[] nums){
    for(int i=0;i<nums.length-1;i++){
        int tmp = nums[i];
        int position = i;
        while(position>0 && nums[position-1]>tmp){
            nums[postion] = nums[position-1];
            position--;
        }
        nums[position] = tmp;
    }
} 

快速排序

归并排序

采用分治法，将已有序的子序列合并，得到完全有序的子序列。

1
2
3
4
5
6
7
8
9
10
11

public void sort_merge(int[] nums){
    int temp = new int[nums.length];
    mergeSort(nums, temp, 0, nums.length)
}
public void mergeSort(int[] nums, int left, int right){
    if(left<right){
        int middle = (left+right)/2;
        mergeSort(nums, left, middle);
        mergeSort(nums, middle+1, right);
    }
}

堆排

桶排

Arrays.sort

长度小于47：双轴插排

长度大于47小于286：双轴快排

大于286或者初始数据基本有序：归并排序

Redis

单机模式

单机模式就是安装一个Redis，启动起来，调用相应的业务，一般用于无需保证高可用的场景中。

主从复制

主从复制指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点，后者称为从节点；数据复制是单向的，只能从主节点复制到从节点。

既然有主从复制，那就代表master和slave的数据是一样的，有数据冗余问题。但是在程序设计上，为了保证高可用性和高性能，是允许有冗余存在的。主从模式在很多系统设计中都会考虑，一个master节点挂很多slave节点，当master节点宕机，会选举产生一个新的master节点，从而保证服务的高可用性。

主从模式的优点：

• 一旦 主节点宕机，从节点 作为 主节点 的 备份 可以随时顶上来。
• 扩展 主节点 的 读能力，分担主节点读压力。
• 高可用基石：除了上述作用以外，主从复制还是哨兵模式和集群模式能够实施的基础，因此说主从复制是Redis高可用的基石。

但这种模式也会有相应的缺点：

• 一旦 主节点宕机，从节点 晋升成 主节点，同时需要修改 应用方 的 主节点地址，还需要命令所有 从节点 去 复制 新的主节点，整个过程需要 人工干预。
• 主节点 的 写能力 受到 单机的限制。
• 主节点 的 存储能力 受到 单机的限制。

哨兵模式

刚刚提到了，主从模式，当主节点宕机之后，从节点是可以作为主节点顶上来，继续提供服务的。但是有一个问题，主节点的IP已经变动了，此时应用服务还是拿着原主节点的地址去访问，就会出现问题了。人工的干预效率低、易出错。因此在Redis 2.8版本开始引入，有了哨兵这个概念。在复制的基础上，哨兵实现了自动化的故障恢复。

如图，哨兵节点由两部分组成，哨兵节点和数据节点：

• 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
• 数据节点：主节点和从节点都是数据节点。

访问redis集群的数据都是通过哨兵集群的，哨兵监控整个redis集群。

一旦发现redis集群出现了问题，比如刚刚说的主节点挂了，从节点会顶上来。但是主节点地址变了，这时候应用服务无感知，也不用更改访问地址，因为哨兵才是和应用服务做交互的。

Sentinel 很好的解决了故障转移，在高可用方面又上升了一个台阶，当然Sentinel还有其他功能。

比如 主节点存活检测、主从运行情况检测、主从切换。

Redis的Sentinel最小配置是 一主一从。

如果各位部署过哨兵集群的话几句知道，在配置哨兵的信息时，我们只需要用到下面的这个配置项，设置主库的IP和端口，并没有配置其他哨兵的连接信息。

sentinel monitor

节点自动发现

先看数据节点

一般情况下，哨兵节点每隔10秒（故障转移时每隔1秒）向主从节点发送INFO命令，以此获取主从节点的信息。第一次执行时，哨兵仅知道我们给出的主节点信息，通过对主节点执行INFO命令就可以获取其从节点列表。如此周期性执行，就可以不断发现新加入的节点。

• 如果INFO命令目标是从节点：哨兵从返回信息中获取从节点所属的最新主节点ip和port，如果与历史记录不一致，则执行更新；获取从节点的优先级、复制偏移量以及与主节点的链接状态并更新。
• 如果INFO命令目标是主节点：哨兵从返回信息中获取主节点的从机列表，如果从节点是新增的，则将其加入监控列表。
• 无论目标是主节点还是从节点，都会记录其runId。
• 如果节点的角色发生变化，哨兵会记录节点新的角色及上报时间。若此时哨兵运行在TILT模式下，则什么都不做。否则，会执行主从切换相关的逻辑，我们后面再细说。

再看哨兵节点

为了相互检查可用性及信息交互，哨兵之间是一直保持连接的，但是我们并没有显示的告知它们彼此的存在，它们之间是怎么发现对方并交互的呢？

是这样的：通过刚才的介绍，我们了解到哨兵通过INFO命令发现了主节点及从节点的地址信息，而Redis提供了一种发布订阅的消息通信模式，即Pub/Sub，哨兵们就是通过一个约定好的通道（channel）发布/订阅hello信息进行通信。结合图示说明一下：

如上图所示：

• 每隔2秒，每个哨兵会通过它所监控的主节点、从节点向__sentinel__:hello通道发布一条hello消息。
• 每个哨兵会通过它所监控的主节点、从节点订阅__sentinel__:hello通道的消息，以此接收其他哨兵发布的信息。

故障检测

故障检测是哨兵执行故障转移的前提，在知晓需要监控的目标（主从节点）后，哨兵通过PING命令实现对主从节点的故障检测。

哨兵以集群方式工作，官方建议至少要有三个节点，每个节点都以相同的方式对主从节点进行监控与故障检测。由于网络抖动或者网络分区，单个哨兵对节点的故障检测可能无法代表其真实的状态，为了降低误判，哨兵之间还需要对节点的故障状态进行协商。所以这里需要引入两个概念：

• 主观宕机（Subjective Down, SDOWN）：是指一个哨兵实例通过检测发现某个主节点发生故障的一种状态。
• 客观宕机（Objective Down, ODOWN）：是指哨兵检测到某个主节点发生故障，通过命令SENTINEL is-master-down-by-addr与其他哨兵节点协商，并且在指定时间内接收到指定数量的其他哨兵的确认反馈时的一种状态。

简单来说，SDOWN是哨兵自己认为节点宕机，而ODOWN是不但哨兵自己认为节点宕机，而且该哨兵与其他节点沟通后，达到一定数量的哨兵都认为节点宕机了。

主观宕机

每个Sentinel以每秒钟一次的频率，向它所有的 主服务器、从服务器 以及其他Sentinel实例 发送一个PING 命令。如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel标记为 主观下线（SDOWN）。SDOWN状态是指在down-after-milliseconds未收到节点的PING命令回复，如果该配置项为30秒，但是哨兵在29秒时收到节点的回复，哨兵也会认为节点是正常工作的。SDOWN无法触发故障转移，仅仅说明是一个哨兵认为节点发生故障（不可用）了，若要触发故障转移，必须达到ODOWN状态。

客观宕机

当Sentinel将一个主节点判断为主观下线之后，为了确认这个主服务器是否真的下线 了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态。当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移操作。

故障转移

Sentinel判定主节点客观宕机（ODOWN）后，将进入故障转移过程。

进入故障转移过程有几个前提：主节点为客观宕机状态、当前没有故障转移在执行、上次故障转移已经超时。Sentinel确认可以执行故障转移后，会进行以下几项准备工作：

• 设置failover_state：SENTINEL_FAILOVER_STATE_WAIT_START（故障转移等待开始）；
• 设置当前主节点标识位：SRI_FAILOVER_IN_PROGRESS（主节点处于故障转移过程中）；
• 配置纪元加1，并以此作为故障转移的纪元；
• 记录故障转移开始时间及failover_state状态修改时间；

Sentinel Leader选举

当一个主节点被判断为客观下线时，监控这个主节点的所有Sentinel会进行协商，选举一个Leader对下线的主节点执行故障转移操作。怎么选呢？

思考一下，我们可以知道：故障检测是多个Sentinel同时执行的，也就是说可能多个Sentinel在相近的时间内都判定主节点客观宕机了，因此Leader的选举过程在Sentinel集群内可能是同步进行的。所以，Sentinel需要在集群内进行“拉票”，“拉票”的依据就是配置纪元及“拉票”的时间。配置纪元越大，优先级越高；“拉票”请求越早，优先级越高。我们来看下：

• 当Sentinel判断主节点客观下线后，会把自己的配置纪元加1，未检测到主节点ODOWN或检测慢的，自然落后于当前纪元；

• Sentinel会使用Sentinel is-master-down-by-addr命令向其他所有Sentinel发起投票请求，与故障检测过程中的“询问“不同，这里的runId将被设置为当前Sentinel的runId，epoch为最新的纪元。

• 其他Sentinel接收到“投票”请求后，执行以下过程：

• • 若请求纪元大于自身配置纪元，则更新替换；若监控主节点的配置纪元小于请求纪元，则更新替换，并“投票”给发起请求的Sentinel。这个过程是抢占式的，同一纪元，先到先得。（Redis命令处理是单线程，无并发冲突）。
  • 根据判断结果，回复“投票”请求：回复内容为该Sentinel选举的Leader的runId。

• Sentinel接收并处理Sentinel is-master-down-by-addr回复：把投票结果（runId）更新到该Sentinel的节点信息中。

“投票”完成后就到了“唱票”环节，该过程是在SENTINEL_FAILOVER_STATE_WAIT_START状态下执行的。Sentinel会遍历当前主节点下所有的Sentinel节点，把它们的投票信息进行统计；然后判断是否有Sentinel胜出。这里胜出的条件是：

• Sentinel必须获取集群内大多数Sentinel的选票，即票数大于50%（防止“脑裂“）；
• Sentinel所获票数必须大于等于法定人数（quorum）；

举例：监控主节点的Sentinel有5个，quorum为4，投票情况：
如果某个Sentinel的获得3票，但是3<4，该Sentinel不能被选为Leader；
如果某个Sentinel的获得4票，但是4>=4，该Sentinel可以被选为Leader;

因为Sentinel Leader的产生需要半数以上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次Leader，所以在一个配置纪元立main，只会出现一个Leader。

如果在给定时限内，没有一个Sentinel被选举为Leader，那么各个Sentinel将在一段时间后再次进行选择，直到选出Leader为止。

Sentinel Leader选举完成，设置failover_state为SENTINEL_FAILOVER_STATE_SELECT_SLAVE。

新主节点选举

主节点已经客观宕机，Sentinel Leader会从该主节点存活的从节点中选出一个新的主节点。

首先，Sentinel Leader会按照以下条件剔除从节点：

• 主观宕机（SDOWN）或与处于断线状态的从节点；
• 最近5秒内未回复过Sentinel Leader INFO命令的从节点；
• 从节点的优先级为0的从节点，由配置项replica-priority决定；
• 与主节点断开连接超过10倍down-after-milliseconds的从节点；

筛选过后，剩下的从节点都是数据比较新、与Sentinel Leader通信正常的，可以保证故障转移后最小的数据丢失。

然后，按照以下规则选择新的主节点：

• 选择replica-priority最低的节点。如果存在相同，则继续；
• 选择复制偏移量最大的的从节点。如果存在相同，则继续；
• 选择runId最小的从节点；

如果新主节点选举失败，将等待重试。选举成功，则将此从节点提升，并设置failover_state为SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE。

配置新的主节点

选出新的主节点之后，Sentinel Leader会向它发送slaveof NO ONE，把这个从节点转为主节点（这是在从节点自身来看的角色转换）。

从节点接收slaveof NO ONE命令后，会重置其主节点信息，断开与其主节点、从节点的网络连接，重置其复制ID，并执行持久化重写操作。

发送命令后，Sentinel Leader会设置failover_state为SENTINEL_FAILOVER_STATE_WAIT_PROMOTION，等待从节点角色提升。

Sentinel Leader会向它发送slaveof NO ONE命令后，每隔一秒发送一次INFO命令（正常是10秒一次），并观察命令回复中的角色信息。当被升级的从节点的角色从原来的slave变为master时，Sentinel Leader就直到该从节点已经升级主节点了。

从节点角色提升成功，设置failover_state状态为SENTINEL_FAILOVER_STATE_RECONF_SLAVES。

配置其他从节点

新的主节点已经配置完成，接下来就是要让其他存活的从节点以该节点为主节点，然后向该节点发起主从复制。

该过程原理比较简单：遍历原主节点的从节点，向这些从节点发送slaveof <ip> <port>命令，该部分在上一篇《Redis专题：一文搞懂主从复制原理》讲过，大家可以自行翻阅。

所有从节点配置完成后，就会修改failover_state为SENTINEL_FAILOVER_STATE_UPDATE_CONFIG。

不过，这一过程受配置项parallel_syncs（同时执行主从复制的节点数量）的影响。由于主从复制过程中从节点数据加载阶段无法对外提供服务，所以，如果同时进行主从复制的从节点数量较多，可能会导致短时间内系统不可用。

该配置越小，从节点完成配置的时间越长；反之，时间越短。实际环境中，我们需要根据从节点的数量，系统压力，按照比例合理设置。

更新配置

故障转移过程中，新主节点是以“储君”的身份在工作，其他所有从节点切换至新的主节点后，就要正式把新主节点“立”起来了。简单来说有三步（实现方法在sentinelFailoverSwitchToPromotedSlave，由周期函数触发）：

• 重置新主节点的信息状态、清空从节点、Sentinel节点等，failover_state修改为SENTINEL_FAILOVER_STATE_NONE。
• 从旧主节点中迁移Sentinel节点、从节点，迁移至新的主节点中。
• 释放就主节点配置信息。

至此，故障转移工作完成。

其他问题

主从节点移除

Sentinel从不移除从节点，即使很长时间都不可用。这一点是非常有用的，因为当发生网络分区或者故障后，Sentinel需要正确的对恢复节点进行重新配置。经过故障转移，旧主节点将以从节点的角色加入集群，Sentinel会对他进行重新配置，让它从新的主节点执行主从复制。

如果需要移除故障节点，需要依次向Sentinel节点发送Sentinel Reset命令，经过10秒，Sentinel会重新刷新它们的从节点列表，仅保存主节点INFO命令回复内容中的从节点。

脑裂问题

redis的主从模式下脑裂是指因为网络问题，导致redis主节点跟从节点和Sentinel集群处于不同的网络分区，此时因为Sentinel集群无法感知到 主节点的存在，就会将某一个从节点提升为主节点。此时就存在两个不同的主节点，就像一个大脑分裂成了两个。

集群脑裂问题中，如果客户端还在基于原来的主节点继续写入数据，那么新的主节点将无法同步这些数据，当网络问题解决之后，Sentinel 集群将原先的主节点降为从节点，此时再从新的主中同步数据，将会造成大量的数据丢失。

解决方案

min-slaves-to-write 3
min-slaves-max-lag 10

第一个参数表示连接到master的最少slave数量
第二个参数表示slave连接到master的最大延迟时间
按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失。

MySQL调优

MySQL优化主要分为以下四大方面：

1. 设计：存储引擎、字段类型、范式与逆范式
2. 功能：索引、缓存、分区分表
3. 架构：主从复制、读写分离、负载均衡、集群
4. 合理SQL：测试、经验

索引

索引的出现是为了改善查询性能的，是帮助MySQL高效获取数据的数据结构。索引是在存储引擎层实现的，所以没有统一的索引标准，不同存储引擎的索引工作方式不同，也不是所有的引擎都支持所有的索引类型。

索引分类

1. 主键索引

主键是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引，并且一个表只能有一个主键。

2. 普通索引

MySQL 允许对两个或两个以上的列上创建索引，我们习惯上称之为联合索引(又叫复合索引，或者组合索引)。实际上，单列索引可以看成联合索引元素数为1的特例。

3. 唯一索引

唯一索引列的值必须唯一，但允许有空值。如果是联合索引，则列值的组合必须唯一。

4. 全文索引

全文索引是一种特殊类型的索引，通过建立倒排索引，快速匹配文档的方式。它查找的是文本中的关键字，而不是直接比较索引中的值。

正排索引：以文档id作为关键字

倒排表以字或词为关键词进行索引，表中关键字所对应的记录表项记录了出现这个字或词的所有文档。由属性值来确定记录的位置，比如说通过关键词检索文档。

倒排索引跟B+树一样，也是一种数据结构。一般利用关联数组，在辅助表中存储单词与文档中所在位置的映射。

注：此处有一个问题，为什么不使用like+%，因为这种查询方式不能够使用索引，因此检索效率极低。

全文索引跟其它几种索引类型的匹配方式完全不一样。它有许多需要注意的细节，比如停用词、词干和复数、布尔搜索等。另外，只有字段类型为 char、varchar 和 text 的字段才能设置全文索引。

创建全文索引：

① 在创建表时创建全文索引

1
2
3
4
5
6
7

create table fulltext_test (
    id int(11) NOT NULL AUTO_INCREMENT,
    content text NOT NULL,
    tag varchar(255),
    PRIMARY KEY (id),
    FULLTEXT KEY content_tag_fulltext(content,tag)  // 创建联合全文索引列
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

② 在已存在的表上创建全文索引

1
2

create fulltext index content_tag_fulltext
    on fulltext_test(content,tag);

③ 通过SQL语句创建全文索引

1
2

alter table fulltext_test
    add fulltext index content_tag_fulltext(content,tag);

全文索引使用match和against关键字来进行检索

1
2

select * from fulltext_test 
    where match(content,tag) against('xxx xxx');

5. 空间索引

空间索引用于地理数据存储，无需前缀查询，而是会从所有维度来索引数据。

创建索引

1. 使用 CREATE INDEX 语句（不能用这个创建主键索引）

   1	create<索引名> on <表名>（<列名>[<长度>][ASC|DESC]

2. 使用 CREATE TABLE语句（在创建表的同时指定某列或者某几列为某种索引类型）

   1 2 3 4 5 6 7

   create table fulltext_test ( id int(11) NOT NULL AUTO_INCREMENT, content text NOT NULL, tag varchar(255), PRIMARY KEY (id), FULLTEXT KEY content_tag_fulltext(content,tag) // 创建联合全文索引列,content_tag_fulltext为索引别名 ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

3. 使用 ALTER TABLE语句

   1	ALTER TABLE <表名> ADD INDEX [<索引名>][<索引类型>](<列名>,...)

删除索引

1

DROP INDEX [indexName] ON mytable;

1

ALTER TABLE testalter_tbl DROP INDEX (c);

MyISAM索引 和 InnoDB

索引 实现

1. MyISAM 引擎使用 B+Tree 作为索引结构，叶节点的 data 域存放的是数据记录的地址。下图是 MyISAM 索引的原理图：

这里设表一共有三列，假设我们以 Col1 为主键，则上图是一个 MyISAM 表的主索引(Primary key)示意。可以看出 MyISAM 的索引文件仅仅保存数据记录的地址。在 MyISAM 中，主索引和辅助索引(Secondary key)在结构上没有任何区别，只是主索引要求 key 是唯一的，而辅助索引的 key 可以重复。如果我们在 Col2 上建立一个辅助索引，则此索引的结构如下图所示：

同样也是一颗 B+Tree，data 域保存数据记录的地址。因此，MyISAM 中索引检索的算法为首先按照 B+Tree 搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址，读取相应数据记录。

MyISAM 的索引方式也叫做“非聚集”的，之所以这么称呼是为了与 InnoDB 的聚集索引区分。

1. 虽然 InnoDB 也使用 B+Tree 作为索引结构，但具体实现方式却与 MyISAM 截然不同。

第一个重大区别是 InnoDB 的数据文件本身就是索引文件。从上文知道，MyISAM 索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在 InnoDB 中，表数据文件本身就是按 B+Tree 组织的一个索引结构，这棵树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。

上图是 InnoDB 主索引(同时也是数据文件)的示意图，可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。因为 InnoDB 的数据文件本身要按主键聚集，所以 InnoDB 要求表必须有主键(MyISAM 可以没有)，如果没有显式指定，则 MySQL 系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则 MySQL 自动为 InnoDB 表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。

第二个与 MyISAM 索引的不同是 InnoDB 的辅助索引 data 域存储相应记录主键的值而不是地址。换句话说，InnoDB 的所有辅助索引都引用主键作为 data 域。例如，下图为定义在 Col3 上的一个辅助索引：

如何选择

1. InnoDB支持事务，MyISAM不支持
2. InnoDB支持外键，MyISAM不支持
3. MyISAM适合查询以及插入为主的应用，InnoDB适合频繁修改以及涉及到安全性较高的应用
4. InnoDB不支持FULLTEXT类型的索引
5. InnoDB中不保存表的行数，如select count( * ) from table时，InnoDB需要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count( * )语句包含where条件时MyISAM也需要扫描整个表
6. InnoDB支持行锁
7. 清空整个表时，InnoDB是一行一行的删除，效率非常慢；MyISAM则会重建表

如果应用程序一定要使用事务，毫无疑问你要选择INNODB引擎。但要注意，INNODB的行级锁是有条件的。在where条件没有使用主键时，照样会锁全表。比如DELETE FROM mytable这样的删除语句。但是如果应用程序对查询性能要求较高，就要使用MYISAM了。MYISAM索引和数据是分开的，而且其索引是压缩的，可以更好地利用内存。所以它的查询性能明显优于INNODB。压缩后的索引也能节约一些磁盘空间。MYISAM拥有全文索引的功能，这可以极大地优化LIKE查询的效率。

索引失效

1. where语句中包含or时（使用or时并不是一定会索引失效，需要看or左右两边的查询列是否命中相同的索引）

   1 2 3 4

   %如果user_id列有索引，这条语句就是可以命中索引的 select * from `user` where user_id = 1 or user_id = 2 %而无论age列是否有索引，都是无法命中索引的 select * from `user` where user_id = 1 or age = 20;

2. where语句中索引列使用了负向查询，可能会导致索引失效（但也不一定会失效，这要看Mysql优化器的判断）

   负向查询包括：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE

3. 索引字段可以为null，使用 is null 或者 is not null 时，可能会导致索引失效

   单个索引其实使用is null或者is not null时，是可以命中索引的，但使用or进行连接时，就会索引失效了，这应该属于第一种索引失效的情况；但是有null值的字段会使索引比较更加复杂，使数据库的处理性能降低很多。

4. 在索引列上使用内置函数，一定会导致索引失效

   比如下面语句中索引列login_time上使用了函数，会索引失效：

   1	select * from `user` where DATE_ADD(login_time, INTERVAL 1 DAY) = 7;

   4.1 隐式类型转换导致的索引失效

   比如下面语句中索引列user_id为varchar类型，不会命中索引

   1	select * from `user` where user_id = 12;

   这是因为MySQL做了隐式类型转换，调用函数将user_id做了转换。

   1	select * from `user` where CAST(user_id AS signed int) = 12;

   4.2 隐式字符编码转换导致的索引失效

   当两个表之间做关联查询时，如果两个表中关联的字段字符编码不一致的话，MySQL可能会调用CONVERT函数，将不同的字符编码进行隐式转换从而达到统一。作用到关联的字段时，就会导致索引失效。

   比如下面这个语句，其中d.tradeid字符编码为utf8，而l.tradeid的字符编码为utf8mb4。因为utf8mb4是utf8的超集，所以MySQL在做转换时会用CONVERT将utf8转为utf8mb4。简单来看就是CONVERT作用到了d.tradeid上，因此索引失效。

   1	select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4;

5. 对索引列进行运算，一定会导致索引失效

运算如+，-，*，/等，如下：

1

select * from `user` where age - 1 = 10;

优化的话，要把运算放在值上，或者在应用程序中直接算好，比如：

1

select * from `user` where age = 10 - 1;

6. like通配符可能会导致索引失效

   like查询以%开头时，会导致索引失效。解决办法有两种：

   将%移到后面，如：

   1	select * from `user` where `name` like '李%';

   利用覆盖索引(覆盖索引指select的数据列只用从索引中就能够取得，不必在数据库中读取)来命中索引。

   1	select name from `user` where `name` like '%李%';

7. 联合索引中，where中索引列违背最左匹配原则，一定会导致索引失效

8. MySQL优化器的最终选择，不走索引

   上面有提到，即使完全符合索引生效的场景，考虑到实际数据量等原因，最终是否使用索引还要看MySQL优化器的判断。当然你也可以在sql语句中写明强制走某个索引。

mysql一般在哪些字段上建立索引

1. 表的主键和外键建立索引

   当对父表进行更新时，如果在子表中的外键没有使用外键，会在更新的过程中将整个子表锁定，而实际上并不需要锁定整个子表，而仅仅需要锁定子表中的几条记录。这样就会大大影响数据库访问的并发性，并且有可能造成死锁的情况。

   因此只有在外键不需要更新或表数据不需要删除时才不需要建立索引。因为一旦发生了上述两种情况，就会导致子表的全表查询

2. 在order by和group by后建立索引

3. 数据量超过300的表应该建立索引

4. 经常与其他表进行连接的表的字段，应该在该字段上建立索引。

5. 经常出现在where子句中的字段建立索引

6. 不应该在字段比较长的字段上建立索引，因为会消耗大量的空间

7. 对于经常频繁进行修改和插入的表应该少建立索引，因为在修改和插入之后，数据库会去维护索引，会消耗资源

MySQL优化

MySQL优化主要分为以下四大方面：

1. 设计：存储引擎、字段类型、范式与逆范式
2. 功能：索引、缓存、分区分表
3. 架构：主从复制、读写分离、负载均衡、集群
4. 合理SQL：测试、经验

设计

存储引擎

MySQL中主要的存储引擎有InnoDB（5.7版本中默认）、MyISAM、MEMORY、CSV等

1. InnoDB的关键属性包括：

1）ACID事务特性支持，包括commit，rollback以及crash恢复的能力；

2）行级别锁以及多版本并发控制MVCC；

3）利用主键的聚簇索引（clustered index）在底层存储数据，提升对主键查询的IO性能；

4）支持外键功能，管理数据的完整性。

5）在InnoDB中存在着缓冲管理，通过缓冲池，将索引和数据全部缓存起来，加快查询的速度

1. MyISAM

1）不支持事务

2）锁粒度是表级的

3）通过key_buffer_size缓存索引，大大提高访问性能，减少产品IO。只会缓存索引，不缓存数据。

4）读取速度快，占用资源少

5）不支持外键约束，但支持全文索引

字段类型

字段类型应该要满足需求，尽量要满足以下需求。

尽可能小（占用存储空间少）、尽可能定长（占用存储空间固定）、尽可能使用整数

MySQL支持的字段类型大致分为：

1. 数值类型

   1）预估存储的数据的取值范围，选取最合适的数据类型，例如枚举类用TINYINT

   2）当确定字段只有正数的时候，unsigned一定要带上，一方面是向其他开发者说明业务要求，另一方面是能够利用好存储空间。

   注：int(10)其中的10只是显示宽度()，对存储并无影响

2. 时间日期类型

   绝大多数的业务场景还是使用 YYYY-MM-DD HH:MM:SS 的格式来进行存储

   datetime和timestamp我们该如何选择？

   timestamp只需要4个字节的存储空间，相比于datetime有很多的优势，如果考虑到存储空间大小时，同等情况下，选择timestamp会更省空间。

   但是timestamp只能存储1970到2038年的时间

3. 字符串类型

   varchar 可变长，更加有效的利用空间

   char 一般用来存储定长字符串 像MD5后的密码

范式与反范式

三大范式

1. 第一范式：列具有原子性，列不可再分

   例如地址，可以拆成省、市、区甚至更细分，并不具有原子性

2. 第二范式：在满足第一范式的前提下，非主键列都依赖于主键

   要求表中的每列都与主键相关，但不能只与主键的某部分相关（针对联合主键）

   考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。
   因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。
   可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。

3. 第三范式：非主键列都直接依赖主键，不存在传递依赖。即不能存在：非主键列A依赖于非主键B，非主键B依赖于主键的情况

   考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。
   其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
   通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。

4. 反范式：违反范式规则的数据库设计理念

范式的优点与缺点

优点：

​ ① 范式化的更新操作通常比反范式化要快，只需要修改较少数据

​ ② 当数据较好的范式化时，就只有很少或没有重复数据，所以只需要修改更少的数据

​ ③ 范式化的表通常更小，可以更好的存放在内存中，所以执行操作会更快

​ ④ 很少有多余的数据意味着检索列表数据时更少需要distinct或者group by语句

缺点：

​ ① 通常表需要关联，稍微复杂一些的查询语句在符合范式的表上都可能需要至少一次的关联，可能会更多。这不但代价昂贵，也可能是一些索引策略无效。

​ ② 在执行数据库语句时，使得需要在一个索引中又排序又过滤。

反范式的优点与缺点

优点：

​ ① 反范式化的表因为所有的数据都在一张表中，可以很好的避免关联

​ ② 对大部分查询最差的情况，即使表没有使用到索引，当数据比内存大时这可能比关联要快的多，因为这样避免了随机IO，一般全表查询是顺序IO。

缺点：

​ 表格内的冗余较多，删除数据时候会造成表有些有用的信息丢失。

规范化越高，那么产生的关系就越多，关系过多的直接结果就是导致表之间的连接操作越频繁，而表之间的连接操作是性能较低的操作，直接影响到査询的速度，所以，对于査询较多的应用，就需要根据实际情况运用逆规范化对数据进行设计，通过逆规范化来提高査询的性能。

反规范的好处是降低连接操作的需求、降低外键和索引的数目，还可能减少表的数目，相应带来的问题是可能出现数据的完整性问题。加快查询速度，但会降低修改速度。因此，决定做反规范时，一定要权衡利弊，仔细分析应用的数据存取需求和实际的性能特点，好的索引和其他方法经常能够解决性能问题，而不必采用反规范这种方法。

功能

索引

1. 选择在什么样的字段上建立索引

2. 索引失效的条件

3. 索引优化

   ① 建立聚集索引，聚集索引可以极大的提高查询速度

   ② 常查询数据建立索引或者组合索引

   ③ 最左前缀原则

   ④ 较长的数据列建立前缀索引

   ⑤ 不要建立无意义的索引

缓存

​ 缓存之所以有效，主要是因为程序运行时对内存和外存的访问呈现局部性特征，局部特征性为空间局部性和时间局部性两方面。时间局部性是指刚刚访问过的数据近期可能会再次被访问，空间局部性是指，某个位置被访问后，其相邻的位置的数据很可能被访问到，而MySQL的缓存机制就是把刚刚访问的数据以及未来即将访问到的数据保存到缓存中，甚至是高速缓存中，从而提高IO效率。

按照缓存读写功能的不同，MySQL将缓存分为Buffer缓存和Cache缓存。

Buffer缓存。由于硬盘的写入速度过慢，或者频繁的I/O，对于硬盘来说是极大的效率浪费。那么可以等到缓存中储存一定量的数据之后，一次性的写入到硬盘中。Buffer 缓存主要用于写数据，提升I/O性能。

Cache 缓存。 Cache 缓存一般是一些访问频繁但是变更较少的数据，如果Cache缓存已经存储满，则启用LRU算法，进行数据淘汰。淘汰掉最远未使用的数据，从而开辟新的存储空间。不过对于特大型的网站，依靠这种策略很难缓解高频率的读请求，一般会把访问非常频繁的数据静态化，直接由nginx返还给用户。程序和数据库I/O设备交互的越少，则效率越高。

分区分表

分表的类型

1. 垂直分表

   对原始表的列进行拆分，根据一定的拆分规则，把一张表的列，拆分成多张表。例如将原始表中不常用的列拆分到一张表，将一些存储大数据量的字符拆到一张表，把经常使用的列拆分到一张表。

   垂直分表只是拆分了原始表的列，没有减少表的行，原来是多少行，还是多少行。

2. 水平分表

   对行进行拆分，根据一定的拆分规则，把原先在一张表中的数据，分表存储到多张表中。如根据id取模，hash值，按日期月份等

   这样将原本存储在一张表中的数据，被分开存储到不同的表中，大大降低了单表的数据量。

分区的类型

分区的意思是将同一表中不同行的记录分配到不同的物理文件中，几个分区就有几个.idb文件。

1. 垂直分区

   根据表中的列，进行垂直划分，使某些特定的列数据被集中在某一个分区中。如根据数据列使用频率

2. 水平分区

   根据表中的行进行分区，把表中满足某种特性的数据，集中保存在某一个分区中。

分区的好处

• 可以让单表存储更多的数据
• 分区表的数据更容易维护，可以通过清楚整个分区批量删除大量数据，也可以增加新的分区来支持新插入的数据。另外，还可以对一个独立分区进行优化、检查、修复等操作
• 部分查询能够从查询条件确定只落在少数分区上，速度会很快
• 分区表的数据还可以分布在不同的物理设备上，从而搞笑利用多个硬件设备

架构

主从复制

读写分离

集群

合理SQL

测试

经验

服务器的硬盘、CPU、内存、网络都有影响到MySQL的性能。

MySQL 三大日志

redolog（事务日志、重做日志，在磁盘上）

redo log（重做日志）是InnoDB存储引擎独有的，它让MySQL拥有了崩溃恢复能力。比如 MySQL 实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。

MySQL是以页的形式存储数据的，查询一条数据，会从硬盘中把一页的数据加载出来，加载出来的数据叫做数据页（也叫脏页），会放到buffer poll中。然后下次再查询时，会先到缓冲池中查找，没有命中就再去硬盘加载，减少硬盘IO开销，提升性能。然后更新数据的时候，发现缓冲池中有需要更新的数据，就直接再缓冲池中更新。然后把“某个数据页上做了什么修改”记录到Redo log buffer中，接着刷盘到redo log中。

理想情况，事务一提交就会进行刷盘操作，但实际上，刷盘的时机是根据策略来进行的。

刷盘时机

InnoDB 存储引擎为 redo log 的刷盘策略提供了 innodb_flush_log_at_trx_commit 参数，它支持三种策略：

在计算机的操作系统中用户空间缓冲区的数据是无法直接写入磁盘的，中间必需经过操作系统缓冲区（OS Buffer）。因此，redo log buffer写入redo log file，实际上会先写入OS Buffer，然后再调用fsync()将其刷入到redo log file。

• 0：延迟写。表示每次事务提交时不进行刷盘操作，提交事务时不会将redo log buffer写入os buffer，而是每隔1秒将redo log buffer写入os buffer并调用fsync()刷入磁盘。系统崩溃会丢失一秒钟的数据。
• 1：实时写，实时刷。表示每次事务提交时都将进行刷盘操作（默认值）。每次提交事务都将redo log buffer写入os buffer并调用fsync()刷入磁盘。这种方式系统奔溃不会丢失数据，因每次提交事务都写入磁盘，性能比较差。
• 2：实时写，延时刷。表示每次事务提交时都只把 redo log buffer 内容写入 page cache。每次提交事务都将redo log buffer写入os buffer，但并不会马上调用fsync()刷入磁盘，而是间隔1秒调fsync()刷盘。相对于每次提交都写盘和每隔1秒写盘，实时写os buffer延时刷盘是一个数据一致性与性能的之间的折中方案。

innodb_flush_log_at_trx_commit 参数默认为 1 ，也就是说当事务提交时会调用 fsync 对 redo log 进行刷盘

除了后台线程每秒1次的轮询操作，还有一种情况，当 redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半的时候，后台线程会主动刷盘。

现在我们来思考一个问题： 只要每次把修改后的数据页直接刷盘不就好了，还有 redo log 什么事？

它们不都是刷盘么？差别在哪里？

1
2
3
4
5

1 Byte = 8bit
1 KB = 1024 Byte
1 MB = 1024 KB
1 GB = 1024 MB
1 TB = 1024 GB

实际上，数据页大小是16KB，刷盘比较耗时，可能就修改了数据页里的几 Byte 数据，有必要把完整的数据页刷盘吗？

而且数据页刷盘是随机写，因为一个数据页对应的位置可能在硬盘文件的随机位置，所以性能是很差。

如果是写 redo log，一行记录可能就占几十 Byte，只包含表空间号、数据页号、磁盘文件偏移 量、更新值，再加上是顺序写，所以刷盘速度很快。

所以用 redo log 形式记录修改内容，性能会远远超过刷数据页的方式，这也让数据库的并发能力更强。

binlog（二进制日志、归档日志）

redo log 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoDB 存储引擎。

而 binlog 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server 层。

不管用什么存储引擎，只要发生了表数据更新，都会产生 binlog 日志。

那 binlog 到底是用来干嘛的？

可以说MySQL数据库的数据备份、主备、主主、主从（(31条消息) 后端技术 - 主备、主从、主主的区别_穿素白衫的少年的博客-CSDN博客_主从和主主的区别）都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。

主备：备机只用来同步主机的数据，不对外提供服务

主从：相较于备机，从机要对外提供读的操作

主主：两台都是主机，同时对外提供读写操作（涉及到分布式ID的问题）

binlog会记录所有涉及更新数据的逻辑操作，并且是顺序写。

记录格式

binlog 日志有三种格式，可以通过binlog_format参数指定。

• statement
• row
• mixed

指定statement，记录的内容是SQL语句原文，比如执行一条update T set update_time=now() where id=1，记录的内容如下。

同步数据时，会执行记录的SQL语句，但是有个问题，update_time=now()这里会获取当前系统时间，直接执行会导致与原库的数据不一致。

为了解决这种问题，我们需要指定为row，记录的内容不再是简单的SQL语句了，还包含操作的具体数据，记录内容如下。

row格式记录的内容看不到详细信息，要通过mysqlbinlog工具解析出来。

update_time=now()变成了具体的时间update_time=1627112756247，条件后面的@1、@2、@3 都是该行数据第 1 个~3 个字段的原始值（假设这张表只有 3 个字段）。

这样就能保证同步数据的一致性，通常情况下都是指定为row，这样可以为数据库的恢复与同步带来更好的可靠性。

但是这种格式，需要更大的容量来记录，比较占用空间，恢复与同步时会更消耗IO资源，影响执行速度。

所以就有了一种折中的方案，指定为mixed，记录的内容是前两者的混合。

MySQL会判断这条SQL语句是否可能引起数据不一致，如果是，就用row格式，否则就用statement格式。

写入机制

binlog的写入时机也非常简单，事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。

因为一个事务的binlog不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为binlog cache。

我们可以通过binlog_cache_size参数控制单个线程 binlog cache 大小，如果存储内容超过了这个参数，就要暂存到磁盘（Swap）。

binlog日志刷盘流程如下

上图的 write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快

• 上图的 fsync，才是将数据持久化到磁盘的操作

write和fsync的时机，可以由参数sync_binlog控制，默认是0。

为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。

虽然性能得到提升，但是机器宕机，page cache里面的 binlog 会丢失。

为了安全起见，可以设置为1，表示每次提交事务都会执行fsync，就如同 redo log 日志刷盘流程 一样。

最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。

在出现IO瓶颈的场景里，将sync_binlog设置成一个比较大的值，可以提升性能。

同样的，如果机器宕机，会丢失最近N个事务的binlog日志。

两阶段提交

redo log（重做日志）让InnoDB存储引擎拥有了崩溃恢复能力。

binlog（归档日志）保证了MySQL集群架构的数据一致性。

虽然它们都属于持久化的保证，但是侧重点不同。

在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的写入时机不一样。

redo log与binlog两份日志之间的逻辑不一致，会出现什么问题？

我们以update语句为例，假设id=2的记录，字段c值是0，把字段c值更新成1，SQL语句为update T set c=1 where id=2。

假设执行过程中写完redo log日志后，binlog日志写期间发生了异常，会出现什么情况呢？

由于binlog没写完就异常，这时候binlog里面没有对应的修改记录。因此，之后用binlog日志恢复数据时，就会少这一次更新，恢复出来的这一行c值是0，而原库因为redo log日志恢复，这一行c值是1，最终数据不一致。

为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用两阶段提交方案。

原理很简单，将redo log的写入拆成了两个步骤prepare和commit，这就是两阶段提交。

使用两阶段提交后，写入binlog时发生异常也不会有影响，因为MySQL根据redo log日志恢复数据时，发现redo log还处于prepare阶段，并且没有对应binlog日志，就会回滚该事务。

再看一个场景，redo log设置commit阶段发生异常，那会不会回滚事务呢？

并不会回滚事务，它会执行上图框住的逻辑，虽然redo log是处于prepare阶段，但是能通过事务id找到对应的binlog日志，所以MySQL认为是完整的，就会提交事务恢复数据。

undo log（回滚日志）

undo log是mysql中比较重要的事务日志之一，顾名思义，undo log是一种用于撤销回退的日志，在事务没提交之前，MySQL会先记录更新前的数据到 undo log日志文件里面，当事务回滚时或者数据库崩溃时，可以利用 undo log来进行回退。

undo log的两个功能：

1. 提供数据回滚

   我们在进行数据更新操作的时候，不仅会记录redo log，还会记录undo log，如果因为某些原因导致事务回滚，那么这个时候MySQL就要执行回滚（rollback）操作，利用undo log将数据恢复到事务开始之前的状态。

   如我们执行下面一条删除语句：

   delete from user where id = 1;
   那么此时undo log会记录一条对应的insert 语句【反向操作的语句】，以保证在事务回滚时，将数据还原回去。

   再比如我们执行一条update语句：

   update user set name = “李四” where id = 1; —修改之前name=张三
   此时undo log会记录一条相反的update语句，如下：

   update user set name = “张三” where id = 1;
   如果这个修改出现异常，可以使用undo log日志来实现回滚操作，以保证事务的一致性。

2. 提供MVCC多版本控制

   MVCC，即多版本控制。在MySQL数据库InnoDB存储引擎中，用undo Log来实现多版本并发控制(MVCC)。当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据版本是怎样的，从而让用户能够读取到当前事务操作之前的数据【快照读】。

   快照读：

   SQL读取的数据是快照版本【可见版本】，也就是历史版本，不用加锁，普通的SELECT就是快照读。

   当前读：

   SQL读取的数据是最新版本。通过锁机制来保证读取的数据无法通过其他事务进行修改UPDATE、DELETE、INSERT、SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE都是当前读。

在InnoDB存储引擎中，undo log分为：

1. insert undo log：指在insert 操作中产生的undo log，因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。
2. update undo log：记录的是对delete 和update操作产生的undo log，该undo log可能需要提供MVCC机制，因此不能再事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

另外，MVCC 的实现依赖于：隐藏字段、Read View、undo log。在内部实现中，InnoDB 通过数据行的 DB_TRX_ID 和 Read View 来判断数据的可见性，如不可见，则通过数据行的 DB_ROLL_PTR 找到 undo log 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 Read View 之前已经提交的修改和该事务本身做的修改

三大日志总结

MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。

MySQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。

MVCC（多版本并发控制）

MVCC是一种

控制的方法，一般在数据库管理系统中，实现对数据库的并发访问。如果有人从数据库中读数据的同时，有另外的人写入数据，有可能读数据的人看到“半写（脏读）”或者“不一致”（不可重复读）的数据，所以需要并发控制方法来解决这个问题。最简单的方法是我们可以通过加锁，让所有的读者等待写者工作完成，但是这个效率会很差。而MVCC的读操作是快照读，写操作在事务提交前对其他的读者是不可见的。当一个MVCC数据库需要更新一条数据记录时，他不会直接用新数据去覆盖旧数据，而是将旧数据记为过时数据并将新数据记在别处。这样就会有存储多个版本的数据，但只有一个是最新的。这种方式允许读者读取在他读之前已经存在的数据。

undolog版本链

• InnoDB会在每行数据后增加隐藏字段：

  1. DB_ROW_ID：行id，如果有主键就没有这一列；
  2. DB_TRX_ID：记录插入或者更新该行数据的事务ID
  3. DB_ROLL_PTR：回滚指针，指向undo log记录；通过回滚指针连接同一条数据的多个版本，形成一个版本链；

• undo log 版本链是基于 undo log 实现的。undo log 中主要保存了数据的基本信息，比如说日志开始的位置、结束的位置，主键的长度、表id，日志编号、日志类型

  

  此外，

例子

执行

1

INSERT INTO student VALUES (1, '张三');

产生：

继续执行：

1

UPDATE student SET name='李四' WHERE id=1;

产生：

继续执行：

1

UPDATE student SET name='王五' WHERE id=1;

1产生：

为了保证事务并发操作时，在写各自的undo log时不产生冲突，InnoDB采用回滚段的方式来维护undo log的并发写入和持久化。回滚段实际上是一种Undo文件组织方式。

ReadView 机制

可重读是事务启动的时候就生成read view整个事务结束都一直使用这个read view，而在读已提交中则是每执行一条语句就重新生成最新的read view。

ReadView 其实就是一个保存事务ID的list列表。记录的是本事务执行时，MySQL还有哪些事务在执行，且还没有提交。(当前系统中还有哪些活跃的读写事务)

它主要包含这样几部分：

m_ids，当前有哪些事务正在执行，且还没有提交，这些事务的 id 就会存在这里；
min_trx_id，是指 m_ids 里最小的值；
max_trx_id，是指下一个要生成的事务 id。下一个要生成的事务 id 肯定比现在所有事务的 id 都大；
creator_trx_id，每开启一个事务都会生成一个 ReadView，而 creator_trx_id 就是这个开启的事务的 id。
这样在访问某条记录时，只需要按照下边的步骤判断该记录在版本链中的某个版本（trx_id）是否可见：
1、trx_id < m_ids列表中最小的事务id
表明生成该版本的事务在生成ReadView前已经提交，所以该版本可以被当前事务访问。
2、trx_id > m_ids列表中最大的事务id
表明生成该版本的事务在生成ReadView 后才生成，所以该版本不可以被当前事务访问。
3、m_ids列表中最小的事务id < trx_id < m_ids列表中最大的事务id
此处比如m_ids为[5,6,7,9,10]
①、若trx_id在m_ids中，比如是6，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问。
②、若trx_id不在m_ids中，比如是8，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

例子

（个人感觉这个例子针对可重复读是错的，事务A当不是只读事务时，它的creator_trx_id等于０；而在其他情况creator_trx_id应该大于当前所有数据行的创建id，以及所有数据行的修改id，比如说creator_trx_id=20，m_id=[15,18,19,20]，当快照读的时候，查看快照的trx_id，如果小于m_id的最小值，说明在创建该事务时，该快照已经提交；但如果大于m_id的最大值，说明在创建该事务的时候，这个快照还没有创建）

在查询一个数据的时候，也就是开启一个事务进行查询的时候，我们要查询的这个数据行可能会有多个row_trx_id，然后判断row_trx_id与m_ids的关系。

事务是可以并发执行的，现在有事务 A、事务 B 这两个事务，且这两个都没有提交。事务 A 将会执行多次读操作，来模拟可重复读中多次读取同一行数据的场景。事务 B 则会修改这一行数据。

事务 A 开启事务的时候会生成一个 ReadView，所以说这个 ReadView 的创建者就是事务 A，事务 A 的事务 id 是 10，所以 creator_trx_id 就是 10。（在一个只读事务中creator_trx_id 为0）

此时，总共就只有事务 A、事务 B 这两个事务，而且它们都还没有提交，所以说 m_ids 会把这两个事务 id，10、18 都记录下来。min_trx_id 是 m_ids 里面的最小值，10、18 中最小的显然是 10。当前最大的事务 id 是 18，那么下一个事务的 id 就是 19，max_trx_id 就是 19。

ReadView 生成之后，事务 A 就要去 undo log 版本链中读取值了。

现在只有一条 undo log 日志，但这并不意味着事务 A 就能读到这条日志的值 X。它要先判断这行日志的 trx_id 是否小于当前事务的 min_trx_id。看图我们可以很轻松地发现，日志的 trx_id = 8 小于 ReadView 中 min_trx_id = 10。

这就意味着，这个事务 A 开始执行之前，修改这行数据的事务已经提交了，所以事务 A 是可以查到值 X 的。

在此基础上再增添一点操作，实现可重复读

我们继续看，事务 A 第一次读完之后，事务 B 要修改这行数据了。undo log 会为所有写操作生成日志，所以就会生成一条 undo log 日志，并且它的 roll_pointer 会指向上一条 undo log 日志。

紧接着，事务 A 第二次去读这行数据了，情况如下图所示：

第一次读的时候，开启事务 A 的时候就生成了一个 ReadView

此时事务 A 第二次去查询的时候，先查到的是 trx_id = 18 的那条数据，它会发现 18 比最小的事务编号 10 大。那就说明事务编号为 18 的事务，有可能它是读不到的。

接着就要去 m_ids 里确认是否有 18 这条数据了。发现有 18，那就说明在事务 A 开启事务的时候，这个事务是没有提交的，它修改的数据就不应该被读到。

事务 A 就会顺着 roll_pointer 指针继续往下找，找到了 trx_id = 8 这条日志，发现这条能读，读到的值任然是 x，与第一次读到的结果一致。实现可重复读。

分布式

CAP理论

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：

• 一致性（Consistency） : 所有节点访问同一份最新的数据副本
• 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
• 分区容错性（Partition tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

什么是网络分区？

分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。

当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。

然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。 比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。

为啥不可能选择 CA 架构呢？ 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。

另外，需要补充说明的一点是： 如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。

BASE理论

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

BASE 理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。

1. 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

什么叫允许损失部分可用性呢？

• 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
• 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

2. 软状态

软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3. 最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式一致性的 3 种级别：

1. 强一致性 ：系统写入了什么，读出来的就是什么。
2. 弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
3. 最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

那实现最终一致性的具体方式是什么呢? 《分布式协议与算法实战》open in new window 中是这样介绍：

• 读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。
• 写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。
• 异步修复 : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。

比较推荐 写时修复，这种方式对性能消耗比较低。

分布式 id

当有多台数据库服务器，要进行写操作时，由于服务器之间是独立的，每台服务器的id按理说是可以重复的，但是这样会在同步时产生问题，所以要考虑分布式id，主要有以下几种方式：

1. UUID 生成唯一ID，由客户端携带ID写入数据库中

   但一般不会使用UUID，没有递增特性，插入到innoDB，查找时会对数据库造成巨大压力，不能作为物理主键，只能作为逻辑主键，物理主键依然使用自增id。（ 物理主键，可以在系统中由数据库自动生成；而逻辑主键一般是用来表示一个包含确切意义的并唯一的键值，可根据逻辑主键的值了解到一些具体信息。）

2. 数据库自增ID 增加一个数据库表用来生成id，每次写入数据前先插入生成id的数据库一个数据，获取一个递增id（要访问两次数据库）

3. Redis自增ID 首先访问Redis，使用incr()生成一个递增id

4. 雪花算法 生成唯一ID，而且自增

5. 数据库号段模式 在数据库中首先取一段数据放到内存里，用到的时候直接从内存中拿

分布式锁

1. 基于数据库 创建一张锁表，想要锁住某个方法或者资源时，就在该表中增加一条记录，想要释放锁的时候就删除这条记录，根据主键的唯一性，如果其他请求来申请锁，也要插入同一条数据，插入不进去就代表有请求占有锁

2. 基于Redis

   分布锁一般通过redis实现，主要通过setnx函数向redis保存一个key，value等于保存时的时间戳，并设置过期时间，然后返回true；

   当获得锁超过等待时间返回false；

   通过key获取redis保存的时间戳，如果value不为空，并且当前时间戳减去value值超过锁过期时间返回false

   如果一次没有获得锁，则每隔一定时间（10ms或者20ms）再获取一次，直到超过等待时间返回false。

3. 基于Zookeeper

分布式事务（分布式事务（ 图解 + 秒懂 + 史上最全 ） - 疯狂创客圈 - 博客园 (cnblogs.com)）

分布式事务场景：

① 跨库场景

② 分库分表

③ 微服务化

像在微服务中，假如我们有这么几个模块：订单系统、库存系统和支付系统，如果这几个模块部署在同一个JVM上，那么我们可以使用本地事务来保证事务的原子性，但如果我们把不同的系统部署到不同的机子上，就必须通过分布式事务来保证事务特性。主要包括以下几种：

1. 两阶段提交 2PC（two phase commit）（应用于DB层面）（阻塞式 要等所有的参与者执行完本地事务后统一提交，不能单个事务先提交）

   2PC总结：管理者向每个参与者发送prepare请求，参与者受到请求后在本地执行事务，每个参与者执行完事务后会给管理者发送执行成功的消息，如果全部的参与者都执行成功，就给参与者发送提交消息，这个时候参与者才提交事务，然后释放锁资源。

   2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。

   整个事务过程由事务管理器和参与者组成。

   a. 准备阶段（Prepare phase）：事务管理器给每个参与者发送 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交。（Undo 日志是记录修改前的数据，用于数据库回滚，Redo 日志是记录修改后的数据，用于提交事务后写入数据文件）

   b. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚（Rollback）消息；否则，发送提交（Commit）消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放锁资源。

2. 三阶段提交

   三阶段总结：相对于2PC，三阶段多增加了一个询问的过程，管理者首先向所有参与者发送Cancommit请求，询问参与者是否可以执行该事务，参与者会返回yes或no。如果参与者返回yes，那么管理者会向参与者发送PreCommit请求，此时相当于2PC的第一阶段，执行成功后，参与者会向管理者发送ACK应答，然后发送doCommit执行，这时候参与者提交事务；或者在一开始参与者返回No，管理者会向参与者发送Abort请求，参与者中断事务；或是在第二步，有参与者没有返回Ack，或是返回了一个NO，这时候就回滚事务。

   作为2PC的改进版，3PC将原有的两阶段过程，重新划分为CanCommit、PreCommit和doCommit三个阶段。

   3PC 协议将 2PC 协议的准备阶段一分为二，从而形成了三个阶段：

   所谓的三个阶段分别是：询问，然后再锁资源，最后真正提交。

   • 第一阶段：CanCommit

     ① 事务询问。协调者向所有参与者发送包含事务内容的canCommit的请求，询问是否可以执行事务提交，并等待应答；

     ② 各参与者反馈事务询问。正常情况下，如果参与者认为可以顺利执行事务，则返回Yes，否则返回No。

   • 第二阶段：PreCommit

     在本阶段，协调者会根据上一阶段的反馈情况来决定是否可以执行事务的PreCommit操作。有以下两种可能：

     • 执行事务预提交
     • 中断事务

     执行事务预提交

     1. 发送预提交请求。协调者向所有节点发出PreCommit请求，并进入prepared阶段；
     2. 事务预提交。参与者收到PreCommit请求后，会开始事务操作，并将Undo和Redo日志写入本机事务日志；
     3. 各参与者成功执行事务操作，同时将反馈以Ack响应形式发送给协调者，同事等待最终的Commit或Abort指令。

     中断事务
     如果任意一个参与者向协调者发送No响应，或者等待超时，协调者在没有得到所有参与者响应时，即可以中断事务。

     中断事务的操作为：

     1. 发送中断请求。 协调者向所有参与者发送Abort请求；
     2. 中断事务。无论是participant 收到协调者的Abort请求，还是participant 等待协调者请求过程中出现超时，参与者都会中断事务；

   • 第三阶段：Do Commit

     在这个阶段，会真正的进行事务提交，同样存在两种可能。

     • 执行提交
     • 回滚事务

     执行提交

     1. coordinator发送提交请求。假如coordinator协调者收到了所有参与者的Ack响应，那么将从预提交转换到提交状态，并向所有参与者，发送doCommit请求；
     2. 事务提交。参与者收到doCommit请求后，会正式执行事务提交操作，并在完成提交操作后释放占用资源；
     3. 反馈事务提交结果。参与者将在完成事务提交后，向协调者发送Ack消息；
     4. 完成事务。协调者接收到所有参与者的Ack消息后，完成事务。

     回滚事务

     在该阶段，假设正常状态的协调者接收到任一个参与者发送的No响应，或在超时时间内，仍旧没收到反馈消息，就会回滚事务：

     1. 发送中断请求。协调者向所有的参与者发送rollback请求；

     2. 事务回滚。参与者收到rollback请求后，会利用阶段二中的Undo消息执行事务回滚，并在完成回滚后释放占用资源；

     3. 反馈事务回滚结果。参与者在完成回滚后向协调者发送Ack消息；

     4. 回滚事务。协调者接收到所有参与者反馈的Ack消息后，完成事务回滚。

3. TCC（采用补偿方法进行回滚，考验程序员的算法能力）（基于业务层面，要编写业务逻辑实现）补偿事务

   针对每个任务都要注册与之对应的确认(Try)和补偿(Cancel)

   TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm/Cancel 操作若执行失败，TM 会进行重试。

   TCC 分为三个阶段：

   1. Try 阶段是做完业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的 Confirm 一起才能真正构成一个完整的业务逻辑。
   2. Confirm 阶段是做确认提交，Try 阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用 TCC 则认为 Confirm 阶段是不会出错的。即：只要 Try 成功，Confirm 一定成功。若 Confirm 阶段真的出错了，需引入重试机制或人工处理。
   3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用 TCC 则认为 Cancel 阶段也是一定成功的。若 Cancel 阶段真的出错了，需引入重试机制或人工处理。

4. 可靠消息服务

   

   通过消息中间件实现，在A系统操作账户之前，首先向消息中间件发送一条消息，消息中间件收到这条消息后会将其持久化，但是不会进行投递，所以下游的系统不知道这条消息的存在，消息中间件持久化成功后，会向A系统发送一个确认应答。A系统收到确认应答后，就可以进行本地事务操作，A系统处理完成后，向消息中间件发送commit请求。对A系统来说，该事务的处理过程结束。消息中间件收到commit指令后，便向B系统投递该消息，从而触发B事务的执行。当B系统操作完成后，向中间件发送一个确认应答，告诉中间件该消息已经成功消费。分布式事务完成。

   若事务A处理时失败，就会向中间件发送rollback请求，发完之后中间件直接将消息丢弃，不会触发B系统的任务

5. AT(alicloud seata用到了，回滚时自动补偿)

ElasticSearch

Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。 它能很方便的使大量数据具有搜索、分析和探索的能力。

应用场景

1. 日志记录和分析
2. 采集和组合公共数据
3. 全文检索
4. 数据可视化

倒排索引

倒排索引：以关键词作为key，包含关键词的文档作为Value

假设我们有两个文档，都有一个content字段

doc_1：The quick brown fox jumped over the lazy dog

doc_2：Quick brown foxes jump over lazy dogs in summer

首先在es底层分词器会对doc进行分词，得到一个个term（单词），然后建立一个映射关系，记录存在各个单词的文档。首先我们分析一下各个单词存在的文档。

因为每个doc都是id唯一标识的，所以会简历一个映射关系。

当es建立了这种映射关系，当我们搜索一个单词的时候，就不需要遍历每个文档了。而且es的倒排索引进行term优化，比如说大小写转换、近义词转换、时态转换、单复数转换等等。

1
2
3
4
5
6

1 大小写转换：Quick --> quick
2 近义词转换：mother --> mom
3 时态转换：jumped --> jump
4 单复数转换：dogs --> dog
......
注意：不同的分词器的分词方式和算法都是不尽相同的。要注意这一点。

当es进行了term优化后，上面的倒排索引就变成了

每一个文档都对应一个ID。倒排索引会按照指定语法对每一个文档进行分词，然后维护一张表，列举所有文档中出现的terms以及它们出现的文档ID和出现频率。搜索时同样会对关键词进行同样的分词分析，然后查表得到结果。

假设有下列几条数据：

ID Name Age Sex
1 Kate 24 Female
2 John 24 Male
3 Bill 29 Male

ID是Elasticsearch自建的文档id，那么Elasticsearch建立的索引如下：

Name:
Term Posting List
Kate 1
John 2
Bill 3

Age:
Term Posting List
24 [1,2]
29 3

Sex:
Term Posting List
Female 1
Male [2,3]

Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而 [1,2] 就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。通过posting list这种索引方式可以很快进行查找，比如要找age=24的人。

Term Dictionary

Elasticsearch为了能快速找到某个term，将所有的term排序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是Term Dictionary。类似于传统数据库的B-Tree的，但是Term Dictionary较B-Tree的查询快。

Term Index

B-Tree通过减少磁盘寻道次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找term，不读磁盘，但是如果term太多，term dictionary也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些，term，分别在哪页，term index其实是一颗 (trie) 前缀树

这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。

所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。

假设我们现在要将mop, moth, pop, star, stop, top (term index里的term前缀) 映射到序号：0，1，2，3，4，5 (term dictionary的block位置)。最简单的做法就是定义个Map，大家找到自己的位置取值即可，但从内存占用少的角度考虑，FST更节省空间。

基本概念

1. 集群：es是分布式的，由多个节点构成集群

2. 节点：一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。

   ES集群中的节点有三种不同的类型：

   • 主节点：负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 主节点并不需要涉及到文档级别的变更和搜索等操作。可以通过属性node.master进行设置。
   • 数据节点：存储数据和其对应的倒排索引。默认每一个节点都是数据节点（包括主节点），可以通过node.data属性进行设置。
   • 协调节点：如果node.master和node.data属性均为false，则此节点称为协调节点，用来响应客户请求，均衡每个节点的负载。

   一个节点不等于一台服务器

3. 索引：ES将数据存储在一个或者多个索引中，索引相当于SQL中的一个数据库。索引由其名称(必须为全小写字符)进行标识，并通过引用此名称完成文档的创建、搜索、更新及删除操作。一个ES集群中可以按需创建任意数目的索引。

4. 类型：类型是索引内部的逻辑分区(category/partition)，其意义完全取决于用户需求。因此，一个索引内部可定义一个或多个类型(type)。例如，在索引中，可以定义一个用于存储用户数据的类型，一个存储日志数据的类型，以及一个存储评论数据的类型。类比传统的关系型数据库领域来说，类型相当于 “表” 。

   Elasticsearch：index –> type –> doc –> field

   MySQL: 数据库 –> 数据表 –> 行 –> 列

   为什么在ES 7.X中去除了类型这个概念？

   • 原因

     因为 Elasticsearch 设计初期，是直接查考了关系型数据库的设计模式，存在了 type（数据表）的概念。但是，其搜索引擎是基于 Lucene 的，这种 “基因” 决定了 type 是多余的。 Lucene 的全文检索功能之所以快，是因为 倒排索引 的存在。而这种倒排索引的生成是基于 index 的，而并非 type。多个type 反而会减慢搜索的速度。为了保持 Elasticsearch “一切为了搜索” 的宗旨，适当的做些改变（去除 type）也是无可厚非的，也是值得的。

     为何不是在 6.X 版本开始就直接去除 type，而是要逐步去除type？

     因为历史原因，前期 Elasticsearch 支持一个 index 下存在多个 type的，而且，有很多项目在使用 Elasticsearch 作为数据库。如果直接去除 type 的概念，不仅是很多应用 Elasticsearch 的项目将面临 业务、功能和代码的大改，而且对于 Elasticsearch 官方来说，也是一个巨大的挑战（这个是伤筋动骨的大手术，很多涉及到 type 源码是要修改的）。所以，权衡利弊，采取逐步过渡的方式，最终，推迟到 7.X 版本才完成 “去除 type” 这个 革命性的变革。

5. 文档（Document）

   文档是索引和搜索的原子单位，它是包含了一个或多个域（Field，列字段）的容器，基于JSON格式进行表示。文档由一个或多个域组成，每个域拥有一个名字及一个或多个值，有多个值的域通常称为 “多值域” 。每个文档可以存储不同的域集，但同一类型下的文档至应该有某种程度上的相似之处。

   document路由原理（一个index会分为多个分片，因此涉及到document存到哪个分片上的问题）

   ①路由算法：shard = hash(routing) % number_of_primary_shards

   ②决定一个document在哪个shard上，最重要的一个值就是routing值，默认是_id，也可手动指定，相同的routing值，每次过来，从hash函数中，产出的hash值一定是相同的
   例：手动指定一个routing value，比如 put /index/type/id?routing=user_id
   ③这就是primary shard数量不可变的原因（通过路由算法存放一个数据后，假设有3个primary_shards，然后hash(routing)=21，那么shard=0，所以数据被存放到P0，如果此时添加一个primary_shards，我们想要获取刚才加入的这个数据，此时再使用路由算法，算出来shard=21%4=1，但在P1找不到这个数据，间接的导致数据丢失）。

6. 分片：

   一个索引中的数据保存在多个分片中，相当于水平分表。一个分片便是一个Lucene 的实例，它本身就是一个完整的搜索引擎。我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。

   ES实际上就是利用分片来实现分布式。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 当你的集群规模扩大或者缩小时， ES会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

   一个分片可以是主分片或者副本分片。 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

   如果当前插入大量数据，那么会对es集群造成一定的压力，所以在插入大量数据前，也就是在建立索引的时候，我们最好把副本数设置为0；等数据建立完索引之后，在手动的将副本数更改到2，这样可以提高数据的索引效率

   在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。默认情况下，一个索引会有5个主分片，而其副本可以有任意数量。

   主分片和副本分片的状态决定了集群的健康状态。每一个节点上都只会保存主分片或者其对应的一个副本分片，相同的副本分片不会存在于同一个节点中。如果集群中只有一个节点，则副本分片将不会被分配，此时集群健康状态为yellow，存在丢失数据的风险。

   a. es处理的最小单元，它只是保存了索引中所有数据的一部分。

   b. 一个分片是一个Lucene索引

   c.一个包含倒排索引的文件记录

   d.分片越多搜索越慢

   分片：扩展和容灾（和kafka的分区很像）

   索引和搜索数据：

   索引文档（相当于写）请求到一个节点，文档会通过hash随机到一个主分片，然后从主分片同步到副本分片。副本分片越多，索引数据越慢，因为所有的数据都完成才算完成

   搜索请求到一个节点，节点请求到本节点的一个分片，到其他节点的另一个分片，所有分片都返回结果到发起节点，发起节点返回搜索结果到请求方。不同节点上的主分片+副本分片的总数越多，请求被分摊的越均匀，并发搜索性能越好。如果节点数很少，分片都集中到少数节点上，搜索速度会变慢，因为增加了开销，实际没有分摊负载。单个搜索无法通过分片加速，因为分片搜索是有额外的开销的，所以尽管把搜索均衡到了不同节点上一定程度上提高了搜索性能，但是还是不能提高单个搜索的速度。

7. 分段

   a. lucene索引再分割成小单元

   b. 分段越多搜索越慢

   c. 分段不会被修改

   d. 索引新的文档会创建新的分段

   e. 分段会持续地被合并

   f. 删除文档的时候不会真的删除

写数据

当用户向一个节点提交了索引一个新文档的请求，该节点会根据路由选择确定新文档所在的分区，而每个节点都会保存每个分区所在节点的信息，协调节点会将请求发送给对应的节点，注意这个请求会发送给主分片，等主分片完成索引，会并行将请求发送到其所有副本分片，保证每个分片都持有最新数据。

• 协调节点默认使用文档 ID 参与计算（也支持通过 routing），以便为路由提供合适的分片：shard = hash(document_id) % (num_of_primary_shards)

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

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

• 在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync 将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。

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

  

读数据

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。

• 客户端发送请求到任意一个 node，成为 coordinate node 。
• coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡（保证读请求能够分摊到不同的shard上）。
• 接收请求的 node 返回 document 给 coordinate node 。
• coordinate node 返回 document 给客户端。

更新和删除数据

• 删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更；
• 磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入新段。
• 在新的文档被创建时， Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

搜索数据

es 最强大的是做全文检索，就是比如你有三条数据：

1
2
3

java真好玩儿啊
java好难学啊
j2ee特别牛Copy to clipboardErrorCopied

你根据 java 关键词来搜索，将包含 java 的 document 给搜索出来。es 就会给你返回：java真好玩儿啊，java好难学啊。

• 客户端发送请求到一个 coordinate node 。

• 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard ，都可以。如果并行搜索的话，如果有比较多的副本shard，这样搜索请求就会被分摊到多个shard上，提高效率

• query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id ）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。

• fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

  

Elasticsearch 的 master 选举流程？

1
2
3

conf/elasticsearch.yml:
    node.master: true/false
    node.data: true/false

一个ElasticSearch集群是由多个节点构成的，节点又可以根据上述两个参数分为四种类型。

当node.master=true时，表示该接待你是一个master的候选节点，可以参与选举，在ES的文档中常被称作master-eligible node。ES在正常运行时只能有一个master，多于一个就发生了脑裂。当node.data为true时，这个节点作为一个数据节点，会存储分配在该node上的shard的数据并负责这些shard的写入、查询等。任何一个集群内的node都可以执行任何请求，其会负责将请求转发给对应的node进行处理，所以当node.master和node.data都为false时，这个节点可以作为一个类似proxy的节点，接受请求并进行转发、结果聚合等。

节点发现

ZenDiscovery是ES自己实现的一套用于节点发现和选主等功能的模块，没有依赖Zookeeper等工具。

简单来说，节点发现依赖以下配置：

1
2

conf/elasticsearch.yml:
    discovery.zen.ping.unicast.hosts: [1.1.1.1, 1.1.1.2, 1.1.1.3]

这个配置可以看作是，在本节点到每个hosts中的节点建立一条边，当整个集群所有的node形成一个联通图时，所有节点都可以知道集群中有哪些节点，不会形成孤岛。

Master选举

上面提到，集群中可能会有多个master-eligible node，此时就要进行master选举，保证只有一个当选master。如果有多个node当选为master，则集群会出现脑裂，脑裂会破坏数据的一致性，导致集群行为不可控，产生各种非预期的影响。

为了避免产生脑裂，ES采用了常见的分布式系统思路，保证选举出的master被多数派(quorum)的master-eligible node认可，以此来保证只有一个master。这个quorum通过以下配置进行配置：

1
2

conf/elasticsearch.yml:
    discovery.zen.minimum_master_nodes: 2

master选举谁发起，什么时候发起？

master选举当然是由master-eligible节点发起，当一个master-eligible节点发现满足以下条件时发起选举：

1. 该master-eligible节点的当前状态不是master。
2. 该master-eligible节点通过ZenDiscovery模块的ping操作询问其已知的集群其他节点，没有任何节点连接到master。
3. 包括本节点在内，当前已有超过minimum_master_nodes个节点没有连接到master。

总结一句话，即当一个节点发现包括自己在内的多数派的master-eligible节点认为集群没有master时，就可以发起master选举。

当需要选举master时，选举谁？

根据源码来进行分析

首先是选举谁的问题，如下面源码所示，选举的是排序后的第一个MasterCandidate（即master-eligible node）。

1
2
3
4
5
6

public MasterCandidate electMaster(Collection<MasterCandidate> candidates) {
        assert hasEnoughCandidates(candidates);
        List<MasterCandidate> sortedCandidates = new ArrayList<>(candidates);
        sortedCandidates.sort(MasterCandidate::compare);
        return sortedCandidates.get(0);
}

那么是按照什么排序的？

1
2
3
4
5
6
7
8
9

public static int compare(MasterCandidate c1, MasterCandidate c2) {
   // we explicitly swap c1 and c2 here. the code expects "better" is lower in a sorted
   // list, so if c2 has a higher cluster state version, it needs to come first.
    int ret = Long.compare(c2.clusterStateVersion, c1.clusterStateVersion);
    if (ret == 0) {
        ret = compareNodes(c1.getNode(), c2.getNode());
    }
    return ret;
}

如上面源码所示，先根据节点的clusterStateVersion比较，clusterStateVersion越大，优先级越高。clusterStateVersion相同时，进入compareNodes，其内部按照节点的Id比较(Id为节点第一次启动时随机生成)。

总结一下：

1. 当clusterStateVersion越大，优先级越高。这是为了保证新Master拥有最新的clusterState(即集群的meta)，避免已经commit的meta变更丢失。因为Master当选后，就会以这个版本的clusterState为基础进行更新。(一个例外是集群全部重启，所有节点都没有meta，需要先选出一个master，然后master再通过持久化的数据进行meta恢复，再进行meta同步)。

   clusterstateversion是集群状态数字版本号，每次更新version+1。

2. 当clusterStateVersion相同时，节点的Id越小，优先级越高。即总是倾向于选择Id小的Node，这个Id是节点第一次启动时生成的一个随机字符串。之所以这么设计，应该是为了让选举结果尽可能稳定，不要出现都想当master而选不出来的情况。

什么时候选举成功？

当一个master-eligible node(我们假设为Node_A)发起一次选举时，它会按照上述排序策略选出一个它认为的master。

• 假设Node_A选Node_B当Master：

Node_A会向Node_B发送join请求，那么此时：

(1) 如果Node_B已经成为Master，Node_B就会把Node_A加入到集群中，然后发布最新的cluster_state, 最新的cluster_state就会包含Node_A的信息。相当于一次正常情况的新节点加入。对于Node_A，等新的cluster_state发布到Node_A的时候，Node_A也就完成join了。

(2) 如果Node_B在竞选Master，那么Node_B会把这次join当作一张选票。对于这种情况，Node_A会等待一段时间，看Node_B是否能成为真正的Master，直到超时或者有别的Master选成功。

(3) 如果Node_B认为自己不是Master(现在不是，将来也选不上)，那么Node_B会拒绝这次join。对于这种情况，Node_A会开启下一轮选举。

• 假设Node_A选自己当Master：

此时NodeA会等别的node来join，即等待别的node的选票，当收集到超过半数的选票时，认为自己成为master，然后变更cluster_state中的master node为自己，并向集群发布这一消息。

按照上述流程，我们描述一个简单的场景来帮助大家理解：

假如集群中有3个master-eligible node，分别为Node_A、Node_B、Node_C，选举优先级也分别为Node_A、Node_B、Node_C。三个node都认为当前没有master，于是都各自发起选举，选举结果都为Node_A(因为选举时按照优先级排序，如上文所述)。于是Node_A开始等join(选票)，Node_B、Node_C都向Node_A发送join，当Node_A接收到一次join时，加上它自己的一票，就获得了两票了(超过半数)，于是Node_A成为Master。此时cluster_state(集群状态)中包含两个节点，当Node_A再收到另一个节点的join时，cluster_state包含全部三个节点。

• Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含-一个主机列表以控制哪些节点需要ping通）这两部分。
• 对所有可以成为master的节点（node master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
• 如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
• master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

Elasticsearch 集群脑裂问题？

脑裂问题，就是同一个集群中的不同节点，对于集群的状态，有了不一样的理解。

由于并发访问量的提高，导致了我们两个节点的集群（分片数默认为5，副本为1，没有固定的master，都是集群中的节点，又做data又做master）状态变成了red，出现了大量的坏片，并且坏掉的都是主分片及其副本。分析发现，是ES集群出现了脑裂问题（俗称精神分裂），即集群中不同的节点对于master的选择出现了分歧，出现了多个master竞争，导致主分片和副本的识别也发生了分歧，对一些分歧中的分片标识为了坏片。

• “脑裂”问题可能的成因：

网络问题：集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对master上的分片和副本标红，分配新的主分片。
节点负载：主节点的角色既为master又为data，访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
内存回收：data 节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。

• 脑裂问题解决方案：

减少误判：discovery.zen ping_timeout 节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。

选举触发：discovery.zen.minimum.master_nodes：1，该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个數大于等于该参数的值，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为(n / 2) +1，n为主节点个数（即有资格成为主节点的节点个数）。

角色分离：即master节点与data节点分离，限制角色

主节点配置为：node master: true，node data: false
从节点配置为：node master: false，node data: true

ES 调优

设计阶段调优

（1）根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；（(31条消息) 高效管理 Elasticsearch 中基于时间的索引_weixin_33941350的博客-CSDN博客）

基于模板+时间+rollover api 滚动创建索引，举例：设计阶段定义：blog 索引的模板格式为：blog_index_时间戳的形式，每天递增数据。这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线 2 的32 次幂-1，索引存储达到了 TB+甚至更大。一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。

（2）使用别名进行索引管理；

（3）每天凌晨定时对索引做 force_merge 操作，以释放空间；

（4）采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink操作，以缩减存储；

​ 冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。对于冷数据不会再写入新数据，可以考虑定期 force_merge 加 shrink 压缩操作，节省存储空间和检索效率。

（5）采取 curator 进行索引的生命周期管理；

（6）仅针对需要分词的字段，合理的设置分词器；

（7）Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。……..

知识点—冷热分离（冷热数据是按照时间推移来区分的）

冷数据（考虑低成本存储）：

1. 不允许更新，偶尔被查询
2. 对访问的响应时间要求不高，通常在1~10秒内都可以接受

热数据（考虑读写性能）：

1. 被频繁查询或更新

2. 对访问的响应时间要求很高，通常在10毫秒以内

因为通常情况下，为了支持热数据的操作特性，需要有较好的硬件配置，比如高性能CPU、大内存、SSD硬盘等等。随着时间的推移，系统里会积累越来越多的历史数据，如果依然采用高配置机器来存放这些使用频率非常低的数据，势必会带来非常高的成本。当然，如果数据量很小或者不计成本，那完全不需要考虑冷热区分，采用一个单体系统就可以应对所有事情了，比如MySQL。

写入调优

（1）写入前副本数设置为 0；

（2）写入前关闭 refresh_interval 设置为-1，禁用刷新机制；

​ 执行刷新操作的频率，这会使索引的最近更改对搜索可见，默认为1s，可以设置-1为禁用刷新，对于写入速率要求较高的场景，可以适当的加大对应的时长，减小磁盘io和segment的生成；

（3）写入过程中：采取 bulk 批量写入；

​ 批量请求显然会大大提升写入速率，且这个速率是可以量化的，官方建议每次批量的数据物理字节数5-15MB是一个比较不错的起点，注意这里说的是物理字节数大小。文档计数对批量大小来说不是一个好指标。比如说，如果你每次批量索引 1000 个文档，记住下面的事实： 1000 个 1 KB 大小的文档加起来是 1 MB 大。 1000 个 100 KB 大小的文档加起来是 100 MB 大。 这可是完完全全不一样的批量大小了。批量请求需要在协调节点上加载进内存，所以批量请求的物理大小比文档计数重要得多。 从 5–15 MB 开始测试批量请求大小，缓慢增加这个数字，直到你看不到性能提升为止。然后开始增加你的批量写入的并发度（多线程等等办法）。 用iostat 、 top 和 ps 等工具监控你的节点，观察资源什么时候达到瓶颈。如果你开始收到 EsRejectedExecutionException ，你的集群没办法再继续了：至少有一种资源到瓶颈了。或者减少并发数，或者提供更多的受限资源（比如从机械磁盘换成 SSD），或者添加更多节点。

（4）写入后恢复副本数和刷新间隔；

（5）尽量使用自动生成的 id。

​ 当写入端使用特定的id将数据写入es时，es会去检查对应的index下是否存在相同的id，这个操作会随着文档数量的增加而消耗越来越大，所以如果业务上没有强需求，建议使用es自动生成的id，加快写入速率

查询调优

（1）禁用 wildcard；

（2）禁用批量 terms（成百上千的场景）；

（3）充分利用倒排索引机制，能 keyword 类型尽量 keyword；

（4）数据量大时候，可以先基于时间敲定索引再检索；

（5）设置合理的路由机制

其他调优

部署调优，业务调优等。

对于 GC 方面，在使用 Elasticsearch 时要注意什么？

（1）倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segmentmemory 增长趋势。

（2）各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用，也就是各类缓存全部占满的时候，还有 heap 空间可以分配给其他任务吗？避免采用 clear cache等“自欺欺人”的方式来释放内存。

（3）避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api 来实现。

（4）cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过 tribe node 连接。

（5）想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做持续的监控。

（6）根据监控数据理解内存需求，合理配置各类circuit breaker，将内存溢出风险降低到最低

在并发情况下，Elasticsearch 如果保证读写一致？

（1）可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；

（2）另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

（3）对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。

什么是网络编程

网络中进程之间如何通信？

本地的进程间通信（IPC）有很多种方式，可以总结为下面4类：

• 消息传递（管道、FIFO、消息队列）
• 同步（互斥量、条件变量、读写锁、文件和写记录锁、信号量）
• 共享内存（匿名的和具名的）
• 远程过程调用（Solaris门和Sun RPC）

网络之间通信首要解决的问题是如何唯一标识一个进程，否则通信无从谈起！在本地可以通过进程PID来唯一标识一个进程，但是在网络中这是行不通的。其实TCP/IP协议族已经帮我们解决了这个问题，网络层的“ip地址”可以唯一标识网络中的主机，而传输层的“协议+端口”可以唯一标识主机中的应用程序（进程）。这样利用三元组（ip地址，协议，端口）就可以标识网络的进程了，网络中的进程通信就可以利用这个标志与其它进程进行交互。

使用TCP/IP协议的应用程序通常采用应用编程接口：UNIX BSD的套接字（socket）和UNIX System V的TLI（已经被淘汰），来实现网络进程之间的通信。就目前而言，几乎所有的应用程序都是采用socket，而现在又是网络时代，网络中进程通信是无处不在，这就是我为什么说“一切皆socket”。

什么是Socket？

socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，都可以用“打开open –> 读写write/read –> 关闭close”模式来操作。我的理解就是Socket就是该模式的一个实现，socket即是一种特殊的文件，一些socket函数就是对其进行的操作（读/写IO、打开、关闭），这些函数我们在后面进行介绍。

1. 简单来说就是IP地址与端口的结合协议（RFC 793）
2. 一种地址与端口的结合描述协议
3. TCP/IP协议的相关API的总称；是网络Api的集合实现

Socket在网络传输中用于唯一标识两个端点之间的连接，端点指 IP + Port

看上面的图，发送端想要发送数据到接收端。首先应用层准备好要发送的数据，然后给了传输层，传输层的主要作用就是为发送端和接收端提供可靠的连接服务，传输层将数据处理完后就给了网络层。网络层的功能就是管理网络，其中一个核心的功能就是路径的选择(路由)，从发送端到接收端有很多条路，网络层就负责管理下一步数据应该到哪个路由器。选择好了路径之后，数据就来到了数据链路层，这一层就是负责将数据从一个路由器送到另一个路由器。然后就是物理层了，可以简单的理解，物理层就是网线一类的最基础的设备。

看一下百度百科对于Socket的介绍：套接字（socket）是一个抽象层，应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。套接字允许应用程序将I/O插入到网络中，并与网络中的其他应用程序进行通信。网络套接字是IP地址与端口的组合。

我们将一个小区比作一台计算机，一台计算机里面跑了很多程序，怎么区分程序呢，用的是端口，就好像小区用门牌号区分每一户人家一样。手机送到小明家了，怎么进去呢？从大门进啊，怎么找到大门呢？门牌号呀。不就相当于从互联网来的数据找到接收端计算机后再根据端口判断应该给哪一个程序一样吗。小明家的入口就可以用小区地址+门牌号进行唯一表示，那么同样的道理，程序也可以用IP+端口号进行唯一标识。那么这个程序的入口就被称作Socket。

现在再来说说什么是Socekt编程，我们将TCP协议简化一下，就只有三个核心功能：建立连接、发送数据以及接收数据。我们再来看一下Java中提供的Socket类中的核心功能：

socket的基本操作

socket() 函数

1

int socket(int domain, int type, int protocol);

socket函数对应于普通文件的打开操作。普通文件的打开操作返回一个文件描述字，而**socket()**用于创建一个socket描述符（socket descriptor），它唯一标识一个socket。这个socket描述字跟文件描述字一样，后续的操作都有用到它，把它作为参数，通过它来进行一些读写操作。

正如可以给fopen的传入不同参数值，以打开不同的文件。创建socket的时候，也可以指定不同的参数创建不同的socket描述符，socket函数的三个参数分别为：

• domain：即协议域，又称为协议族（family）。常用的协议族有，AF_INET、AF_INET6、AF_LOCAL（或称AF_UNIX，Unix域socket）、AF_ROUTE等等。协议族决定了socket的地址类型，在通信中必须采用对应的地址，如AF_INET决定了要用ipv4地址（32位的）与端口号（16位的）的组合、AF_UNIX决定了要用一个绝对路径名作为地址。
• type：指定socket类型。常用的socket类型有，SOCK_STREAM、SOCK_DGRAM、SOCK_RAW、SOCK_PACKET、SOCK_SEQPACKET等等（socket的类型有哪些？）。
• protocol：顾名思义，就是指定协议。常用的协议有，IPPROTO_TCP、IPPTOTO_UDP、IPPROTO_SCTP、IPPROTO_TIPC等，它们分别对应TCP传输协议、UDP传输协议、STCP传输协议、TIPC传输协议。

注意：并不是上面的type和protocol可以随意组合的，如SOCK_STREAM不可以跟IPPROTO_UDP组合。当protocol为0时，会自动选择type类型对应的默认协议。

当我们调用socket创建一个socket时，返回的socket描述字它存在于协议族（address family，AF_XXX）空间中，但没有一个具体的地址。如果想要给它赋值一个地址，就必须调用bind()函数，否则就当调用connect()、listen()时系统会自动随机分配一个端口。

bind()函数

正如上面所说bind()函数把一个地址族中的特定地址赋给socket。例如对应AF_INET、AF_INET6就是把一个ipv4或ipv6地址和端口号组合赋给socket。

1

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

函数的三个参数分别为：

• sockfd：即socket描述字，它是通过socket()函数创建了，唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。

• addr：一个const struct sockaddr * 指针，指向要绑定给sockfd的协议地址。这个地址结构根据地址创建socket时的地址协议族的不同而不同，

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

  如ipv4对应的是： struct sockaddr_in { sa_family_t sin_family; /* address family: AF_INET */ in_port_t sin_port; /* port in network byte order */ struct in_addr sin_addr; /* internet address */ }; /* Internet address. */ struct in_addr { uint32_t s_addr; /* address in network byte order */ }; ipv6对应的是： struct sockaddr_in6 { sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* port number */ uint32_t sin6_flowinfo; /* IPv6 flow information */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* Scope ID (new in 2.4) */ }; struct in6_addr { unsigned char s6_addr[16]; /* IPv6 address */ }; Unix域对应的是： \#define UNIX_PATH_MAX 108 struct sockaddr_un { sa_family_t sun_family; /* AF_UNIX */ char sun_path[UNIX_PATH_MAX]; /* pathname */ };

• addrlen：对应的是地址的长度。

通常服务器在启动的时候都会绑定一个众所周知的地址（如ip地址+端口号），用于提供服务，客户就可以通过它来接连服务器；而客户端就不用指定，有系统自动分配一个端口号和自身的ip地址组合。这就是为什么通常**服务器端在listen之前会调用bind()**，而客户端就不会调用，而是在connect()时由系统随机生成一个。

listen()、connect()函数

如果作为一个服务器，在调用socket()、bind()之后就会调用listen()来监听这个socket，如果客户端这时调用connect()发出连接请求，服务器端就会接收到这个请求。

1

int listen(int sockfd, int backlog);

listen函数的第一个参数即为要监听的socket描述字，第二个参数为相应socket可以排队的最大连接个数。socket()函数创建的socket默认是一个主动类型的，listen函数将socket变为被动类型的，等待客户的连接请求。

1

int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

connect函数的第一个参数即为客户端的socket描述字，第二参数为服务器的socket地址，第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。

accept()函数

TCP服务器端依次调用socket()、bind()、listen()之后，就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就想TCP服务器发送了一个连接请求。TCP服务器监听到这个请求之后，就会调用accept()函数取接收请求，这样连接就建立好了。之后就可以开始网络I/O操作了，即类同于普通文件的读写I/O操作。

1

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

accept函数的第一个参数为服务器的socket描述字，第二个参数为指向struct sockaddr *的指针，用于返回客户端的协议地址，第三个参数为协议地址的长度。如果accpet成功，那么其返回值是由内核自动生成的一个全新的描述字，代表与返回客户的TCP连接。

注意：accept的第一个参数为服务器的socket描述字，是服务器开始调用socket()函数生成的，称为监听socket描述字；而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字，它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字，当服务器完成了对某个客户的服务，相应的已连接socket描述字就被关闭。

read()、write()等函数

至此服务器与客户已经建立好连接了。可以调用网络I/O进行读写操作了，即实现了网咯中不同进程之间的通信！网络I/O操作有下面几组：

• read()/write()
• recv()/send()
• readv()/writev()
• recvmsg()/sendmsg()
• recvfrom()/sendto()

read函数是负责从fd中读取内容.当读成功时，read返回实际所读的字节数，如果返回的值是0表示已经读到文件的结束了，小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的，如果是ECONNREST表示网络连接出了问题。

write函数将buf中的nbytes字节内容写入文件描述符fd.成功时返回写的字节数。失败时返回-1，并设置errno变量。 在网络程序中，当我们向套接字文件描述符写时有俩种可能。1)write的返回值大于0，表示写了部分或者是全部的数据。2)返回的值小于0，此时出现了错误。我们要根据错误类型来处理。如果错误为EINTR表示在写的时候出现了中断错误。如果为EPIPE表示网络连接出现了问题(对方已经关闭了连接)。

close()函数

在服务器与客户端建立连接之后，会进行一些读写操作，完成了读写操作就要关闭相应的socket描述字，好比操作完打开的文件要调用fclose关闭打开的文件。

1

#include <unistd.h>int close(int fd);

close一个TCP socket的缺省行为时把该socket标记为已关闭，然后立即返回到调用进程。该描述字不能再由调用进程使用，也就是说不能再作为read或write的第一个参数。

注意：close操作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求。

socket中发送的TCP三次握手

从图中可以看出，当客户端调用connect时，触发了连接请求，向服务器发送了SYN J包，这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包，调用accept函数接收请求向客户端发送SYN K ，ACK J+1，这时accept进入阻塞状态；客户端收到服务器的SYN K ，ACK J+1之后，这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时，accept返回，至此三次握手完毕，连接建立。

socket中TCP的四次握手释放连接

图示过程如下：

• 某个应用进程首先调用close主动关闭连接，这时TCP发送一个FIN M；
• 另一端接收到FIN M之后，执行被动关闭，对这个FIN进行确认。它的接收也作为文件结束符传递给应用进程，因为FIN的接收意味着应用进程在相应的连接上再也接收不到额外数据；
• 一段时间之后，接收到文件结束符的应用进程调用close关闭它的socket。这导致它的TCP也发送一个FIN N；
• 接收到这个FIN的源发送端TCP对它进行确认。

这样每个方向上都有一个FIN和ACK。

IO简介

JAVA IO

IO编程模型

用什么样的通道进行数据的发送和接收（异步/同步、单通道/双通道、有/无缓冲、阻塞/非阻塞）

BIO

同步阻塞IO（传统阻塞型），一个连接对应一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，可以通过线程池机制改善。一般适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高。

BIO编程简单流程：

1. 服务器端启动一个SeverSocket，然后使用**accept()**来等待客户端与之连接，并一直阻塞在这，直到客户端发来连接。

2. 客户端启动Socket对服务器进行通信，默认情况下服务器需要对每个客户建立一个线程与之通信。

3. 客户端发出请求后，先咨询服务器是否有线程响应，如果没有则会等待，或者被拒绝。

4. 如果有响应，客户端线程会等待请求结束后，再继续执行。

注：建立连接后，如果当前线程暂时没有数据可读，则线程就阻塞在Read操作上，造成线程资源的浪费

NIO（面向缓冲区编程）

java NIO 全称 java non-blocking IO，是指JDK提供的新的API。同步非阻塞，服务器实现模式为一个线程处理多个请求，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求就进行处理。一般用于连接数目多且连接比较短的架构。

NIO的三大核心部分： Selector、Buffer、channel。

服务器端：首先开启一个ServerSocketchannel，这个ServerSocketchannel相当于BIO中的ServerSocket，ServerSocketchannel通过bind函数绑定所要监听的端口，然后将ServerSocketchannel注册到selector上。

遍历selector中的通道，判断通道是否准备就绪，并执行相应的业务（比如说处理连接的通道发现有连接进来，就再新建一个通道；如果有通道有读写操作，就执行相应的读写操作。但整个过程也是同步的，要前面的事件执行完再去执行下一个事件，但是这个通道没有IO请求，也就不会阻塞在这），把数据写到通道中，或者读取到缓冲区中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public static void main(String[] args) throws  Exception{
        //创建ServerSocketChannel，-->> ServerSocket
        ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
        InetSocketAddress inetSocketAddress = new InetSocketAddress(5555);
        serverSocketChannel.socket().bind(inetSocketAddress);
        serverSocketChannel.configureBlocking(false); //设置成非阻塞
 
        //开启selector,并注册accept事件
        Selector selector = Selector.open();
        serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);
 
        while(true) {
            selector.select(2000);  //监听所有通道
            //遍历selectionKeys
            Set<SelectionKey> selectionKeys = selector.selectedKeys();
            Iterator<SelectionKey> iterator = selectionKeys.iterator();
            while (iterator.hasNext()) {
                SelectionKey key = iterator.next();
                if(key.isAcceptable()) {  //处理连接事件
                    SocketChannel socketChannel = serverSocketChannel.accept();
                    socketChannel.configureBlocking(false);  //设置为非阻塞
                    System.out.println("client:" + socketChannel.getLocalAddress() + " is connect");
                    socketChannel.register(selector, SelectionKey.OP_READ); //注册客户端读取事件到selector
                } else if (key.isReadable()) {  //处理读取事件
                    ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
                    SocketChannel channel = (SocketChannel) key.channel();
                    channel.read(byteBuffer);
                    System.out.println("client:" + channel.getLocalAddress() + " send " + new String(byteBuffer.array()));
                }
                iterator.remove();  //事件处理完毕，要记得清除
            }
        }
 
    }

客户端：开启一个SocketChannel，然后调用connect方法与服务器端进行连接。将数据从缓冲区写到通道或者从通道读数据到缓冲区

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public static void main(String[] args) throws Exception{
        SocketChannel socketChannel = SocketChannel.open();
        socketChannel.configureBlocking(false);
        InetSocketAddress inetSocketAddress = new InetSocketAddress("127.0.0.1", 5555);
 
        if(!socketChannel.connect(inetSocketAddress)) {
            while (!socketChannel.finishConnect()) {
                System.out.println("客户端正在连接中，请耐心等待");
            }
        }
 
        ByteBuffer byteBuffer = ByteBuffer.wrap("hello,world".getBytes());
        socketChannel.write(byteBuffer);
        socketChannel.close();
    }

Selector

Selector能够检测多个注册的通道上是否有事件发生(注意:多个Channel以事件的方式可以注册到同一个Selector)，如果有事件发生，便获取事件然后针对每个事件进行相应的处理。这样就可以只用一个单线程去管理多个通道，也就是管理多个连接和请求。只有在通道真正有读写请求事件发生时，才会进行读写，大大的减少了系统开销。

将channel注册（register方法）到selector上（每一个channel对应一个selectionKey，注册后会放入集合中），selector对这些通道进行监控，就是调用select方法，该方法会返回一个selectionKey类型的集合。一旦监控到有IO事件发生，得到有时间发生的selectionKey，通过selectionKey反向获取通道。

注：select方法是一个阻塞方法，直到注册的channel里至少有一个事件发生才会返回；

select(long timeout) timeout时间内阻塞

selectNow() 非阻塞

Buffer

本质上是一个可以读写数据的内存块。可以理解成是一个容器对象(含数组)，该对象提供了一组方法，可以更轻松地使用内存块，缓冲区对象内置了一些机制，能够跟踪和记录缓冲区的状态变化情况。Channel 提供从文件、网络读取数据的渠道，但是读取或写入的数据都必须经由 Buffer。

Channel

1. 每个 channel 都会对应一个 Buffer
2. Selector 对应一个线程，一个线程对应多个 channel(连接)
3. 该图反应了有三个 channel 注册到该 selector
4. 程序切换到哪个 channel 是由事件决定的， Event 就是一个重要的概念
5. Selector 会根据不同的事件，在各个通道上切换
6. Buffer 就是一个内存块 ，底层是有一个数组
7. 数据的读取写入是通过 Buffer, 这个和 BIO有本质区别，BIO 中要么是输入流，或者是输出流，不能双向，但是 NIO 的 Buffer 是可以读也可以写，需要 flip 方法切换。
8. channel是双向的，可以返回底层操作系统的情况，比如 Linux，底层的操作系统通道就是双向的

Java NIO的非阻塞模式，使一个线程从某通道发送请求或者读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取，而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此，一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。

BIO和NIO区别

1. BIO以流的方式处理数据，而NIO以块的方式处理数据，块I/O的效率比流I/O高很多
2. BIO是阻塞的，NIO则是非阻塞的
3. BIO基于字节流和字符流进行操作，而NIO基于Channel(通道)和Buffer(缓冲区)进行操作，数据总是从通道读取到缓冲区中，或者从缓冲区写入到通道中。Selector(选择器)用于监听多个通道的事件（比如：连接请求，数据到达等），因此使用单个线程就可以监听多个客户端通道

AIO

异步非阻塞，jdk1.7引入，AIO 引入了异步通道的概念，采用了Proactor模式，简化了程序编写，有效的请求才启动线程，它的特点是先由操作系统完成后才通知服务端程序启动线程去处理，一般适用于连接数较多且连接时间较长的应用。

操作系统 IO

epoll管理成千上万的网络IO，epoll是实现事件循环的技术

1. 单线程epoll redis
2. 多线程epoll mamcached
3. 多进程epoll

epoll 底层数据结构： 红黑树和就绪队列

epoll在创建的时候，实际是创建了红黑树的root节点

epoll由下面三个函数组成

epoll_create

epoll_ctl

epoll_wait 多长时间去轮询一次，返回所有的IO中有多少个可读可写，比如说返回值用nready表示

redis：

然后对这些就绪好的事件进行轮询，判断事件类型，可以按照事件类型将事件大致分为两类：

1. sockfd：相当于listenfd，然后执行accept方法
2. 其他类型事件：执行recv方法或者send方法

上述是单线程，但如何兼容多核CPU：多开几个redis进程

互联网服务端处理网络请求的原理

首先看看一个典型互联网服务端处理网络请求的典型过程：

由上图可以看到，主要处理步骤包括：

• 1）获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）；
• 2）构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）；
• 3）返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）。

设计服务端并发模型时，主要有如下两个关键点：

• 1）服务器如何管理连接，获取输入数据；
• 2）服务器如何处理请求。

以上两个关键点最终都与操作系统的 I/O 模型以及线程(进程)模型相关，下面先详细介绍I/O模型。

I/O 模型的基本认识

介绍操作系统的 I/O 模型之前，先了解一下几个概念：

• 1）阻塞调用与非阻塞调用；
• 2）阻塞调用是指调用结果返回之前，当前线程会被挂起，调用线程只有在得到结果之后才会返回；
• 3）非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。

两者的最大区别在于被调用方在收到请求到返回结果之前的这段时间内，调用方是否一直在等待。

阻塞是指调用方一直在等待而且别的事情什么都不做；非阻塞是指调用方先去忙别的事情。

同步处理与异步处理：同步处理是指被调用方得到最终结果之后才返回给调用方；异步处理是指被调用方先返回应答，然后再计算调用结果，计算完最终结果后再通知并返回给调用方。

阻塞、非阻塞和同步、异步的区别（阻塞、非阻塞和同步、异步其实针对的对象是不一样的）：

• 1）阻塞、非阻塞的讨论对象是调用者；
• 2）同步、异步的讨论对象是被调用者。

recvfrom 函数：
recvfrom 函数(经 Socket 接收数据)，这里把它视为系统调用。

一个输入操作通常包括两个不同的阶段：

• 1）等待数据准备好；
• 2）从内核向进程复制数据。

对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用进程缓冲区。

实际应用程序在系统调用完成上面的 2 步操作时，调用方式的阻塞、非阻塞，操作系统在处理应用程序请求时，处理方式的同步、异步处理的不同，可以分为 5 种 I/O 模型（下面的章节将逐个展开介绍）。（参考《UNIX网络编程卷1》）

I/O模型1：阻塞式 I/O 模型(blocking I/O）

在阻塞式 I/O 模型中，应用程序在从调用 recvfrom 开始到它返回有数据报准备好这段时间是阻塞的，recvfrom 返回成功后，应用进程开始处理数据报。（也就是说读写完数据后进程才会去干其他事情）

比喻：一个人在钓鱼，当没鱼上钩时，就坐在岸边一直等。
优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源。
缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，这种模型在实际生产中很少使用。

I/O模型2：非阻塞式 I/O 模型(non-blocking I/O）

在非阻塞式 I/O 模型中，应用程序把一个套接口设置为****非阻塞，就是告诉内核，当所请求的 I/O 操作无法完成时，不要将进程睡眠。

而是返回一个错误，应用程序基于 I/O 操作函数将不断的轮询数据是否已经准备好，如果没有准备好，继续轮询，直到数据准备好为止。

比喻：边钓鱼边玩手机，隔会再看看有没有鱼上钩，有的话就迅速拉杆。
优点：不会阻塞在内核的等待数据过程，每次发起的 I/O 请求可以立即返回，不用阻塞等待，实时性较好。
缺点：轮询将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低，所以一般 Web 服务器不使用这种 I/O 模型。

I/O模型3：I/O 复用模型(I/O multiplexing）

在 I/O 复用模型中，会用到 Select 或 Poll 函数或 Epoll 函数(Linux 2.6 以后的内核开始支持)，这两个函数也会使进程阻塞，但是和阻塞 I/O 有所不同。

这两个函数可以同时阻塞多个 I/O 操作，而且可以同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。

比喻：放了一堆鱼竿，在岸边一直守着这堆鱼竿，没鱼上钩就玩手机。
优点：可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程)，这样可以大大节省系统资源。
缺点：当连接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，因为单个连接处理需要 2 次系统调用，占用时间会有增加。
众所周之，Nginx这样的高性能互联网反向代理服务器大获成功的关键就是得益于Epoll。

I/O模型4：信号驱动式 I/O 模型（signal-driven I/O)

在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续运行并不阻塞。

当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。

比喻：鱼竿上系了个铃铛，当铃铛响，就知道鱼上钩，然后可以专心玩手机。
优点：线程并没有在等待数据时被阻塞，可以提高资源的利用率。
缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知。

信号驱动 I/O 尽管对于处理 UDP 套接字来说有用，即这种信号通知意味着到达一个数据报，或者返回一个异步错误。

但是，对于 TCP 而言，信号驱动的 I/O 方式近乎无用，因为导致这种通知的条件为数众多，每一个来进行判别会消耗很大资源，与前几种方式相比优势尽失。

I/O模型5：异步 I/O 模型（即AIO，全称asynchronous I/O）

由 POSIX 规范定义，应用程序告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到应用程序的缓冲区）完成后通知应用程序。

这种模型与信号驱动模型的主要区别在于：信号驱动 I/O 是由内核通知应用程序何时启动一个 I/O 操作，而异步 I/O 模型是由内核通知应用程序 I/O 操作何时完成。

优点：异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠。
缺点：要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O。

而在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时都是以 IO 复用模型模式为主。

关于AIO的介绍，请见：《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》。

5 种 I/O 模型总结

从上图中我们可以看出，越往后，阻塞越少，理论上效率也是最优。

这五种 I/O 模型中，前四种属于同步 I/O，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配。

数据库与缓存一致性问题

使用缓存目的

通常情况下，我们使用缓存的主要目的是为了提高查询性能，大多数情况下，我们是这样使用缓存的：

1. 首先用户请求过来，会先查询缓存中有没有想要的数据，如果有就直接返回。
2. 如果缓存中没有该数据，就去查询数据库。
3. 如果数据库中有数据，就将查询出来的数据，放入缓存中，然后返回该数据。
4. 如果数据库中也没有该数据，就返回空。

那如果有数据需要更新，应该怎么操作呢？

目前有4种方案：

1. 先写缓存，再写数据库
2. 先写数据库，再写缓存
3. 先删缓存，再写数据库
4. 先写数据库，再删缓存

先写缓存，再写数据库

如果采用先写缓存，再写数据库的方式，会有这种问题（是四种方式中最严重的）：

用户执行写操作，首先写缓存，然后此时网络出现了问题，导致没有成功写到数据库

那这样的话，缓存更新为了最新数据，而数据库还是旧数据，这样缓存中的数据就变成了“脏数据”。我们都知道缓存的主要目的是把数据库中的数据临时保存在内存，便于后续查询，提升查询速度。但如果某条数据，在数据库中都不存在，你缓存这种“假数据”又有啥意义呢？因此，先写缓存，再写数据库的方案是不可取的，在实际工作中用得不多。

先写数据库，再写缓存

用户的写操作，先写数据库，再写缓存，可以避免之前“假数据”的问题。但它却带来了新的问题。

写缓存失败了

如果把写数据库和写缓存操作，放在同一个事务当中，当写缓存失败了，我们可以把写入数据库的数据进行回滚。

如果是并发量比较小，对接口性能要求不太高的系统，可以这么玩。

但如果在高并发的业务场景中，写数据库和写缓存，都属于远程操作。为了防止出现大事务，造成的死锁问题，通常建议写数据库和写缓存不要放在同一个事务中。

也就是说在该方案中，如果写数据库成功了，但写缓存失败了，数据库中已写入的数据不会回滚。

这就会出现：数据库是新数据，而缓存是旧数据，两边数据不一致的情况

高并发下的问题

假设在高并发的场景中，针对同一个用户的同一条数据，有两个写数据请求：a和b，它们同时请求到业务系统。

其中请求a获取的是旧数据，而请求b获取的是新数据，如下图所示：

1. 请求a先过来，写完了数据库，由于网络问题，还没来得及写缓存。
2. 这时请求b过来了，先写了数据库。
3. 接下来，请求b顺利写了缓存。
4. 此时，请求a的卡顿结束，也写了缓存。

很显然，在这个过程中，请求b在缓存中的新数据，被请求a中的旧数据覆盖了。也就是说，在高并发场景下，如果多个线程同时执行先写数据库，再写缓存的操作，可能出现数据库中是新值，而缓存中是旧值的情况。

浪费系统资源

如果写的缓存，并不是简单的数据内容，而是要经过非常复杂的计算得出的最终结果。这样每写一次缓存，都要经过一次非常复杂的计算，就会十分浪费资源（CPU和内存）。

对一些写操作多、读操作少的业务场景，这种做法也是得不偿失。

先删缓存，再删数据库

高并发下的问题

假设在高并发的场景中，同一个用户的同一条数据，有一个读数据请求c，还有另一个写数据请求d（一个更新操作），同时请求到业务系统。如下图所示：

1. 请求d先过来，把缓存删除了，由于网络原因，卡顿了一下，还没来得及写数据库。

2. 这时请求c过来了，查缓存发现没有数据，再查数据库，有数据，但是旧值。

3. 请求c将数据库中的旧值更新到缓存中。

4. 此时，请求d卡顿结束，把新值写入数据库。

   在这个过程当中，