java面试——2021校招提前批字节飞书后端面试问题集合

介绍一下微服务秒杀项目

redis成为热点怎么办？

利用的redis的（主从、哨兵、集群）做压力的均分

集群怎么解决

 

nginx负载均衡、配置、权重算法实现

 

令牌桶、漏桶区别，使用场景

 

jwt结构、为什么用jwt

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。

 {
  "姓名": "张三",
  "角色": "管理员",
  "到期时间": "2018年7月1日0点0分"
}

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

使用JWT的原因

    鉴权逻辑无需访问数据库，任何情况下都不会击穿缓存打到数据库影响业务；
    与数据库解耦，横向扩容性佳，Token发放、验证都可以脱离数据库
    同样是提供Token，但JWT中可附带允许的权限/操作，业务无需实现复杂的权限控制逻辑，只需要判断Token中是否有对应权限即可；
    数据平台主要的功能就是提供数据访问接口与数据上传接口，没有传统Web应用的那种上下文关系。过重的鉴权逻辑不太符合当前业务特点；
    使用多版本私钥，通过更改固定版本签名所用的私钥可以批量废除发出的Token；使用Redis等缓存后亦可实现对单一Token的回收
    业务只有上传/拉取这两个操作，只需要区分当前用户是谁即可

oauth2流程、有安全风险吗、state参数了解吗

新浪微博作为服务提供商，拥有用户的头像、昵称、邮箱、好友以及所有的微博内容，简书希望获取用户存储在微博的头像和昵称，假设它们是三个人：

1. 简书问新浪微博：我想要获取用户 A 的头像和昵称，请你提供
2. 微博说：我需要经过用户Ａ 本人的许可，然后去问用户 A 是否要授权简书访问自己的头像和昵称
3. 用户 A 对微博说：我给简书一个临时的钥匙，如果他给你出示了这把钥匙，你就把我的资料给他
4. 简书使用户给它的钥匙获取用户头像和昵称信息。

以上是 OAuth 认证的大概流程。在使用微博授权之前，简书需要先在微博开放平台上注册应用，填写自己的名称、logo、用途等信息，微博开放平台颁发给简书一个应用 ID 和叫 APP Secret 的密钥，在实际对接中，会使用到这两个参数。

state 参数是为了保证申请 code 的设备和使用 code 的设备的一致而存在的。

对于开发者而言，要修复这个漏洞，就是必须加入state参数，这个参数既不可预测，又必须可以充分证明client和当前第三方网站的登录认证状态存在关联（如果存在过期时间更好）。其实，随机算一个字符串，然后保存在session，回调时检查state参数和session里面的值，就满足要求了。state生成随机算一个字符串，然后保存在当前用户的session，回调时检查state参数和当前用户session里面的值是否一致.攻击者无法猜对方的state值是多少.  就无法拼出用于攻击的url.。

csrf攻击是什么？怎么防范

一般来说，攻击者通过伪造用户的浏览器的请求，向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等。攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。

防范手段：

1 验证 HTTP Referer 字段：HTTP头中的Referer字段记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，而如果黑客要对其实施 CSRF攻击，他一般只能在他自己的网站构造请求。因此，可以通过验证Referer值来防御CSRF 攻击。

2 关键操作页面加上验证码，后台收到请求后通过判断验证码可以防御CSRF。但这种方法对用户不太友好。

3 在请求地址中添加token并验证：CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于cookie中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有token或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于session之中，然后在每次请求时把token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。而对于 POST 请求来说，要在 form 的最后加上 ，这样就把token以参数的形式加入请求了。

4 在HTTP 头中自定义属性并验证：这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。

rabbitmq协议、如何保证消息被投递（看到过但是没了解）

1.通过AMOP提供的事务机制:

2消息的确认机制 从confirm机制  在发送完消息后可以通过WaitForConfirm等待消息的投递结果，这里有个可选参数，就是阻塞等待的时间，如果返回结果为false则表示消息投递失败，则发送端这时候也就可以采取重试之类的策略了。一种同步的，一种异步通知的：异步回调的方式也就是通道订阅RabbitMQ的发送完毕确认事件，消息投递成功会回调这个方法给发送方，回调的参数包含当前消息在该通道中发送的编号DeliveryTag（批量提交的时候可以根据这个编号对应提交集合的索引，保证对应集合索引上的消息可靠投递）

Exchange类型

三种类型：Direct exchange  Topic exchange(可以使用通配符)  Fanout exchange

netty拆包 解决粘包和拆包的四种解决方案

在RPC框架中，粘包和拆包问题是必须解决一个问题，因为RPC框架中，各个微服务相互之间都是维系了一个TCP长连接，比如dubbo就是一个全双工的长连接。由于微服务往对方发送信息的时候，所有的请求都是使用的同一个连接，这样就会产生粘包和拆包的问题

粘包和拆包

产生粘包和拆包问题的主要原因是，操作系统在发送TCP数据的时候，底层会有一个缓冲区，例如1024个字节大小，如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题；如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。如下图展示了粘包和拆包的一个示意图：

对于粘包和拆包问题，常见的解决方案有四种：

• 客户端在发送数据包的时候，每个包都固定长度，比如1024个字节大小，如果客户端发送的数据长度不足1024个字节，则通过补充空格的方式补全到指定长度；
• 客户端在每个包的末尾使用固定的分隔符，例如\r\n，如果一个包被拆分了，则等待下一个包发送过来之后找到其中的\r\n，然后对其拆分后的头部部分与前一个包的剩余部分进行合并，这样就得到了一个完整的包；
• 将消息分为头部和消息体，在头部中保存有当前整个消息的长度，只有在读取到足够长度的消息之后才算是读到了一个完整的消息；
• 通过自定义协议进行粘包和拆包的处理。

 Netty提供的粘包拆包解决方案

3.1 FixedLengthFrameDecoder

对于使用固定长度的粘包和拆包场景，可以使用FixedLengthFrameDecoder，该解码一器会每次读取固定长度的消息，如果当前读取到的消息不足指定长度，那么就会等待下一个消息到达后进行补足。其使用也比较简单，只需要在构造函数中指定每个消息的长度即可。这里需要注意的是，FixedLengthFrameDecoder只是一个解码一器，Netty也只提供了一个解码一器，这是因为对于解码是需要等待下一个包的进行补全的，代码相对复杂，而对于编码器，用户可以自行编写，因为编码时只需要将不足指定长度的部分进行补全即可。

3.2 LineBasedFrameDecoder与DelimiterBasedFrameDecoder

对于通过分隔符进行粘包和拆包问题的处理，Netty提供了两个编解码的类，LineBasedFrameDecoder和DelimiterBasedFrameDecoder。这里LineBasedFrameDecoder的作用主要是通过换行符，即\n或者\r\n对数据进行处理；而DelimiterBasedFrameDecoder的作用则是通过用户指定的分隔符对数据进行粘包和拆包处理。同样的，这两个类都是解码一器类，而对于数据的编码，也即在每个数据包最后添加换行符或者指定分割符的部分需要用户自行进行处理。

3.3 LengthFieldBasedFrameDecoder与LengthFieldPrepender

这里LengthFieldBasedFrameDecoder与LengthFieldPrepender需要配合起来使用，其实本质上来讲，这两者一个是解码，一个是编码的关系。它们处理粘拆包的主要思想是在生成的数据包中添加一个长度字段，用于记录当前数据包的长度。LengthFieldBasedFrameDecoder会按照参数指定的包长度偏移量数据对接收到的数据进行解码，从而得到目标消息体数据；而LengthFieldPrepender则会在响应的数据前面添加指定的字节数据，这个字节数据中保存了当前消息体的整体字节数据长度。LengthFieldBasedFrameDecoder的解码过程如下图所示：

3.4 自定义粘包与拆包器

对于粘包与拆包问题，其实前面三种基本上已经能够满足大多数情形了，但是对于一些更加复杂的协议，可能有一些定制化的需求。对于这些场景，其实本质上，我们也不需要手动从头开始写一份粘包与拆包处理器，而是通过继承LengthFieldBasedFrameDecoder和LengthFieldPrepender来实现粘包和拆包的处理。

如果用户确实需要不通过继承的方式实现自己的粘包和拆包处理器，这里可以通过实现MessageToByteEncoder和ByteToMessageDecoder来实现。这里MessageToByteEncoder的作用是将响应数据编码为一个ByteBuf对象，而ByteToMessageDecoder则是将接收到的ByteBuf数据转换为某个对象数据。通过实现这两个抽象类，用户就可以达到实现自定义粘包和拆包处理的目的。如下是这两个类及其抽象方法的声明：

public abstract class ByteToMessageDecoder extends ChannelInboundHandlerAdapter {
    protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List