众安保险二面

当晚出结果挂了

自我介绍

1.使用RabbitMQ延时队列实现未付款订单，超过一定时间后，系统自动取消订单并解锁库存；

订单取消时，付款成功怎么办？

2.使用redis+lua脚本防止重复提交攻击，解决了用户利用浏览器刷新和回退重复提交订单的问题

为什么要用lua

3.Semaphore信号量实现秒杀和一人一单功能，通过逐步改进分布式锁的方案，解决在多线程情况下用户重复提交订单的幂等性问题；

key是怎么保证唯一性的？

userId + sessionId + skuId

4.OAuth2.0有几种授权模式？（不会）

OAuth（Open Authorization）是一种开放标准，用于授权第三方应用访问用户资源。OAuth 定义了四种授权模式，分别为：

授权码模式（Authorization Code Grant）：该模式是最常用的授权模式，适用于第三方应用在服务器端访问用户资源的场景。该模式通过授权服务器颁发授权码，再通过授权码获取访问令牌，从而实现访问用户资源。
隐式授权模式（Implicit Grant）：该模式适用于第三方应用在客户端（如浏览器）访问用户资源的场景。该模式通过直接颁发访问令牌，从而实现访问用户资源。
密码模式（Resource Owner Password Credentials Grant）：该模式适用于用户信任第三方应用，直接将用户名和密码等凭证信息传递给第三方应用，从而实现访问用户资源。
客户端模式（Client Credentials Grant）：该模式适用于第三方应用访问自己的资源，而非用户资源。该模式通过客户端直接向授权服务器获取访问令牌，从而实现访问自己的资源。

需要根据具体的业务需求和安全要求选择合适的授权模式，以保证系统的安全性和用户的隐私。

5.JWT认证做了什么改正相比于传统session?(没答上)

传统的session认证有如下的问题：

每个用户的登录信息都会保存到服务器的session中，随着用户的增多，服务器开销会明显增大

由于session是存在与服务器的物理内存中，所以在分布式系统中，这种方式将会失效。虽然可以将session统一保存到Redis中，但是这样做无疑增加了系统的复杂性，对于不需要redis的应用也会白白多引入一个缓存中间件

对于非浏览器的客户端、手机移动端等不适用，因为session依赖于cookie，而移动端经常没有cookie

因为session认证本质基于cookie，所以如果cookie被截获，用户很容易收到跨站请求伪造攻击。并且如果浏览器禁用了cookie，这种方式也会失效

前后端分离系统中更加不适用，后端部署复杂，前端发送的请求往往经过多个中间件到达后端，cookie中关于session的信息会转发多次

由于基于Cookie，而cookie无法跨域，所以session的认证也无法跨域，对单点登录不适用

2.2 JWT认证的优势

对比传统的session认证方式，JWT的优势是：

简洁：JWT Token数据量小，传输速度也很快

因为JWT Token是以JSON加密形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持

不需要在服务端保存会话信息，也就是说不依赖于cookie和session，所以没有了传统session认证的弊端，特别适用于分布式微服务

单点登录友好：使用Session进行身份认证的话，由于cookie无法跨域，难以实现单点登录。但是，使用token进行认证的话， token可以被保存在客户端的任意位置的内存中，不一定是cookie，所以不依赖cookie，不会存在这些问题

适合移动端应用：使用Session进行身份认证的话，需要保存一份信息在服务器端，而且这种方式会依赖到Cookie（需要 Cookie 保存 SessionId），所以不适合移动端

6.es倒排索引

全文检索

这种实现方式实际会存在很多问题：

评分机制

Elasticsearch使用的是 term frequency/inverse document frequency算法，简称为TF/IDF算法。TF词频(Term Frequency)，IDF逆向文件频率(Inverse Document Frequency)

Term frequency：搜索文本中的各个词条在field文本中出现了多少次，出现次数越多，就越相关。

Inverse document frequency：搜索文本中的各个词条在整个索引的所有文档中出现了多少次，出现的次数越多，就越不相关.

Field-length norm：field长度，field越长，相关度越弱

7.前后端是如何联调的？restful规范？

RESTful 是一种基于 HTTP 协议的 Web 应用程序的设计风格，其核心思想是将 Web 应用程序的功能和资源抽象为一组资源，并通过 HTTP 协议提供统一的接口进行访问和操作。以下是 RESTful 的规范：

使用 HTTP 方法（GET、POST、PUT、DELETE 等）来表示对资源的操作。GET 方法用于获取资源，POST 方法用于创建资源，PUT 方法用于更新资源，DELETE 方法用于删除资源。
使用 URI（Uniform Resource Identifier）来表示资源，URI 应该是唯一的，且能够识别资源的类型和位置。URI 应该使用名词而不是动词，如 /users 表示用户资源，而不是 /getUsers。
使用 HTTP 状态码来表示操作结果，如 200 表示成功，201 表示创建成功，404 表示资源不存在，500 表示服务器错误等。
使用 JSON 或 XML 格式来表示资源的表现形式，客户端可以通过 HTTP 头信息 Accept 来指定期望的资源表现形式。
使用 HATEOAS（Hypermedia As The Engine Of Application State）来表示资源之间的关系，即资源应该包含链接信息，客户端通过链接信息来发现和访问相关资源。
遵循单一职责原则，每个资源应该只有一个 URI，且每个 URI 只能表示一个资源。
遵循无状态原则，即客户端每次请求都应该包含足够的信息，服务端不应该保存客户端的状态信息。

以上是 RESTful 的规范，遵循这些规范可以使 Web 应用程序具有良好的可读性、可维护性和可扩展性。

hr面