凉凉：
（1）自我介绍
（2）最近比较熟悉的项目
（3）平时怎么打日志的，日志记录哪些内容，存文件还是，按行存还是（黑人脸？？？？）
（4）数据库索引，为什么用B+树
(5) Redis持久化方式
（6）https协议，还有HTTP数据包格式
（7）分布式事务一致性（RabbitMQ）
（8）0-99不重复数组在100长度数组中，O(n)时间，O(1)空间。。。尼玛的这就是脑静急转弯，直接A[n] = n进行哈希
(9)单链表翻转
（一）数据库索引，为什么用B+树?
1.B树
B树（B-tree）是一种树状数据结构，它能够存储数据、对其进行排序并允许以O(log n)的时间复杂度运行进行查找、顺序读取、插入和删除的数据结构。B树，概括来说是一个节点可以拥有多于2个子节点的二叉查找树。与自平衡二叉查找树不同，B-树为系统最优化大块数据的读和写操作。B-tree算法减少定位记录时所经历的中间过程，从而加快存取速度。普遍运用在数据库和文件系统。”
B 树可以看作是对2-3查找树的一种扩展，即他允许每个节点有M-1个子节点。
1.1定义
根节点至少有两个子节点
每个节点有M-1个key，并且以升序排列
位于M-1和M key的子节点的值位于M-1 和M key对应的Value之间
其它节点至少有M/2个子节点
下图是一个M=4 阶的B树:
2.B+树
B+树是对B树的一种变形树，它与B树的差异在于：
有k个子结点的结点必然有k个关键码。
非叶结点仅具有索引作用，跟记录有关的信息均存放在叶结点中。
树的所有叶结点构成一个有序链表，可以按照关键码排序的次序遍历全部记录。
如下图是一个M=4的B+树：
B+树和B树的区别
B+树的非叶子结点只包含导航信息，不包含实际的值，所有的叶子结点和相连的节点使用链表相连，便于区间查找和遍历。
B+ 树的优点在于：
- IO次数更少：由于B+树在内部节点上不包含数据信息，因此在内存页中能够存放更多的key。 数据存放的更加紧密，具有更好的空间局部性。因此访问叶子节点上关联的数据也具有更好的缓存命中率。
- 遍历更加方便：B+树的叶子结点都是相链的，因此对整棵树的遍历只需要一次线性遍历叶子结点即可。而且由于数据顺序排列并且相连，所以便于区间查找和搜索。而B树则需要进行每一层的递归遍历。相邻的元素可能在内存中不相邻，所以缓存命中性没有B+树好。 但是B树也有优点，其优点在于，由于B树的每一个节点都包含key和value，因此经常访问的元素可能离根节点更近，因此访问也更迅速。下面是B 树和B+树的区别图:
为什么MySQL选择B+树做索引
-
B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。
-
B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
-
B+树更便于遍历：由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。
-
B+树更适合基于范围的查询：B树在提高了IO性能的同时并没有解决元素遍历的效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。 InnoDB的一棵B+树可以存放多少行数据？
答案：约2千万 zhuanlan.zhihu.com/p/81273236?…
为什么是这么多？ 因为这是可以算出来的，要搞清楚这个问题，先从InnoDB索引数据结构、数据组织方式说起。
计算机在存储数据的时候，有最小存储单元，这就好比现金的流通最小单位是一毛。
在计算机中，磁盘存储数据最小单元是扇区，一个扇区的大小是512字节，而文件系统（例如XFS/EXT4）的最小单元是块，一个块的大小是4k，而对于InnoDB存储引擎也有自己的最小储存单元，页（Page），一个页的大小是16K。
下面几张图可以理解最小存储单元：
文件系统中一个文件大小只有1个字节，但不得不占磁盘上4KB的空间。
InnoDB的所有数据文件（后缀为ibd的文件），大小始终都是16384（16k）的整数倍。
磁盘扇区、文件系统、InnoDB存储引擎都有各自的最小存储单元。
在MySQL中，InnoDB页的大小默认是16k，当然也可以通过参数设置：
表中的数据都是存储在页中的，所以一个页中能存储多少行数据呢？
假设一行数据的大小是1k，那么一个页可以存放16行这样的数据。
如果数据库只按这样的方式存储，如何查找数据就成为一个问题，因为不知道要查找的数据存在哪个页中，也不可能把所有的页遍历一遍，那样太慢了。不过，可以使用B+树的方式组织这些数据，如图所示：
先将数据记录按主键进行排序，分别存放在不同的页中（为了便于理解这里一个页中只存放3条记录，实际情况可以存放很多）
除了存放数据的页以外，还有存放键值+指针的页，如图中page number=3的页，该页存放键值和指向数据页的指针，这样的页由N个键值+指针组成。
当然它也是排好序的。这样的数据组织形式，我们称为索引组织表。
现在来看下，要查找一条数据，怎么查？
如：select * from user where id=5;
这里id是主键，通过这棵B+树来查找，首先找到根页，你怎么知道user表的根页在哪呢？
其实每张表的根页位置在表空间文件中是固定的，即page number=3的页。
找到根页后通过二分查找法，定位到id=5的数据应该在指针P5指向的页中，那么进一步去page number=5的页中查找，同样通过二分查询法即可找到id=5的记录：
| 5 | zhao2 | 27 |
现在清楚了InnoDB中主键索引B+树是如何组织数据、查询数据的。
总结一下：
InnoDB存储引擎的最小存储单元是页，页可以用于存放数据也可以用于存放键值+指针，在B+树中叶子节点存放数据，非叶子节点存放键值+指针。 索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中，进而在去数据页中查找到需要的数据； 那么回到我们开始的问题，通常一棵B+树可以存放多少行数据？
这里我们先假设B+树高为2，即存在一个根节点和若干个叶子节点，那么这棵B+树的存放总记录数为：根节点指针数*单个叶子节点记录行数。
上文已经说明单个叶子节点（页）中的记录数=16K/1K=16。（这里假设一行记录的数据大小为1k，实际上现在很多互联网业务数据记录大小通常就是1K左右）。
那么现在需要计算出非叶子节点能存放多少指针？
其实这也很好算，假设主键ID为bigint类型，长度为8字节，而指针大小在InnoDB源码中设置为6字节，这样一共14字节
我们一个页中能存放多少这样的单元，其实就代表有多少指针，即16384/14=1170。
那么可以算出一棵高度为2的B+树，能存放1170*16=18720条这样的数据记录。
根据同样的原理可以算出一个高度为3的B+树可以存放：1170117016=21902400条这样的记录。
所以在InnoDB中B+树高度一般为1-3层，它就能满足千万级的数据存储。
在查找数据时，一次页的查找代表一次IO，所以通过主键索引查询通常只需要1-3次IO操作即可查找到数据。
怎么得到InnoDB主键索引B+树的高度？
上面通过推断得出B+树的高度通常是1-3，下面从另外一个侧面证明这个结论。
在InnoDB的表空间文件中，约定page number为3的代表主键索引的根页，而在根页偏移量为64的地方存放了该B+树的page level。
如果page level为1，树高为2，page level为2，则树高为3。即B+树的高度=page level+1；下面将从实际环境中尝试找到这个page level。
linetem表的page level为2，B+树高度为page level+1=3；
region表的page level为0，B+树高度为page level+1=1；
customer表的page level为2，B+树高度为page level+1=3；
这三张表的数据量如下：
总结：
lineitem表的数据行数为600多万，B+树高度为3，customer表数据行数只有15万，B+树高度也为3。可以看出尽管数据量差异较大，这两个表树的高度都是3
换句话说这两个表通过索引查询效率并没有太大差异，因为都只需要做3次IO。那么如果有一张表行数是一千万，那么他的B+树高度依旧是3，查询效率仍然不会相差太大。
region表只有5行数据，当然他的B+树高度为1。
（二）Redis持久化方式
1. RDB：对内存中数据库状态进行快照
- AOF：把每条写命令都写入文件，类似mysql的binlog日志
RDB方式：将Redis在内存中的数据库状态保存到磁盘里面，RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态
1）执行命令手动生成
有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求，创建RDB文件结束之前，客户端发送的BGSAVE和SAVE命令会被服务器拒绝
2）通过配置自动生成
可以设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令，可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令
例如：
save 900 1
save 300 10
save 60 10000
那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行
服务器在900秒之内，对数据库进行了至少1次修改
服务器在300秒之内，对数据库进行了至少10次修改
服务器在60秒之内，对数据库进行了至少10000次修改
AOF方式：是通过保存Redis服务器所执行的写命令来记录数据库状态的AOF文件刷新的方式，有三种：
appendfsync always - 每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全 appendfsync everysec - 每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据 appendfsync no - 依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差 默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾
数据恢复
1、RDB方式
RDB文件的载入工作是在服务器启动时自动执行的，没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件存在，它就会自动载入RDB文件，服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止
2、AOF方式
服务器在启动时，通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态，具体过程：
载入AOF文件
创建模拟客户端
从AOF文件中读取一条命令
使用模拟客户端执行命令
循环读取并执行命令，直到全部完成
如果同时启用了RDB和AOF方式，AOF优先，启动时只加载AOF文件恢复数据
(三) https协议，数据包格式
HTTP协议
HTTP（HyperText Transfer Protocol）即超文本传输协议，是一种详细规定了浏览器和万维网服务器之间互相通信的规则，它是万维网交换信息的基础，它允许将HTML（超文本标记语言）文档从Web服务器传送到Web浏览器。
比较详细的文章：
hanking.blog.csdn.net/article/det…
HTTP协议目前最新版的版本是1.1，HTTP是一种无状态的协议，无状态是指Web浏览器与Web服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后Web服务器返回响应（Response），连接就被关闭了，在服务器端不保留连接的有关信息。也就是说，HTTP请求只能由客户端发起，而服务器不能主动向客户端发送数据。
HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。
HTTP工作原理
HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
Web服务器有：Apache服务器，IIS服务器（Internet Information Services）等。
Web服务器根据接收到的请求后，向客户端发送响应信息。
HTTP默认端口号为80，但是你也可以改为8080或者其他端口。
- HTTP三点注意事项：
HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
HTTP是无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
HTTP请求与响应
HTTP遵循请求（Request）/应答（Response）模型，Web浏览器向Web服务器发送请求时，Web服务器处理请求并返回适当的应答。
HTTP请求：
POST /test.php HTTP/1.1 //请求行
HOST：www.test.com //请求头
User-Agent：Mozilla/5.0 （windows NT 6.1；rv：15.0）Gecko/20100101 Firefox/15.0 //空白行，代表请求头结束
Username=admin&password=admin //请求正文
HTTP请求包括三部分，分别是请求行（请求方法）、请求头（消息报头）和请求正文。
HTTP请求第一行为请求行（请求方法），由三部分组成，第一部分说明了该请求是POST请求，第二部分是一个斜杠（/login.java），用来说明请求是该域名根目录下的login.java，第三部分说明使用的是HTTP1.1版本。
HTTP请求第二行至空白行为请求头（也被称为消息头）。其中，HOST代表请求主机地址，User-Agent代表浏览器的标识，请求头由客户端自行设定。
HTTP请求第三行为请求正文，请求正文是可选的，它最常出现在POST请求方式中。
根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了五种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
GET、POST、HEAD、PUT请求：
-
GET：GET方法用于获取请求页面的指定信息。如果请求资源为动态脚本（非HTML），那么返回文本是Web容器解析后的HTML源代码。GET请求没有消息主体，因此在消息头后的空白行是没有其他数据。
-
POST：POST方法也与GET方法相似，但最大的区别在于，GET方法没有请求内容，而POST是有请求内容的。
-
HEAD：这个请求的功能与GET请求相似，不同之处在于服务器不会再其响应中返回消息主体，因此，这种方法可用于检查某一资源在向其提交GET请求前是否存在。
-
PUT：PUT方法用于请求服务器把请求中的实体存储在请求资源下，如果请求资源已经在服务器中存在，那么将会用此请求中的数据替换原先的数据。向服务器上传指定的资源。
HTTP响应：
HTTP/1.1 200 OK //响应行
Date: Sun, 15 Nov 2015 11:02:04 GMT //响应头
Server: bfe/1.0.8.9
Content-Length: 2605
Content-Type: application/javascript
Cache-Control: max-age=315360000
Expires: Fri, 13 Jun 2025 09:54:00 GMT
Content-Encoding: gzip
Set-Cookie: H_PS_PSSID=2022_1438_1944_1788; path=/; domain=test.com
Connection: keep-alive
//空白行，代表响应头结束
<html>
<head><title> Index.html </title></head> //响应正文消息主题
HTTP响应的第一行为响应行，其中有HTTP版本（HTTP/1.1）、状态码（200）以及消息“OK”。
第二行至末尾的空白行为响应头，由服务器向客户端发送。
消息头之后是响应正文，是服务器向客户端发送的HTML数据。
HTTP消息头：
请求头：请求头只出现在HTTP请求中，请求报头允许客户端向服务端传递请求的附加信息和客户端自身信息。
响应头：响应头是服务器根据请求向客户端发送的HTTP头。
HTTP请求头：
- Host 请求报头域主要用于指定被请求资源的Internet主机和端口。
- User-Agent 请求报头域允许客户端将它的操作系统、浏览器和其他属性告诉服务器。
- Referer 包含一个URL，代表当前访问URL的上一个URL，也就是说，用户是从什么地方来到本页面。当前请求的原始URL地址。
- Cookie 是非常重要的请求头，常用来表示请求者的身份等。
- Accept 这个消息头用于告诉服务器客户端愿意接受那些内容，比如图像类，办公文档格式等等。 HTTP响应头信息：
拦截HTTP请求的分析点：
HTTP状态与会话
HTTP状态码：
当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。
HTTP状态码的英文为HTTP Status Code。
五种状态码：
1xx：信息提示，表示请求已被成功接收，继续处理。
2xx：请求被成功提交。
3xx：客户端被重定向到其他资源。
4xx：客户端错误状态码，格式错误或者不存在资源。
5xx：描述服务器内部错误。
常见的状态码描述如下：
200：客户端请求成功，是最常见的状态。
302：重定向。
404：请求资源不存在，是最常见的状态。
400：客户端请求有语法错误，不能被服务器所理解。
401：请求未经授权。
403：服务器收到请求，但是拒绝提供服务。
500：服务器内部错误，是最常见的状态。
503：服务器当前不能处理客户端的请求。
会话与会话状态简介：
WEB应用中的会话是指一个客户端浏览器与WEB服务器之间连续发生的一系列请求和响应过程。
WEB应用的会话状态是指WEB服务器与浏览器在会话过程中产生的状态信息，借助会话状态，WEB服务器能够把属于同一会话中的一系列的请求和响应过程关联起来。 如何实现有状态的会话：
某个用户从网站的登录页面登入后，在进入购物页面购物时，负责处理购物请求的服务器程序必须知道处理上一次请求的程序所得到的用户信息。
HTTP协议是一种无状态的协议，WEB服务器本身不能识别出哪些请求是同一个浏览器发出的 ，浏览器的每一次请求都是完全孤立的。
WEB服务器端程序要能从大量的请求消息中区分出哪些请求消息属于同一个会话，即能识别出来自同一个浏览器的访问请求，这需要浏览器对其发出的每个请求消息都进行标识，属于同一个会话中的请求消息都附带同样的标识号，而属于不同会话的请求消息总是附带不同的标识号，这个标识号就称之为会话ID（SessionID）。
会话ID可以通过一种称之为Cookie的技术在请求消息中进行传递，也可以作为请求URL的附加参数进行传递。会话ID是WEB服务器为每客户端浏览器分配的一个唯一代号，它通常是在WEB服务器接收到某个浏览器的第一次访问时产生，并且随同响应消息一道发送给浏览器。
会话过程由WEB服务器端的程序开启，一旦开启了一个会话，服务器端程序就要为这个会话创建一个独立的存储结构来保存该会话的状态信息，同一个会话中的访问请求都可以且只能访问属于该会话的存储结构中的状态信息。 Cookie技术：
Cookie是一种在客户端保持HTTP状态信息的技术，它好比商场发放的优惠卡。
Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一片数据，WEB服务器传送给各个客户端浏览器的数据是可以各不相同的。
一旦WEB浏览器保存了某个Cookie，那么它在以后每次访问该WEB服务器时，都应在HTTP请求头中将这个Cookie回传给WEB服务器。
Cookie技术最先被Netscape公司引入到 Navigator浏 览器中。
现在，绝大多数浏览器都支持Cookie，或者至少兼容 Cookie技 术的使用。
Cookie是一小段文本信息，伴随着用户请求和页面在Web服务器和浏览器之间传递。Cookie包含每次用户访问站点时Web应用程序都可以读取的信息。
Cookie只是一段文本，所以它只能保存字符串。
WEB服务器通过在HTTP响应消息中增加Set-Cookie响应头字段将Cookie信息发送给浏览器，浏览器则通过在HTTP请求消息中增加Cookie请求头字段将Cookie回传给WEB服务器。
一个Cookie只能标识一种信息，它至少含有一个标识该信息的名称（NAME）和设置值（VALUE）。
一个WEB站点可以给一个WEB浏览器发送多个Cookie，一个WEB浏览器也可以存储多个WEB站点提供的Cookie。
浏览器一般只允许存放300个Cookie，每个站点最多存放20个Cookie，每个Cookie的大小限制为4KB。
Cookie的传送过程示意图：
单链表翻转
public class ListNode {
int val;
ListNode next = null;
ListNode(int val) {
this.val = val;
}
}
public class Solution {
public ListNode ReverseList(ListNode head) {
ListNode p = head;
if(p == null){
return null;
}
if(p.next == null)
return p;
ListNode s = p;
ListNode q = p.next;
p = q.next;
s.next = null;
q.next = s;
while(p != null){
s = q;
q = p;
p = p.next;
q.next = s;
}
return q;
}
}
