1、Redis 6.0 之后为何引入了多线程？6.0 之前为什么不使用多线程？
Redis 6.0 之后引入了多线程主要出于以下几个原因：
处理大量短暂请求时的性能瓶颈：在处理大量的短暂请求时，Redis 在网络 IO 或 CPU 密集型的计算操作等方面可能出现性能瓶颈。引入多线程可以提高 Redis 在多核 CPU 下的处理能力和并发性能，从而缓解性能瓶颈问题。
充分利用多核 CPU 的计算能力：单线程模型无法充分利用多核 CPU 的计算能力，而多线程模型可以通过多个 IO 线程和工作线程充分利用多核 CPU 的计算能力，从而提高 Redis 的处理能力和并发性能。
支持更高的并发量：多线程模型可以支持更高的并发量，从而满足更多的应用场景和业务需求。
Redis 6.0 之前没有采用多线程的主要原因包括：
Redis 的数据结构基于内存，而内存访问是非常快的，所以单线程的 Redis 能够在内存处理方面达到非常高的性能表现。
Redis 是一个 I/O 密集型的应用，主要涉及网络 I/O 和磁盘 I/O，而在单线程模式下，Redis 可以通过事件循环（event loop）的方式，高效地处理网络 I/O，减少 CPU 切换和上下文切换的开销。
单线程模型简化了开发和维护的复杂度，可以避免线程同步和竞争等问题。
Redis 的设计思想是追求简单、高性能和可靠性，并且提供了多种持久化机制，包括 RDB 持久化和 AOF 持久化，可以保证数据的可靠性。
2、HTTP 协议中 GET 和 POST 有什么区别？分别适用于什么场景？
GET和POST是HTTP协议中最常见的两种请求方法，用于客户端向服务器发送请求并获取响应。
| 区别 | GET | POST |
| 请求方式 | 发送请求获取资源，请求参数在 URL 中，请求数据以查询字符串形式发送 | 发送请求提交数据，请求参数在请求体中，请求数据以消息体形式发送 |
| 安全性 | 不安全，参数暴露在 URL 中，容易被窥探和篡改 | 相对安全，因为请求参数在请求体中传输 |
| 幂等性 | 幂等，多次请求返回相同的结果，不会对服务端产生影响 | 非幂等，多次请求会对服务端造成副作用（如重复插入数据） |
| 缓存性 | 支持浏览器缓存，可被缓存 | 不能被浏览器缓存 |
| 参数长度 | 有长度限制，一般不超过2048字符 | 无限制 |
| 适用场景 | 用于请求数据，请求数据量较小，获取资源，查询操作，请求参数不敏感，需要缓存时使用 | 用于提交、更新数据，数据量较大或包含敏感数据时使用，或需要保证数据一定提交成功时使用 |
它们之间的区别主要体现在数据传输、安全性和使用场景等方面，因为它能够缓存、快速响应，并且具有幂等性。GET主要用于获取资源、查询操作等无副作用操作，而POST则适合于提交数据、更新操作等有副作用操作，因为它相对安全，可以处理大量数据，并且支持更多的数据类型。
3、什么是零拷贝？说一说你对零拷贝的理解？
零拷贝是指在数据传输过程中，避免了数据在用户空间和内核空间之间的多次复制，直接在内核空间和外设之间进行传输的技术，可以提高系统的性能。
传统的数据传输过程中经常需要多次将数据从内核空间复制到用户空间、再从用户空间复制到网络缓冲区，这样会带来很大的CPU开销和额外的内存消耗。而零拷贝技术则可以直接在内核空间和网络设备之间进行数据传输，避免了不必要的数据拷贝和上下文切换，从而提高了数据传输效率和系统性能。
区别 hash模式 history模式 abstract模式
| 区别 | hash模式 | history模式 | abstract模式 |
| URL 格式 | URL 中带有 #，如：http://example.com/#/home |
URL 中没有 #，而是直接使用 path， 如： http://example.com/home |
没有真实的 URL，只使用虚拟路径，如：/home |
| 浏览器兼容性 | 兼容性好，支持所有浏览器 | 需要 HTML5 支持，不支持 IE9 及以下版本 | 无浏览器兼容问题 |
| 服务端配置 | 不需要进行额外配置，可以直接在前端中使用 | 需要服务器端进行配置，防止 404 | 不需要服务端配置 |
| SEO | 不利于 SEO，因为搜索引擎不会爬取 URL 中的 # 后面的内容 | 对 SEO 更加友好，因为路径更加规范 | 不利于 SEO |
| 使用场景 | 不需要考虑浏览器兼容性和服务端配置，适用于简单应用场景 | 需要考虑 SEO 和更规范的 URL 地址，适用于较复杂应用场景 | 非浏览器环境下的应用程序或者只需要使用编程式导航的情况 |
hash 模式： hash 模式是指在 URL 中加入 #，如 http://example.com/#/home，其中 /#/ 之后的部分称为路由路径，# 之前的部分称为 hash。当 URL 中的 hash 发生变化时，不会向服务器发出请求，而是在客户端直接根据 hash 进行相应的跳转和渲染。该模式可以避免浏览器刷新页面，但是 URL 不够美观，不能进行 SEO 优化。
history 模式： history 模式是指在 URL 中没有 #，如 http://example.com/home，这种模式需要服务器配置支持，即所有的 URL 都需要返回同一个 HTML 页面，然后由前端的路由系统根据 URL 的 path 进行相应的渲染。该模式相比于 hash 模式，URL 更加美观，可以进行 SEO 优化。
abstract 模式： abstract 模式是指在非浏览器环境中使用 Vue Router，例如 Node.js 等服务器端渲染，由于没有浏览器中的 URL，所以需要使用 abstract 模式。该模式与 history 模式类似，不需要在 URL 中加入 #，可以直接使用 path。
一般情况下，我们建议使用 history 模式，因为它对 SEO 更加友好、URL 更加规范，并且随着 HTML5 技术的普及，浏览器兼容性也不再是问题。但是在特定场景下，如需要支持 IE9 及以下浏览器，或者不方便进行服务端配置时，可以选择使用 hash 模式。而 abstract 模式则适用于一些特殊的场景，如非浏览器环境下的应用程序或者只需要使用编程式导航的情况。
