软件面试相关

计算机网络部分

HTTPS和HTTP的区别

1.HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全， HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
2. https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
3. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

http长连接和短连接的区别

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。而从HTTP/1.1起，默认使用长连接，用以保持连接特性。什么是TCP粘包/拆包？发生原因？解决方案一个完整的业务可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这个就是TCP的拆包和粘包问题。
原因：
1.应用程序写入数据的字节大小大于套接字发送缓冲区的大小.
2. 进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)
3. 以太网的payload大于MTU进行IP分片。（ MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。）
解决方案：
1.消息定长。
2. 在包尾部增加回车或者空格符等特殊字符进行分割
3. 将消息分为消息头和消息尾。
4. 使用其它复杂的协议，如RTMP协议等。

什么是SSL ？https是如何保证数据传输的安全（SSL是怎么工作保证安全的）

SSL代表安全套接字层。它是一种用于加密和验证应用程序（如浏览器）和Web服务器之间发送的数据的协议。 身份验证 ，
加密Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。SSL/TLS协议作用：认证用户和服务，加密数据，维护数据的完整性的应用层协议加密和解密需要两个不同的密钥，故被称为非对称加密；加密和解密都使用同一个密钥的对称加密。

SSL加密优点

优点在于加密、解密效率通常比较高HTTPS 是基于非对称加密的， 公钥是公开的
（1）客户端向服务器端发起SSL连接请求；
（2） 服务器把公钥发送给客户端，并且服务器端保存着唯一的私钥
（3）客户端用公钥对双方通信的对称秘钥进行加密，并发送给服务器端
（4）服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密，
（5）进行数据传输，服务器和客户端双方用公有的相同的对称秘钥对数据进行加密解密，可以保证在数据收发过程中的安全，即是第三方获得数据包，也无法对其进行加密，解密和篡改。

因为数字签名、摘要是证书防伪非常关键的武器。 “摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串。然后，在通过CA的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

如何保证公钥不被篡改？

将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
公钥加密计算量太大，如何减少耗用的时间？
每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成"对话密钥"。
（3） 双方采用"对话密钥"进行加密通信。上面过程的前两步，又称为"握手阶段"（handshake）。

《计算机网络》书本：
SSL工作过程，A：客户端，B：服务器端
1.协商加密算法：A向B发送SSL版本号和可选加密算法，B选择自己支持的算法并告知A
2.服务器鉴别：B向A发送包含公钥的数字证书，A使用CA公开发布的公钥对证书进行验证
3.会话密钥计算：A产生一个随机秘密数，用B的公钥进行加密后发送给B，B根据协商的算法产生共享的对称会话密钥并发送给A.
4.安全数据传输：双方用会话密钥加密和解密它们之间传送的数据并验证其完整性

TCP：对应的应用层协议
FTP：定义了文件传输协议，使用21端口.
Telnet：它是一种用于远程登陆的端口,23端口
SMTP：定义了简单邮件传送协议，服务器开放的是25号端口。
POP3：它是和SMTP对应，POP3用于接收邮件。
HTTP：超文本传输协议
UDP对应的应用层协议
DNS：用于域名解析服务，用的是53号端口
SNMP：简单网络管理协议，使用161号端口
TFTP(Trival File Transfer Protocal)：简单文件传输协议，69

SSL证书如何实现http加密变为https的

1、客户端向服务器发起SSL连接请求，并请求服务器发送其公钥；
2、服务器将自己的公钥以数字证书的形式发送给客户端；
3、客户端使用浏览器内置的一组可信的证书颁发机构（CA）公钥验证服务器证书的真实性，并提取服务器公钥；
4、客户端使用服务器公钥对会话密钥进行加密，并发送给服务器；
5、服务器使用自己的私钥对接收到的加密数据进行解密，得到会话密钥；
6、之后双方都使用该会话密钥对通信数据进行加密和解密，从而保证了通信的安全性。

Cookies和session区别

Cookie和Session都是客户端与服务器之间保持状态的解决方案
1，存储的位置不同，cookie：存放在客户端，session：存放在服务端。Session存储的数据比较安全
2，存储的数据类型不同
两者都是key-value的结构，但针对value的类型是有差异的
cookie：value只能是字符串类型，session：value是Object类型
3，存储的数据大小限制不同
cookie：大小受浏览器的限制，很多是是4K的大小， session：理论上受当前内存的限制，
4，生命周期的控制
	cookie的生命周期当浏览器关闭的时候，就消亡了
	(1)cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束，
	(2)session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁

session 的工作原理

session 的工作原理是客户端登录完成之后，服务器会创建对应的 session，session 创建完之后，会把 session 的 id 发送给客户端，客户端再存储到浏览器中。
这样客户端每次访问服务器时，都会带着 sessionid，服务器拿到 sessionid 之后，在内存找到与之对应的 session 这样就可以正常工作了。

一次完整的HTTP请求过程

域名解析
发起TCP的3次握手
建立TCP连接后发起http请求
服务器响应http请求，浏览器得到html代码
浏览器解析html代码，并请求html代码中的资源（如js、css、图片等)
浏览器对页面进行渲染呈现给用户。

GET 和 POST 的区别

1.get是获取数据，post是修改数据
2.get把请求的数据放在url上， 以?分割URL和传输数据，参数之间以&相连，所以get不太安全。而post把数据放在HTTP的包体内（requrest body）
3.get提交的数据最大是2k（ 限制实际上取决于浏览器）， post理论上没有限制。
4.GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200(返回数据); POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)。
5.GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
6.GET是幂等的，而POST不是幂等的

什么是三次握手四次挥手?tcp为什么要三次握手?

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误

三次握手：

• 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
• 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
• 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
• 完成三次握手，客户端与服务器开始传送数据

1.客户端先发送FIN，进入FIN_WAIT1状态，用来关闭Client到Server的数据传送
2.服务端收到FIN，发送ACK，进入CLOSE_WAIT状态，客户端收到这个ACK，进入FIN_WAIT2状态
3.服务端发送FIN，进入LAST_ACK状态，用来关闭Server到Client的数据传送
4.客户端收到FIN，发送ACK，进入TIME_WAIT状态，服务端收到ACK，进入CLOSE状态（等待2MSL时间，约4分钟。主要是防止最后一个ACK丢失。）

四次挥手：

1. 第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可
   以接受数据。
2. 第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
3. 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
4. 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

TCP如何保证可靠传输？

1. 三次握手。
2. 将数据截断为合理的长度。应用数据被分割成 TCP 认为最适合发送的数据块（按字节编号，合理分片）
3. 超时重发。当 TCP 发出一个段后，它启动一个定时器，如果不能及时收到一个确认就重发
4. 确认应答：对于收到的请求，给出确认响应
5. 校验和：校验出包有错，丢弃报文段，不给出响应
6. 序列号：对失序数据进行重新排序，然后才交给应用层
7. 丢弃重复数据：对于重复数据 ， 能够丢弃重复数据
8. 流量控制。TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
9. 拥塞控制。当网络拥塞时，减少数据的发送

TCP与UDP区别

1.TCP面向连接（如打电话要先拨号建立连接）提供可靠的服务;UDP是无连接的，即发送数据之前不需要建立连接，;UDP尽最大努力交付，即不保证可靠交付。（由于UDP无需建立连接，因此UDP不会引入建立连接的时延，TCP需要在端系统中维护连接状态，比如接受和发送缓存，拥塞控制，序号与确认号的参数等，故TCP会比UDP慢）
2.UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
3. 每一条TCP连接只能是一对一的;UDP支持一对一，一对多，多对一和多对多的交互通信
4 UDP分组首部开销小，TCP首部开销20字节;UDP的首部开销小，只有8个字节。
5. TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的（一次交付一个完整的报文，报文不可分割，报文是UDP数据报处理的最小单位）。
6.UDP适合一次性传输较小数据的网络应用，如DNS，SNMP等

OSI 的七层模型都有哪些？

• OSI 模型把网络通信的工作分为 7 层，从下到上分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。
• OSI 只是存在于概念和理论上的一种模型，它的缺点是分层太多，增加了网络工作的复杂性，所以没有大规模应用。后来人们对 OSI
  进行了简化，合并了一些层，最终只保留了 4 层，从下到上分别是接口层、网络层、传输层和应用层，这就是大名鼎鼎的 TCP/IP 模型。

物理层：利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。
数据链路层：接收来自物理层的位流形式的数据，并封装成帧，传送到上一层
网络层：将网络地址翻译成对应的物理地址，并通过路由选择算法为分组通过通信子网选择最适当的路径。
传输层：在源端与目的端之间提供可靠的透明数据传输
会话层：负责在网络中的两节点之间建立、维持和终止通信
表示层：处理用户信息的表示问题，数据的编码，压缩和解压缩，数据的加密和解密
应用层：为用户的应用进程提供网络通信服务

常见的状态码有哪些？

1开头的状态码(信息类)

100，接受的请求正在处理，信息类状态码

2开头的状态码(成功类)

2xx(成功)表示成功处理了请求的状态码
200(成功)服务器已成功处理了请求

3开头的状态码(重定向)

3xx(重定向)表示要完成请求，需要进一步操作。通常这些状态代码用来重定向。 301，永久性重定向，表示资源已被分配了新的 URL
302，临时性重定向，表示资源临时被分配了新的 URL
303，表示资源存在另一个URL，用GET方法获取资源
304，(未修改)自从上次请求后，请求网页未修改过。服务器返回此响应时，不会返回网页内容

4开头的状态码(客户端错误)

4xx(请求错误)这些状态码表示请求可能出错，妨碍了服务器的处理
400(错误请求)服务器不理解请求的语法
401表示发送的请求需要有通过HTTP认证的认证信息
403(禁止)服务器拒绝请求 404(未找到)服务器找不到请求网页

5开头的状态码(服务器错误)

5xx(服务器错误)这些状态码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求的错误
500，(服务器内部错误)服务器遇到错误，无法完成请求
503，表示服务器处于停机维护或超负载，无法处理请求

dns是什么？dns的工作原理

将主机域名转换为ip地址，属于应用层协议，使用UDP传输。

过程：

总结： 浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。
一、主机向本地域名服务器的查询一般都是采用递归查询。
二、本地域名服务器向根域名服务器的查询的迭代查询。
	1)当用户输入域名时，浏览器先检查自己的缓存中是否 这个域名映射的ip地址，有解析结束。
	2）若没命中，则检查操作系统缓存（如Windows的hosts）中有没有解析过的结果，有解析结束。
	3）若无命中，则请求本地域名服务器解析（ LDNS）。
	4）若LDNS没有命中就直接跳到根域名服务器请求解析。根域名服务器返回给LDNS一个 主域名服务器地址。
	5） 此时LDNS再发送请求给上一步返回的gTLD（ 通用顶级域）， 接受请求的gTLD查找并返回这个域名对应的Name Server的地址
	6） Name Server根据映射关系表找到目标ip，返回给LDNS
	7） LDNS缓存这个域名和对应的ip， 把解析的结果返回给用户，用户根据TTL值缓存到本地系统缓存中，域名解析过程至此结束

多线程、多进程、协程、相关

CPU、核心、进程、线程、协程、串行、并发、并行

CPU、核心、进程、线程、协程、串行、并发、并行

线程创建与管理

线程创建与管理

多线程通信

线程间通信方式有两种：共享内存和消息传递。 不同进程间线程通信等同于进程间通信，同一进程间可用共享内存实现。
在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信，典型的共享内存通信方式就是通过共享对象进行通信。
在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信，在java中典型的消息传递方式就是wait()和notify()。

进程间的通信方式

相关详解请查看此处
管道：

管道是最简单，效率最差的一种通信方式。
管道本质上就是内核中的一个缓存，当进程创建一个管道后，Linux会返回两个文件描述符，一个是写入端的描述符，一个是输出端的描述符，可以通过这两个描述符往管道写入或者读取数据。
如果想要实现两个进程通过管道来通信，则需要让创建管道的进程fork子进程，这样子进程们就拥有了父进程的文件描述符，这样子进程之间也就有了对同一管道的操作。

缺点：
半双工通信，一条管道只能一个进程写，一个进程读。
一个进程写完后，另一个进程才能读，反之同理。

消息队列：

管道的通信方式效率是低下的，不适合进程间频繁的交换数据。这个问题，消息队列的通信方式就可以解决。A进程往消息队列写入数据后就可以正常返回，B进程需要时再去读取就可以了，效率比较高。
而且，数据会被分为一个一个的数据单元，称为消息体，消息发送方和接收方约定好消息体的数据类型，不像管道是无格式的字节流类型，这样的好处是可以边发送边接收，而不需要等待完整的数据。

缺点:
1.每个消息体有一个最大长度的限制，并且队列所包含消息体的总长度也是有上限的，这是其中一个不足之处。
2.另一个缺点是消息队列通信过程中存在用户态和内核态之间的数据拷贝问题。进程往消息队列写入数据时，会发送用户态拷贝数据到内核态的过程，同理读取数据时会发生从内核态到用户态拷贝数据的过程。

共享内存：

共享内存解决了消息队列存在的内核态和用户态之间数据拷贝的问题。
现代操作系统对于内存管理采用的是虚拟内存技术，也就是说每个进程都有自己的虚拟内存空间，虚拟内存映射到真实的物理内存。共享内存的机制就是，不同的进程拿出一块虚拟内存空间，映射到相同的物理内存空间。这样一个进程写入的东西，另一个进程马上就能够看到，不需要进行拷贝。

信号量：

信号量是由荷兰学者 Dijkstra 提出的, 它的原理比较简单, 但却能非常好地实现并发控制, 在并发执行的程序中,如果它们都要访问同一个共享资源 (临界资源), 若此时不加以控制则可能会造成数据错误, 信号量可以非常方便地解决这个问题,最简单的信号量可以是一个只能取 0 和 1 的变量, 信号量的操作有两个, 分别称之为 P 操作和 V 操作, 我们将信号量记为 s, 则P(s) 调用的结果是若 s 的值大于 0 则减去 1, 否则挂起进程, V(s) 调用的结果是如果此时有因为执行 P(s)操作而被挂起的进程, 则恢复该进程的运行, 否则将 s 的值加一, 每次程序要进入临界区时, 都首先调用 P(s), 如果调用成功,说明当前没有其它进程或线程在访问临界区, 调用 P(s) 的同时也会将 s 的值减成 0, 从而阻止其它想要访问临界区的程序进入,当操作完毕后, 调用 V(s) 释放对临界区的占用, 在 UNIX 中, 信号量操作有如下的函数:

Socket：

前面提到的管道、消息队列、共享内存、信号量和信号都是在同一台主机上进行进程间通信，那要想跨网络与不同主机上的进程之间通信，就需要Socket通信了。
实际上，Socket通信不仅可以跨网络与不同主机的进程间通信，还可以在同主机上进程间通信。

MySQL相关

MySQL 支持哪些存储引擎?

MySQL 5.7 支持的存储引擎有 InnoDB、MyISAM、Memory、Merge、Archive、CSV、BLACKHOLE、等。

可以使用SHOW ENGINES;语句查看系统所支持的引擎类型，结果如图所示。
Support 列的值表示某种引擎是否能使用，YES表示可以使用，NO表示不能使用，DEFAULT表示该引擎为当前默认的存储引擎。

常用的三种常用存储引擎：MyISAM、InnoDB和MEMORY

MyISAM

MyISAM基于ISAM存储引擎，并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM拥有较高的插入、查询速度，但NO事物。使用这个存储引擎，每个MyISAM在磁盘上存储成三个文件：

（1）frm文件：存储表的定义数据
（2）MYD文件：存放表具体记录的数据
（3）MYI文件：存储索引

frm和MYI可以存放在不同的目录下。MYI文件用来存储索引，但仅保存记录所在页的指针，索引的结构是B+树结构。下图是MYI文件保存的机制：

上图，该存储引擎通过MYI的B+树结构来查找记录页，再根据记录页查找记录。并且支持全文索引、B树索引和数据压缩。
支持数据的类型也有三种：
（1）静态固定长度表

这种方式的优点在于存储速度非常快，容易发生缓存，而且表发生损坏后也容易修复。缺点是占空间。这也是默认的存储格式。

（2）动态可变长表

优点是节省空间，但是一旦出错恢复起来比较麻烦。

（3）压缩表

上面说到支持数据压缩，说明肯定也支持这个格式。在数据文件发生错误时候，可以使用check table工具来检查，而且还可以使用repair table工具来恢复。

有一个重要的特点那就是NO事务，但是这也意味着他的存储速度更快，如果你的读写操作允许有错误数据的话，只是追求速度，可以选择这个存储引擎。

MyISAM主要特性有：
1、大文件（达到63位文件长度）在支持大文件的文件系统和操作系统上被支持；
2、当把删除和更新及插入操作混合使用的时候，动态尺寸的行产生更少碎片。这要通过合并相邻被删除的块，以及若下一个块被删除，就扩展到下一块自动完成；
3、每个MyISAM表最大索引数是64，这可以通过重新编译来改变。每个索引最大的列数是16；
4、最大的键长度是1000字节，这也可以通过编译来改变，对于键长度超过250字节的情况，一个超过1024字节的键将被用上
5、BLOB和TEXT列可以被索引；
6、NULL被允许在索引的列中，这个值占每个键的0~1个字节；
7、所有数字键值以高字节优先被存储以允许一个更高的索引压缩；
8、每个MyISAM类型的表都有一个AUTO_INCREMENT的内部列，当INSERT和UPDATE操作的时候该列被更新，同时AUTO_INCREMENT列将被刷新。所以说，MyISAM类型表的AUTO_INCREMENT列更新比InnoDB类型的AUTO_INCREMENT更快；
9、可以把数据文件和索引文件放在不同目录；
10、每个字符列可以有不同的字符集；
11、有VARCHAR的表可以固定或动态记录长度；
12、VARCHAR和CHAR列可以多达64KB。

使用MyISAM引擎创建数据库，将产生3个文件。文件的名字以表名字开始，扩展名之处文件类型：frm文件存储表定义、数据文件的扩展名为.MYD（MYData）、索引文件的扩展名时.MYI（MYIndex）。

InnoDB存储引擎

InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID），支持行锁定和外键，InnoDB是默认的MySQL引擎。

InnoDB主要特性有：

1. InnoDB给MySQL提供了具有提交、回滚和崩溃恢复能力的事物安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句中提供一个类似Oracle的非锁定读。这些功能增加了多用户部署和性能。在SQL查询中，可以自由地将InnoDB类型的表和其他MySQL的表类型混合起来，甚至在同一个查询中也可以混合
2. InnoDB是为处理巨大数据量的最大性能设计。它的CPU效率可能是任何其他基于磁盘的关系型数据库引擎锁不能匹敌的。
3. InnoDB存储引擎完全与MySQL服务器整合，InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB将它的表和索引在一个逻辑表空间中，表空间可以包含数个文件（或原始磁盘文件）。这与MyISAM表不同，比如在MyISAM表中每个表被存放在分离的文件中。InnoDB表可以是任何尺寸，即使在文件尺寸被限制为2GB的操作系统上
4. InnoDB支持外键完整性约束，存储表中的数据时，每张表的存储都按主键顺序存放，如果没有显示在表定义时指定主键，InnoDB会为每一行生成一个6字节的ROWID，并以此作为主键。
5. InnoDB被用在众多需要高性能的大型数据库站点上，InnoDB不创建目录，使用InnoDB时，MySQL将在MySQL数据目录下创建一个名为ibdata1的10MB大小的自动扩展数据文件，以及两个名为ib_logfile0和ib_logfile1的5MB大小的日志文件
6. 可以通过自动增长列，方法是auto_increment。
7. 支持事务。默认的事务隔离级别为可重复度，通过MVCC（并发版本控制）来实现的。
8. 使用的锁粒度为行级锁，可以支持更高的并发；
9. 支持外键约束；外键约束其实降低了表的查询速度，但是增加了表之间的耦合度。
10. 配合一些热备工具可以支持在线热备份；
11. 在InnoDB中存在着缓冲管理，通过缓冲池，将索引和数据全部缓存起来，加快查询的速度；
12. 对于InnoDB类型的表，其数据的物理组织形式是聚簇表。所有的数据按照主键来组织。数据和索引放在一块，都位于B+数的叶子节点上。

InnoDB的存储表和索引也有下面两种形式：

（1）使用共享表空间存储：所有的表和索引存放在同一个表空间中。

（2）使用多表空间存储：表结构放在frm文件，数据和索引放在IBD文件中。分区表的话，每个分区对应单独的IBD文件，分区表的定义可以查看我的其他文章。使用分区表的好处在于提升查询效率。

对于InnoDB来说，最大的特点在于支持事务，但这以损失效率来换取和保障。

Memory

MEMORY存储引擎将表中的数据存储到内存中，未查询和引用其他表数据提供快速访问。每一个表实际上和一个磁盘文件关联，文件是frm。

1. 支持的数据类型有限制，比如：NOTEXT和BLOB类型，对于字符串类型的数据，只支持固定长度的行，VARCHAR会被自动存储为CHAR类型
2. 支持的锁粒度为表级锁。所以，在访问量比较大时，表级锁会成为MEMORY存储引擎的瓶颈；
3. 由于数据是存放在内存中，一旦服务器出现故障，数据都会丢失；
4. 查询的时候，如果有用到临时表，而且临时表中有BLOB，TEXT类型的字段，那么这个临时表就会转化为MyISAM类型的表，性能会急剧降低；
5. 默认使用hash索引；
6. 如果一个内部表很大，会转化为磁盘表；
7. MEMORY表的每个表可以有多达32个索引，每个索引16列，以及500字节的最大键长度；
8. MEMORY存储引擎执行HASH和BTREE缩影；
9. 可以在一个MEMORY表中有非唯一键值；
10. MEMORY表使用一个固定的记录长度格式；
11. MEMORYNOBLOB或TEXT列；
12. MEMORY支持AUTO_INCREMENT列和对可包含NULL值的列的索引；
13. MEMORY表在所由客户端之间共享（就像其他任何非TEMPORARY表）；
14. MEMORY表内存被存储在内存中，内存是MEMORY表和服务器在查询处理时的空闲中，创建的内部表共享；
15. 当不再需要MEMORY表的内容时，要释放被MEMORY表使用的内存，应该执行DELETE FROM或TRUNCATE TABLE，或者删除整个表（使用DROP TABLE）。

存储引擎的4种推荐选择：

1. 如要提供提交、回滚、崩溃恢复能力的事物安全（ACID兼容）能力，并要求实现并发控制，推荐InnoDB；

2. 如数据表主要用来插入和查询记录，则MyISAM引擎能提供较高的处理效率；

3. 如只是临时存放数据，数据量不大，并且不需要较高的数据安全性，可以选择将数据保存在内存中的Memory引擎，MySQL中使用该引擎作为临时表，存放查询的中间结果；

4. 如只有INSERT和SELECT操作，可选择Archive，Archive支持高并发的插入操作，但本身不是事务安全的。Archive非常适合存储归档数据，如记录日志信息可以使用Archive。

聚簇索引与非聚簇索引

• 聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据
• 非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因

澄清一个概念：innodb中，在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引，辅助索引叶子节点存储的不再是行的物理位置，而是主键值。

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id =14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。

MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。

聚簇索引的优势

1. 由于行数据和叶子节点存储在一起，同一页中会有多条行数据，访问同一数据页不同行记录时，已经把页加载到了Buffer中，再次访问的时候，会在内存中完成访问，不必访问磁盘。这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。
2. 辅助索引使用主键作为"指针"而不是使用地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"。也就是说行的位置（实现中通过16K的Page来定位）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。
3. 聚簇索引适合用在排序的场合，非聚簇索引不适合
4. 取出一定范围数据的时候，使用用聚簇索引
5. 二级索引需要两次索引查找，而不是一次才能取到数据，因为存储引擎第一次需要通过二级索引找到索引的叶子节点，从而找到数据的主键，然后在聚簇索引中用主键再次查找索引，再找到数据
6. 可以把相关数据保存在一起。例如实现电子邮箱时，可以根据用户 ID来聚集数据，这样只需要从磁盘读取少数的数据页就能获取某个用户的全部邮件。如果没有使用聚簇索引，则每封邮件都可能导致一次磁盘 I/O。

聚簇索引的劣势:

1.维护索引很昂贵，特别是插入新行或者主键被更新导至要分页(page split)的时候。建议在大量插入新行后，选在负载较低的时间段，通过OPTIMIZE TABLE优化表，因为必须被移动的行数据可能造成碎片。使用独享表空间可以弱化碎片
2.表因为使用UUId（随机ID）作为主键，使数据存储稀疏，这就会出现聚簇索引有可能有比全表扫面更慢

innodb为什么要用自增id作为主键

InnoDB作为MySQL中的一种存储引擎，使用自增id作为主键有以下几个原因：

1.自增id是一个单调递增的数字，可以保证插入记录时的顺序，使得插入数据时可以减少页面分裂的次数，提高插入性能。
2.自增id是一个整数类型，占用的空间较小，因此在索引中可以更加高效地使用。
3.自增id可以保证唯一性，不会出现重复的情况，避免了数据异常的情况。
需要注意的是，自增id作为主键只是一种约定俗成的做法，并不是绝对的。在某些情况下，可能存在更合适的主键选择，需要根据具体的业务需求进行选择。

数据库三范式

所有字段值都是不可分解的原子值。

在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
数据表中的每一列数据都和主键直接相关，而不能间接相关。

第一范式(确保每列保持原子性)

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

第二范式(确保表中的每列都和主键相关)

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说 在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

第三范式(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

优点：

可以尽量得减少数据冗余 缺点:对于查询需要多个表进行关联，更难进行索引优化 反范式化: 优点:可以减少表得关联 缺点:数据冗余以及数据异常

索引失效的几种场景

1. like 以%开头，索引无效；当like前缀没有%，后缀有%时，索引有效。
2. or语句前后没有同时使用索引。当or左右查询字段只有一个是索引，该索引失效，只有当or左右查询字段均为索引时，才会生效
3. 组合索引，不是使用第一列索引，索引失效。
4. 数据类型出现隐式转化。如varchar不加单引号的话可能会自动转换为int型(用select查询时)，使索引无效，产生全表扫描
5. 在索引列上使用 IS NULL 或 IS NOT NULL操作(在 where 子句中对字段进行 null 值判断)
6. 在索引字段上使用not，<>，!=。不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。 优化方法： key<>0 改为 key>0 or key<0。
7. 对索引字段进行计算操作、字段上使用函数。
8. 当全表扫描速度比索引速度快时，mysql会使用全表扫描，此时索引失效。

事务是什么

事务（transaction）是作为一个单元的一组有序的数据库操作。如果组中的所有操作都成功，则认为事务成功，即使只有一个操作失败，事务也不成功。如果所有操作完成，事务则提交，其修改将作用于所有其他数据库进程。如果一个操作失败，则事务将回滚，该事务所有操作的影响都将取消。

为什么使用事务:

可以保证数据的一致性和完整性(避免异常和错误等导致的数据信息异常) 

事务具有的四个特征？

事务的特性ACID:
原子性（Atomicity）：事务包含的操作全部成功或者全部失败

一致性（Consistency）：数据库从一个一致性状态变到另一个一致性状态
    (一系列操作后,所有的操作和更新全部提交成功,数据库只包含全部成功后的数据就是数据的一致性)
    (由于系统异常或数据库系统出现故障导致只有部分数据更新成功,但是这不是我们需要的最终数据,这就是数据的不一致)
隔离性（Isolation）：事务互相隔离互不干扰
     (事务内部操作的数据对其它事务是隔离的,在一个事务执行完之前不会被其他事务影响和操作)
持久性（Durability）：事务提交后数据应该被永久的保存下来，出现宕机等故障后可以恢复数据

MySQL 默认隔离级别？

四种隔离级别详解

数据库事务的隔离级别有4种，由低到高分别为Readuncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻读

MySQL性能优化的9种方法

1、选择最合适的字段属性

Mysql是一种关系型数据库，可以很好地支持大数据量的存储，但是一般来说，数据库中的表越小，在它上面执行的查询也就越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度舍得尽可能小。

2、尽量把字段设置为NOT NULL

在可能的情况下，尽量把字段设置为NOT NULL,这样在将来执行查询的时候，数据库不用去比较NULL值。

对于某些文本字段来说，例如“省份”或者“性别”，我们可以将他们定义为ENUM(枚举)类型。因为在MySQL中，ENUM类型被当做数值型数据来处理，而数值型数据被处理起来的速度要比文本类型要快得多。这样我们又可以提高数据库的性能。

3、使用连接（JOIN）来代替子查询（Sub-Queries）

MySQL从4.1开始支持SQL的子查询。这个技术可以使用select语句来创建一个单例的查询结果，然后把这个结果作为过滤条件用在另一个查询中。

4、使用联合（UNION）来代替手动创建的临时表

MySQL从4.0版本开始支持union查询，他可以把需要使用临时表的两条或更多的select查询合在一个查询中。在客户端查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用union来创建查询的时候，我们只需要用union作为关键字把多个select语句连接起来就可以了，要注意的是所有select语句中的字段数目要相同。

5、事务

尽管我们可以使用子查询(Sub-Queries)、连接(JOIN)和联合(UNION)来创建各种各样的查询，但不是所有的数据库操作，都可以只用一条或少数几条就可以完成的。更多的时候是需要用一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。

6、使用外键

锁定表的方法可以维护数据的完整性，但是他却不能保证数据的关联性。这个时候我们可以使用外键。例如：外键可以保证每一条销售记录都指向某一个存在的客户。

7、锁定表

尽管事务是维护数据库完整性的一个非常好的方法，但却因为他的独占性，有时会影响数据库的性能，尤其是很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其他的用户请求只能暂时等待直到该事务结束。

8、使用索引

索引是提高数据库性能的常用方法，他可以令数据库服务器比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(),MIN()和ORDERBY这些命令的时候，性能提高更为明显。

那该对那些字段进行索引呢？

一般来说，索引应该建立在那些将用于join，where判断和orderby排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引，对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况。

9、优化查询语句

1. 不使用子查询
2. 避免函数索引
3. 用IN来替换OR
4. LIKE双百分号无法使用到索引
5. 读取适当的记录LIMIT M,N
6. 避免数据类型不一致
7. 分组统计可以禁止排序
8. 避免随机取记录
9. 禁止不必要的ORDER BY排序
   10.批量INSERT插入

MySQL为什么使用B+树，而不是使用其他？B+树的特点

可以直接使用次链接
MySQL为什么使用B+树，而不是使用其他？B+树的特点

redis相关

Redis 持久化机制

Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。
实现：单独创建fork()一个子进程，将当前父进程的数据库数据复制到子进程的内存中，然后由子进程写入到临时文件中，持久化的过程结束了，再用这个临时文件替换上次的快照文件，然后子进程退出，内存释放。

RDB是Redis默认的持久化方式。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。（ 快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。）
AOF：Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问题

缓存雪崩

我们可以简单的理解为：由于原有缓存失效，新缓存未到期间
(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

解决办法：

大多数系统设计者考虑用加锁（ 最多的解决方案）或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开。

缓存穿透

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

解决办法;

最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。
5TB的硬盘上放满了数据，请写一个算法将这些数据进行排重。如果这些数据是一些32bit大小的数据该如何解决？如果是64bit的呢？
对于空间的利用到达了一种极致，那就是Bitmap和布隆过滤器(Bloom Filter)。
Bitmap： 典型的就是哈希表
缺点是，Bitmap对于每个元素只能记录1bit信息，如果还想完成额外的功能，恐怕只能靠牺牲更多的空间、时间来完成了。

布隆过滤器（推荐）
就是引入了k(k>1)k(k>1)个相互独立的哈希函数，保证在给定的空间、误判率下，完成元素判重的过程。
它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
Bloom-Filter算法的核心思想就是利用多个不同的Hash函数来解决“冲突”。
Hash存在一个冲突（碰撞）的问题，用同一个Hash得到的两个URL的值有可能相同。为了减少冲突，我们可以多引入几个Hash，如果通过其中的一个Hash值我们得出某元素不在集合中，那么该元素肯定不在集合中。只有在所有的Hash函数告诉我们该元素在集合中时，才能确定该元素存在于集合中。这便是Bloom-Filter的基本思想。
Bloom-Filter一般用于在大数据量的集合中判定某元素是否存在。
受提醒补充：缓存穿透与缓存击穿的区别
缓存击穿：是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据。
解决方案;在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。
增：给一个我公司处理的案例：背景双机拿token，token在存一份到redis，保证系统在token过期时都只有一个线程去获取token;线上环境有两台机器，故使用分布式锁实现。

缓存预热

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决思路：

1、直接写个缓存刷新页面，上线时手工操作下；
2、数据量不大，可以在项目启动的时候自动进行加载；
3、定时刷新缓存；

缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：
（1）定时去清理过期的缓存；
（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
以参考日志级别设置预案：
（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

Memcache与Redis的区别都有哪些？

1)、存储方式 Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
Redis有部份存在硬盘上，redis可以持久化其数据
2)、数据支持类型memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型，提供list，set，zset，hash等数据结构的存储
3)、使用底层模型不同 它们之间底层实现方式以及与客户端之间通信的应用协议不一样。 Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
4). value 值大小不同：Redis 最大可以达到 512M；memcache 只有 1mb。
5）redis的速度比memcached快很多 6）Redis支持数据的备份，即master-slave模式的数据备份。

单线程的redis为什么这么快

(一)纯内存操作
(二)单线程操作，避免了频繁的上下文切换
(三)采用了非阻塞I/O多路复用机制

redis的数据类型，以及每种数据类型的使用场景

一共五种

(一)String

这个其实没啥好说的，最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。

(二)hash

这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

(三)list

使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。本人还用一个场景，很合适—取行情信息。就也是个生产者和消费者的场景。LIST可以很好的完成排队，先进先出的原则。

(四)set

因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。
另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

(五)sorted set

sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。68661

redis的过期策略以及内存淘汰机制

redis采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.

定期删除+惰性删除是如何工作的呢?

定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。
在redis.conf中有一行配置

maxmemory-policy volatile-lru

该配置就是配内存淘汰策略的(什么，你没配过？好好反省一下自己)
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错
ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

Redis 为什么是单线程的

官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）Redis利用队列技术将并发访问变为串行访问
1）绝大部分请求是纯粹的内存操作（非常快速）
2）采用单线程,避免了不必要的上下文切换和竞争条件
3）非阻塞IO优点：
1.速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
2. 支持丰富数据类型，支持string，list，set，sorted set，hash
3.支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
4. 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除如何解决redis的并发竞争key问题

同时有多个子系统去set一个key。这个时候要注意什么呢？ 不推荐使用redis的事务机制。因为我们的生产环境，基本都是redis集群环境，做了数据分片操作。你一个事务中有涉及到多个key操作的时候，这多个key不一定都存储在同一个redis-server上。因此，redis的事务机制，十分鸡肋。
(1)如果对这个key操作，不要求顺序： 准备一个分布式锁，大家去抢锁，抢到锁就做set操作即可
(2)如果对这个key操作，要求顺序： 分布式锁+时间戳。 假设这会系统B先抢到锁，将key1设置为{valueB 3:05}。接下来系统A抢到锁，发现自己的valueA的时间戳早于缓存中的时间戳，那就不做set操作了。以此类推。
(3) 利用队列，将set方法变成串行访问也可以redis遇到高并发，如果保证读写key的一致性
对redis的操作都是具有原子性的,是线程安全的操作,你不用考虑并发问题,redis内部已经帮你处理好并发的问题了

有没有尝试进行多机redis 的部署？如何保证数据一致的？

主从复制，读写分离

一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

对于大量的请求怎么样处理

redis是一个单线程程序，也就说同一时刻它只能处理一个客户端请求；
redis是通过IO多路复用（select，epoll, kqueue，依据不同的平台，采取不同的实现）来处理多个客户端请求的

Redis 常见性能问题和解决方案？

(1) Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件
(2) 如果数据比较重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性， Master 和 Slave 最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即： Master <- Slave1 <- Slave2 <-
Slave3…

Redis事务

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的
Redis会将一个事务中的所有命令序列化，然后按顺序执行。
1.redis 不支持回滚“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。
2.如果在一个事务中的命令出现错误，那么所有的命令都不会执行；
3.如果在一个事务中出现运行错误，那么正确的命令会被执行。
注：redis的discard只是结束本次事务,正确命令造成的影响仍然存在.

1）MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
2）EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。
3）通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
4）WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。

Redis实现分布式锁

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁。
将 key 的值设为 value ，当且仅当 key 不存在。 若给定的 key 已经存在，则 SETNX 不做任何动作

解锁：使用 del key 命令就能释放锁
解决死锁：
1）通过Redis中expire()给锁设定最大持有时间，如果超过，则Redis来帮我们释放锁。
2） 使用 setnx key “当前系统时间+锁持有的时间”和getset key “当前系统时间+锁持有的时间”组合的命令就可以实现