美团到店面经

redis中大key引起的问题

1、阻塞请求
Big Key对应的value较大，我们对其进行读写的时候，需要耗费较长的时间，这样就可能阻塞后续的请求处理。Redis的核心线程是单线程，单线程中请求任务的处理是串行的，前面的任务完不成，后面的任务就处理不了。

2、内存增大
读取Big Key耗费的内存比正常Key会有所增大，如果不断变大，可能会引发OOM（内存溢出），或达到redis的最大内存maxmemory设置值引发写阻塞或重要Key被逐出。

3、阻塞网络
读取单value较大时会占用服务器网卡较多带宽，自身变慢的同时可能会影响该服务器上的其他Redis实例或者应用。

4、影响主从同步、主从切换
删除一个大Key造成主库较长时间的阻塞并引发同步中断或主从切换。

redis如何妥善处理大key问题？

要解决Big Key问题，无非就是减小key对应的value值的大小，也就是对于String数据结构的话，减少存储的字符串的长度；对于List、Hash、Set、ZSet数据结构则是减少集合中元素的个数。

1、对大Key进行拆分
将一个Big Key拆分为多个key-value这样的小Key，并确保每个key的成员数量或者大小在合理范围内，然后再进行存储，通过get不同的key或者使用mget批量获取。

2、对大Key进行清理
对Redis中的大Key进行清理，从Redis中删除此类数据。Redis自4.0起提供了UNLINK命令，该命令能够以非阻塞的方式缓慢逐步的清理传入的Key，通过UNLINK，你可以安全的删除大Key甚至特大Key。

3、监控Redis的内存、网络带宽、超时等指标
通过监控系统并设置合理的Redis内存报警阈值来提醒我们此时可能有大Key正在产生，如：Redis内存使用率超过70%，Redis内存1小时内增长率超过20%等。

4、定期清理失效数据
如果某个Key有业务不断以增量方式写入大量的数据，并且忽略了其时效性，这样会导致大量的失效数据堆积。可以通过定时任务的方式，对失效数据进行清理。

5、压缩value
使用序列化、压缩算法将key的大小控制在合理范围内，但是需要注意序列化、反序列化都会带来一定的消耗。如果压缩后，value还是很大，那么可以进一步对key进行拆分。

zset底层数据结构有了解吗？

zset的两种数据结构
压缩表ziplist

当redis插入第一个元素时，同时满足以下条件，就会以ziplist创建跳表

节点数量<128 （可通过server.zset_max_ziplist_entries设置）

节点的长度<64（可通过server.zset_max_ziplist_value设置）

当选择用ziplist实现zset后，以后插入的节点若不满足以上任一个条件，就会转为skiplist

ziplist 编码的 Zset 使用紧挨在一起的压缩列表节点来保存，第一个节点保存 member，第二个保存 score。ziplist 内的集合元素按 score 从小到大排序，其实质是一个双向链表。虽然元素是按 score 有序排序的，但对 ziplist 的节点指针只能线性地移动，所以在 REDIS_ENCODING_ZIPLIST 编码的 Zset 中，查找某个给定元素的复杂度为 O(N)。

跳表skiplist

跳表的本质是一个多层链表，它能快速地查询、插入、删除【时间复杂度均为O(logn)】，所以它的查询速度媲美平衡二叉树，而且它的数据结构比平衡二叉树简单，结构示意图如下:

查询过程：时间复杂度为O(logn)

前向遍历：
- 从当前层的当前节点开始，沿着水平方向向前遍历，直到找到当前层中下一个节点的值大于或等于要查找的值，或者到达当前层的末尾。
- 如果到达当前层的末尾，并且当前层不是最底层，则下降到下一层，然后从下一层的相应节点继续向前遍历。
垂直下降：
- 当在某一层找到的节点值大于或等于要查找的值时，或者已经到达当前层的末尾，则移动到下一层对应的节点（即通过节点的向下指针）。
- 在新的层上，重复步骤2的前向遍历。
查找结束：
- 当到达最底层，并且找到的节点值等于要查找的值时，查询成功。
- 如果在最底层遍历到的节点值不等于要查找的值，则说明跳表中不存在该值，查询失败。

zset底层为什么使用skipList不使用B+树，请对比分析原因？

redis设计本身使用的是极简思想，跳跃表的操作，比二叉树简单，不需要考虑平衡，实现起来也简单,我觉的这个是重点
redis是纯内存操作，不需要考虑磁盘IO的次数（一个*header可以理解为一个数据页，只不过是在内存里）
MySQL为了持久化，需要考虑磁盘IO，利用数据页，系统缓存，减少磁盘的操作顺序

手撕sql（一个表连接的题目，题目记不太得）

基于sql题目，先问你了解索引吗？索引为什么快？索引的底层数据结构选型问题？

基于sql题目，问你认为应该把索引建立哪一（几）列？为什么这么做？

基于sql题目，问你什么情况下索引会失效，如何避免这种情况？

union和join的区别

JOIN操作符用于根据两个或多个表之间的相关列来合并这些表的数据。UNION操作符用于合并两个或多个SELECT语句的结果集。合并后的结果集会去除重复的行。
UNION默认去除重复行，而UNION ALL保留重复行。JOIN不会去除重复行，它基于关系返回匹配的行。

了解tcp和udp吗？区别是什么？实际应用场景有什么不同？

TCP 和 UDP 区别：

1. 连接

TCP 是面向连接的传输层协议，传输数据前先要建立连接。
UDP 是不需要连接，即刻传输数据。

2.服务对象

TCP 是一对一的两点服务，即一条连接只有两个端点。
UDP 支持一对一、一对多、多对多的交互通信。

3.可靠性

TCP 是面向连接的传输层协议，传输数据前先要建立连接。
UDP 是不需要连接，即刻传输数据。

4.拥塞控制、流量控制、滑动窗口

TCP 有拥塞控制和流量控制机制，保证数据的可靠传输。
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

5. 首部开销

TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20个字节，如果使用了「选项」字段则会变长的。
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

6. 传输方式

TCP 是流式传输，没有边界，但保证顺序和可靠。
UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

7. 分片不同

TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层。

TCP 和 UDP 应用场景：

由于 TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：

FTP 文件传输；
HTTP / HTTPS；

由于 UDP 面向无连接，它可以随时发送数据，再加上 UDP 本身的处理既简单又高效，因此经常用于：

包总量较少的通信，如 DNS 、SNMP 等；
视频、音频等多媒体通信；
广播通信；

基于TCP和UDP的协议各自有哪些？

基于TCP的协议：

HTTP/HTTPS：超文本传输协议及其安全版本，用于Web浏览器和服务器之间的通信。
FTP：文件传输协议，用于文件的上传和下载。
SMTP：简单邮件传输协议，用于电子邮件的发送。
IMAP/POP3：互联网邮件访问协议和邮局协议版本3，用于电子邮件的接收。
SSH：安全外壳协议，用于安全地访问远程计算机。
Telnet：用于远程登录到网络设备。
SSL/TLS：安全套接字层/传输层安全性，用于在互联网上提供加密通信。
DNS（域名系统）：虽然DNS查询通常使用UDP，但DNS的区域传输使用TCP

基于UDP的协议：

DNS：域名系统，用于将域名解析为IP地址。
DHCP：动态主机配置协议，用于自动分配IP地址给网络中的设备。
TFTP：简单文件传输协议，用于文件传输，尤其是在没有完整TCP/IP堆栈的情况下
IGMP：互联网组管理协议，用于IP组播。

TCP如何保证传输的可靠性？

1. 三次握手（Three-Way Handshake）

在建立连接时，TCP使用三次握手来确保两个通信端点都准备好进行数据交换，并且同步序列号，这是可靠传输的基础。

2. 序列号和确认应答（Sequence Numbers and Acknowledgments）

序列号：TCP将每个字节的数据都分配一个序列号，确保数据按照正确的顺序传输。
确认应答：接收方收到数据后，会发送一个确认应答（ACK），其中包含下一个期望收到的序列号。如果发送方没有收到确认应答，它会重新发送数据。确保数据丢失

3. 重传机制（Retransmission）

如果发送方在预定的超时时间内没有收到确认应答，它会假设数据包丢失或出错，并重新发送数据。

4. 流量控制（Flow Control）

TCP使用滑动窗口机制进行流量控制，以避免发送方发送数据过快，导致接收方来不及处理。接收方通过调整窗口大小来告知发送方它能够接收的数据量。

5. 拥塞控制（Congestion Control）

TCP通过以下几种算法来避免网络拥塞：

慢启动（Slow Start）：连接开始时，逐渐增加发送数据的速率。
拥塞避免（Congestion Avoidance）：当检测到网络拥塞时，减少数据发送速率。
快速重传（Fast Retransmit）：在收到三个重复的ACK时，不必等待超时，立即重传丢失的数据包。
快速恢复（Fast Recovery）：在快速重传后，调整窗口大小，而不是从慢启动重新开始。

讲到HTTP了，那你说一下HTTP和HTTPS的区别？

HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

你刚讲到HTTP基于SSL/TLS实现的安全加密？具体如何实现的？讲一下具体流程（对称加密消息、非对称加密公钥）？

HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。

所以安全上存在以下三个风险：

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。

TLS 协议是如何解决 HTTP 的风险的呢？

信息加密： HTTP 交互信息是被加密的，第三方就无法被窃取；
校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；
身份证书：证明淘宝是真的淘宝网；

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件其实就是服务端的公钥，会在 TLS 握手阶段传递给客户端，而服务端的私钥则一直留在服务端，一定要确保私钥不能被窃取。

TLS四次握手：

第一次握手：客户端首先会发一个「Client Hello」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数，这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

第二次握手：

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数。接着，返回Server Hello消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。然后，服务端为了证明自己的身份，会发送Server Certificate给客户端，这个消息里含有数字证书。随后，服务端发了Server Hello Done消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

第三次握手

客户端验证完证书后，认为可信则继续往下走。

接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过Client Key Exchange消息传给服务端。

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此，客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。

于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

生成完「会话密钥」后，然后客户端发一个Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。

然后，客户端再发一个Encrypted Handshake Message（Finishd）消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

第四次握手

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。最后，就用「会话密钥」加解密 HTTP 请求和响应了。

reentrantLock具体怎么去唤醒新线程的，我希望听api应用层面的

1.通过条件变量Condition对象

lock.lock();
 
condition.signal(); // 唤醒等待的线程
condition.await();// 让线程进入等待状态
 
lock.unlock();

和synchronized一样，condition也是只能在lock()方法和unlock()方法的中间使用

2.tryLock()尝试获取锁

tryLock()：尝试获取锁，如果锁不可用，则立即返回false。如果锁可用，则获取锁并返回true。
tryLock(long time, TimeUnit unit)：尝试在指定时间内获取锁。如果锁在指定时间内不可用，则返回false；如果锁可用，则获取锁并返回true。

你提到AQS，那你知道AQS的设计模式是什么吗？

模板方法模式：AQS定义了同步器的骨架，包括获取和释放锁的方法。这些方法是模板方法，由子类来实现具体的逻辑。例如，acquire和release方法是模板方法，子类需要实现tryAcquire和tryRelease方法。
装饰器模式：AQS提供了一种扩展同步器功能的方式，允许通过添加额外的组件来增强其行为。例如，ReentrantLock通过继承AQS并添加自己的逻辑来实现可重入的锁。
观察者模式：AQS通过队列来管理等待获取同步状态的线程。当同步状态发生变化时，它会通知等待的线程。这种模式使得AQS能够支持多种同步状态，而不仅仅是简单的独占锁。
代理模式：AQS通过代理类来提供同步器的操作接口，这些代理类封装了具体的同步逻辑。例如，ReentrantLock通过NonfairSync和FairSync代理类来实现非公平和公平锁。

装饰器模式和模板方法设计模式的区别是什么？

装饰器模式和模板方法设计模式都是用于扩展和增强对象的行为，但它们的应用场景和实现方式有所不同。

装饰器模式：

目的：在不修改对象结构的情况下，动态地给对象添加额外的职责。
实现方式：通过创建一个装饰类，该类持有被装饰对象的引用，并在其方法中调用被装饰对象的方法。
应用场景：当需要在不改变现有对象结构的情况下，为对象添加新的功能时。

模板方法设计模式：

目的：定义一个操作中的算法框架，而将一些步骤延迟到子类中。
实现方式：通过定义一个抽象类或接口，其中包含一个或多个抽象方法，以及一个或多个具体方法（模板方法）。子类必须实现抽象方法，而具体方法可以被重写或覆盖。
应用场景：当算法中有多个步骤，但其中某些步骤可能需要子类定制时。

那你自己在项目中如何使用spring进行的aop呢？

添加依赖：在项目的pom.xml或build.gradle文件中添加Spring AOP的依赖。
定义切入点（Pointcut）：使用@Pointcut注解定义一个切入点，它指定哪些方法将被拦截。
创建通知（Advice）：定义一个通知类，类上面加上@aspect注解，标明该类是一个切面类，该类包含一个或多个通知方法，这些方法将被应用到切入点指定的方法上。通知方法可以包括前置通知（Before）、后置通知（After）、环绕通知（Around）、异常通知（AfterThrowing）和最终通知（After）。
当方法执行到连接点时，创建代理对象，通过调用代理对象对应的方法，织入通知。