面试题整理

971230 · Oct 11, 2024 · 3f85a21 · 3f85a21
1 parent 59b3154
commit 3f85a21
Show file tree

Hide file tree

Showing 6 changed files with 59 additions and 1 deletion.
diff --git a/docs/开始阅读/index.md b/docs/开始阅读/index.md
@@ -24,6 +24,7 @@ hide:
     - [x] <a class="navigation" href="面试题/遇到的面试题整理(1-25)/">遇到的面试题整理(1-25)</a>
     - [x] <a class="navigation" href="面试题/遇到的面试题整理(26-50)/">遇到的面试题整理(26-50)</a>
     - [x] <a class="navigation" href="面试题/遇到的面试题整理(51-75)/">遇到的面试题整理(51-75)</a>
+    - [x] <a class="navigation" href="面试题/遇到的面试题整理(76-100)/">遇到的面试题整理(76-100)</a>
 - <a class="navigation" href="设计模式/">二、设计模式</a>
     - [x] <a class="navigation" href="设计模式/策略模式/">策略模式</a>
     - [x] <a class="navigation" href="设计模式/建造者模式/">建造者模式</a>

diff --git a/docs/开始阅读/面试题/img/全局唯一ID防止重复提交.png b/docs/开始阅读/面试题/img/全局唯一ID防止重复提交.png
diff --git a/docs/开始阅读/面试题/index.md b/docs/开始阅读/面试题/index.md
@@ -14,3 +14,4 @@ icon: material/head-question
 - <a class="navigation" href="遇到的面试题整理(1-25)/">② 遇到的面试题整理(1-25)</a>
 - <a class="navigation" href="遇到的面试题整理(26-50)/">③ 遇到的面试题整理(26-50)</a>
 - <a class="navigation" href="遇到的面试题整理(51-75)/">④ 遇到的面试题整理(51-75)</a>
+- <a class="navigation" href="遇到的面试题整理(76-100)/">④ 遇到的面试题整理(76-100)</a>
diff --git a/docs/开始阅读/面试题/遇到的面试题整理(51-75).md b/docs/开始阅读/面试题/遇到的面试题整理(51-75).md
@@ -730,4 +730,52 @@ SpringFactoriesLoader.loadFactoryNames(YourFactoryInterface.class, classLoader)
 });
 ```
 
-[相关链接🔗](https://developer.aliyun.com/article/1351974)
+[相关链接🔗](https://developer.aliyun.com/article/1351974)
+
+## 75.零跑汽车二面：接口幂等性相关(现场面试)
+
+什么是幂等性：是指<wavy>用户对于同一个操作发起一次请求或多次请求，得到的结果都是一样的</wavy>，不会因为请求了多次而出现异常现象。
+
+方案有很多，介绍两种：
+
+#### 1️⃣利用全局唯一ID防止重复提交
+利用数据库的主键唯一特性：相同的ID信息，数据库会抛异常，这样新增数据会失败。
+
+- (1)搭建一个生成全局唯一ID的服务。建议加入一些业务信息到该服务中，例如，
+在生成的订单 ID 中可以包含业务信息中的订单元素(如“OD”2021122620005600001)。该全局唯一ID服务可以参考雪花算法 SnowFlow 进行搭建。
+- (2)在订单确定页面中，调用全局唯-ID 服务生成订单号。
+- (3)在提交订单时带上订单号，请求到达订单系统的下单接口。
+- (4)将数据库订单表 ID 和订单号进行映射，将订单号作为订单表的 ID。
+- (5)订单系统在创建订单信息时，订单号使用前端传过来的订单号，然后直接将该订单信息插入订单库中。
+- (6)如果订单写入成功，则是第一次提交，返回下单成功;如果报 ID 冲突信息，则是重复提交在订单表中只保留之前的记录，不会写入相同的新记录。
+
+!!! Warning "注意"
+    在报“订单重复提交”错误时，不要向客户端抛出错误信息，因为重复提交的订单不一定全部失败。
+    如果给用户展示错误，则用户可能还会提交订单，这会使得用户体验不是很好。可以直接向用户展示下单成功，如图所示。
+
+<img src="../img/全局唯一ID防止重复提交.png" style="zoom: 60%;"/>
+
+#### 2️⃣利用“Token+Redis”机制防止重复提交
+
+- (1)订单系统提供一个发放 Token 的接口。这个 Token 是一个防重令牌，即一串唯一字符串可以使用 UUID 算法生成)。
+- (2)在“订单确认页”中调用获取 Token 的接口，该接口向订单确认页返回 Token，同时将此 Token 写入 Redis 缓存中，并依据实际业务对其设置一定的有效期。
+- (3)用户在“订单确认页”中点击“提交订单”按钮时，将第(2)步获取的 Token 以参数或者请求头的形式封装进订单信息中，然后请求订单系统的下单接口。
+- (4)下单接口在收到提交下单的请求后，首先判断在 Redis 中是否存在当前传入的 Token:
+    - 如果存在，则代表这是第1次请求，会删除这个Token，继续创建订单的其他业务。
+    - 如果不存在，则代表这不是第1次请求，而是重复的请求，会终止后面的业务操作
+
+!!! Warning "注意"
+    对于并发场景下的思考:在创建订单前删除 Token,还是在创建订单后再删除 Token?<br>
+    如果是在创建订单前先删除，那么在用户多次请求到达下单接口(极端情况下)后查询缓存Redis，
+    发现在Redis中已经删除了这个Token，这会导致重复提交。<br>
+    如果是在创建订单后再删除，那么在用户多次请求到达下单接口(极端情况下)后，第一个请求删除 Token 没有成功,
+    之后的请求会发现该 Token,并且比对出它们是相等的,这也会导致重复提交。
+
+所以，在应对并发修改场景下，对于 Token 的获取、比对和删除,需要使用原子操作。在 Redis中可以用 Lua 脚本进行原子操作。
+利用数据库的主键唯一特性和 Token 机制来避免重复提交，是一种比较常用的接口幂等性方案。
+对于重复提交的场景，需要依据业务进行分析，分析当前场景是否具备幂等性，如果不具有幂等性，则需要进行幂等性设计。
+
+!!! Info ""
+    幂等性设计方案远不止以上这两种，例如，可以利用数据库的悲观锁和乐观锁，或者分布式场景下的分布式锁等，来防止重复提交。
+
+[美团方案](https://tech.meituan.com/2016/09/29/distributed-system-mutually-exclusive-idempotence-cerberus-gtis.html)
diff --git a/docs/开始阅读/面试题/遇到的面试题整理(76-100).md b/docs/开始阅读/面试题/遇到的面试题整理(76-100).md
@@ -0,0 +1,7 @@
+---
+title: 遇到的面试题整理(76-100)
+description: 放一些自己面试时候遇到的面试题，总结一下
+# icon: fontawesome/solid/toilet-paper
+---
+
+# 76.
diff --git a/mkdocs.yml b/mkdocs.yml
@@ -159,6 +159,7 @@ nav:
       - 遇到的面试题(1-25): 开始阅读/面试题/遇到的面试题整理(1-25).md
       - 遇到的面试题(26-50): 开始阅读/面试题/遇到的面试题整理(26-50).md
       - 遇到的面试题(51-75): 开始阅读/面试题/遇到的面试题整理(51-75).md
+      - 遇到的面试题(76-100): 开始阅读/面试题/遇到的面试题整理(76-100).md
     - 设计模式:
       - 开始阅读/设计模式/index.md
       - 策略模式: 开始阅读/设计模式/策略模式.md