1、TCP 和 UDP 协议有什么区别，分别适用于什么场景？

TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是两种常用的传输层协议，两者的区别比较如下：

	TCP	UDP
可靠性	可靠	不可靠
连接性	面向链接	无连接
报文	面向字节流	面向报文
效率	传输效率低	传输效率高
安全性	容易被攻击、安全性不如UDP	也会被攻击，相对TCP来说安全
可靠性	可靠，无差错、不丢失、不重复有序的传输	不可靠传输，不保证传输有序性
双工性	全双工	一对一、一对多、多对一、多对多
流量控制	滑动窗口	无
拥塞控制	慢开始、拥塞避免、快重传、快恢复	无
传输速度	慢	快
应用场景	对效率要求低，对准确性要求高或要求有链接的场景	对效率要求高、对准确性要求低

TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是两种常用的传输层协议，它们有以下的区别：

1、连接方面

TCP 是面向连接的协议，而 UDP 是无连接的协议。在 TCP 中，发送方和接收方必须先建立连接，然后才能传输数据。UDP 则不需要建立连接，直接发送数据即可。

2、可靠性 TCP 保证数据传输的可靠性，通过序列号、确认应答和重传机制等方式来保证数据的完整性和正确性。UDP 则不保证数据传输的可靠性，因为它不提供确认和重传机制。

3、传输速度 因为 TCP 要保证数据传输的可靠性，所以在传输速度方面相对较慢。而 UDP 则不需要进行复杂的传输控制，因此传输速度更快。

4、传输内容 TCP 是一种面向字节流的协议，将数据看作是一连串的字节流，没有明确的消息边界。UDP 则是面向报文的协议，将数据看作是一系列的报文，每个报文是一个独立的单元，具有明确的消息边界。

基于以上的特点，TCP 和 UDP 适用于不同的场景。TCP 适用于对传输可靠性要求比较高的场景，例如网页浏览、文件传输、邮件等。而 UDP 则适用于对传输可靠性要求较低、传输速度要求较高的场景，例如在线游戏、视频直播等。

TCP 用于在传输层有必要实现可靠传输的情况；而在一方面，UDP 主要用于那些对高速传输和实时性有较高要求的通信或广播通信。TCP 和 UDP 应该根据应用的目的按需使用。

2、如何用 Redis 实现分布式 Session？

回答一：

通过redis中的hash来实现，将token的值作为键，他里面的每一个字段对应着，用户相关的信息，当用户第一次登陆的时候就会生成一个token，在用户下次登陆的时候就会请求头中携带这个token，后端通过校验请求头的token在redis中是否存在，如果存在就直接返回用户的信息，不存在就直接跳转登录页，这个token可以使用uuid的形式来生成避免重复，以及被窃取的风险

回答二：

在分布式系统中，通常会将 Session 存储在 Redis 中来实现分布式 Session，这样就可以在多台服务器之间共享 Session 数据。实现分布式 Session 的方式有多种，其中一种常用的方式是使用 Redis 的数据结构 Hash。具体实现步骤如下：

1. 在用户登录成功后，将 Session 数据存储在 Redis 中。
2. 将 Redis 中的 Session 数据的 Key 设置为一个全局唯一的 ID，一般使用类似于“session:token”这样的格式，其中 token 是一个随机生成的字符串，用来标识这个 Session 数据。
3. 在客户端返回响应的同时，将 Session ID（即 token）以 Cookie 的形式返回给客户端。客户端在后续的请求中都会携带这个 Cookie。
4. 在后续的请求中，服务器会从客户端传递过来的 Cookie 中获取 Session ID，然后根据这个 ID 从 Redis 中获取对应的 Session 数据。如果 Redis 中没有找到对应的 Session 数据，那么就表示这个请求无法通过认证。
5. 在用户退出登录或 Session 失效时，需要将 Redis 中的对应 Session 数据删除。

可以使用 Redis 的 EXPIRE 命令来设置 Session 数据的过期时间，这样可以自动删除已经过期的 Session 数据。同时，还需要注意保护 Redis 中的 Session 数据不被恶意攻击者窃取，一般可以通过设置 Session 数据的前缀和使用随机的 Session ID 等方式来提高安全性。

回答三：

在分布式系统中，为了保持用户的登录状态，需要使用Session来记录用户信息，但是单机的Session无法满足高并发和负载均衡的需求。Redis可以通过集群、主从复制等技术实现分布式Session，具体实现方式如下：

1. 选择一个集中式的缓存服务器（如Redis），将Session信息存储到缓存服务器中。这里可以使用Redis的Hash数据结构存储Session信息，使用Session ID作为Hash的Key，Session对象作为Hash的Value。
2. 为了保证Session的有效性，需要给Session设置一个过期时间。在Redis中，可以通过设置Hash的expire时间来实现Session过期。一般情况下，Session过期时间设置为30分钟或者1个小时。
3. 在客户端请求到达应用服务器时，应用服务器会读取Session ID，并通过Session ID从缓存服务器中读取Session信息。如果Session已过期，则需要重新生成一个Session ID，并重新创建一个新的Session信息。
4. 为了提高性能，可以在应用服务器本地缓存一份Session信息。当应用服务器需要读取Session信息时，先从本地缓存中读取，如果本地缓存中不存在，则从缓存服务器中读取，并将Session信息保存到本地缓存中。这样可以减少对缓存服务器的访问，提高系统性能。
5. 在多台应用服务器上部署同一个应用程序时，需要保证Session的一致性。可以使用Redis的集群或主从复制功能来实现Session的共享。

回答四：

在分布式系统中为了保证用户的登陆态，我们会把用户的登录信息存储在「session」里。而session是依赖于「cookie」的，即服务器创建session时会给它分配一个唯一的ID，并且在响应时创建一个cookie用于存储这个「sessionId」。当客户端收到这个cookie之后，就会自动保存这个sessionId，并且在下次访问时自动携带这个sessionId，届时服务器就可以通过这个sessionId得到与之对应的session，从而识别用户的身。

1. 第一是「创建令牌（key）」的程序，就是在用户初次访问服务器时，给它创建一个「唯一的身份标识」，并且使用cookie封装这个标识再发送给客户端。那么当客户端下次再访问服务器时，就会自动携带这个身份标识了，这和sessionId的道理是一样的，只是改由我们自己来实现了。另外，在返回令牌之前，我们需要将它存储起来，以便于后续的验证。而这个令牌是不能保存在服务器本地的，因为其他服务器无法访问它。因此，我们可以将其存储在服务器之外的一个地方，那么Redis便是一个理想的场所。
2. 第二是「验证令牌」的程序，就是在用户再次访问服务器时，我们获取到了它之前的身份标识，那么我们就要验证一下这个标识是否存在了。验证的过程很简单，我们从Redis中尝试获取一下就可以知道结果。

3、什么是分布式的 CAP 理论？

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个。

• 一致性 ：数据在多个副本之间能够保持一致的特性。
• 可用性：系统提供的服务一直处于可用的状态，每次请求都能获得正确的响应。
• 分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

CAP三者不可同得，那么必须得做一些权衡。

CA without P

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但是对于分布式系统，分区是客观存在的，其实分布式系统理论上是不可选CA的。

CP without A

如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

AP wihtout C

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

t C**

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。