1. 作者讲了什么？ 针对**必须保证数据可靠性的写需求**（例如订单操作）的操作，如何保证数据库的可靠性（准确） 引入了**幂等**的概念，表明重复请求在实际生产环境中不可避免； 要避免重复请求，就需要使请求幂等，并通过列子说明，如何实现请求的幂等 2. 作者是怎么把事情说明白的？ 通过举了电商系统订单的实际的几个例子： 1. 订单创建，如何保证保证不重复下单 2. 订单更新，如何保证准确和幂等 3. 为了讲明白，作者讲了哪些要点？哪些是亮点？ **要点** 1. 实际生产环境，重复请求不可避免（客户端重试、服务间重试） 2. 增： 1. 生成唯一订单ID，订单ID全局唯一，并递增（为了MySQL建立索引时，如果不递增引起页分裂等问题，导致写入性能下降） 2. 将生成的ID放入缓存 3. order表的订单ID字段设置唯一索引约束 4. 客户端请求带上订单ID，如果重复插入会引起唯一索引重复，导致事务失败 5. 由于订单已经创建成功，对于由于唯一索引冲突导致的创建失败，需要给前端返回“创建成功”，防止对客户产生困扰 3. 改：更改请求接口，带上当前version；SQL条件加上`WHERE version=x `实现天然幂等 ```sql UPDATE order SET tarcing_num=666 AND version=version+1 WHERE id=100 AND version=6 ``` 4. 对于作者所讲，我有哪些发散性思考？ 1. 对于任何“写”操作的接口，在设计的时候，都需要考虑**幂等**的概念。对于需要强保证数据可靠性的服务，需要设计**幂等** 2. 对于下订单、发表文章、发表评论这些写入服务的接口，除了幂等，还有防止重复提交、快速提交的问题 - 一方面 ：客户端端需要做锁，用户点击“发布”按钮后，在网络请求没有返回，或者超时之前，用户都不可以继续点击“发布按钮”，界面可以将按钮置灰或者转菊花 - 另一方面：服务端需要进行加锁 1. 请求接口时，获取一个锁 锁的粒度 ：同一用户的同一操作逻辑 锁名称规则：业务名称+用户ID （例如：post_msg:100101 ） 2. 给锁设置过期时间2-3秒，防止业务逻辑执行错误，用户一直被锁住 3. 如果被锁了，返回“正在处理，请勿重复提交” 4. 没有被锁，执行正常逻辑，在逻辑结束后，删掉锁 5. 在未来哪些场景，我可以使用它？ 1. 在做任何更新接口时，时刻考虑是否需要实现**幂等**

老师想问下库存在高并发下有没有方法解决超卖或少卖问题，看了下好多同学都问了，但是老师都不回答

老师好 单个mysql的并发 你那边有它的并发数据吗

解答了多年了认为大学学的知识没用的疑惑

发现老师不仅技术好，课讲的好，文采也好。所谓触类旁通。哈哈

老师江湖再见！消息队列高手可和后端存储实战课，非常不错，我从中学习到了很多东西！

老师江湖再见，祝顺利👍👍

一下子和Java的GC算法产生了共鸣。 创建新表的方式，只复制少部分数据，效率更高，但你要能接受这段时间的STW。这是复制算法。 历史归档，删除数据的方式，会产生碎片，利用率低。只有到空间不足的情况下，才进行压缩整理（OPTIMIZE）。这是标记清理算法，关键时刻再整理（STW），CMS GC就是这个思路。

这门课对我帮助很大。谢谢老师，期待下门课程发布。

Flag：理清几种常见数据库的使用场景和遇到存储问题的解决思路