ARTS 0809: 反转链表、Shopify 如何用 MySQL 解决超卖与 AI 时代程序员的价值
每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS）
Algorithm
这周是简单难度，反转链表 https://leetcode.cn/problems/reverse-linked-list/?envType=study-plan-v2&envId=selected-coding-interview
我也记录一下自己的两个错误的思路：
需要反转的链表：1 -> 2 -> 3 -> 4 -> 5
1）如果两两互换的话
1 -> 2 -> 3 -> 4 -> 5 把 2 插到最前 → 2 -> 1 -> 3 -> 4 -> 5 把 3 插到最前 → 3 -> 2 -> 1 -> 4 -> 5 把 4 插到最前 → 4 -> 3 -> 2 -> 1 -> 5 把 5 插到最前 → 5 -> 4 -> 3 -> 2 -> 1
这个思路和正确的思路其实是有点类似了，但是她需要把最后的结果和来源写到一起，非常乱
2）如果是首尾互换的逻辑呢，比如下面的例子：
▼text复制代码初始 1 -> 2 -> 3 -> 4 -> 5 ↑ ↑ 左 右 第 1 步：换 1 和 5 5 -> 2 -> 3 -> 4 -> 1 ↑ ↑ 左 右 第 2 步：换 2 和 4 5 -> 4 -> 3 -> 2 -> 1 ↑ 左右相遇（或交叉） 完成 5 -> 4 -> 3 -> 2 -> 1
如果这样写的话，那么需要前后两个不同的指针，而且这个 next 的逻辑比较麻烦
「正确」的思路：
用 1 -> 2 -> 3 把你这段代码逐步画开：
1、初始
▼text复制代码pre = null cur = 1 null 1 -> 2 -> 3 ↑ ↑ pre cur
2、第 1 轮
▼text复制代码① next = cur.next null 1 -> 2 -> 3 ↑ ↑ ↑ pre cur next ② cur.next = pre null <- 1 2 -> 3 ↑ ↑ ↑ pre cur next ③ pre = cur; cur = next null <- 1 2 -> 3 ↑ ↑ pre cur
3、第 2 轮
▼text复制代码① next = cur.next null <- 1 2 -> 3 ↑ ↑ ↑ pre cur next ② cur.next = pre null <- 1 <- 2 3 ↑ ↑ ↑ pre cur next ③ pre = cur; cur = next null <- 1 <- 2 3 ↑ ↑ pre cur
4、第 3 轮
▼text复制代码① next = cur.next null <- 1 <- 2 3 -> null ↑ ↑ ↑ pre cur next ② cur.next = pre null <- 1 <- 2 <- 3 null ↑ ↑ ↑ pre cur next ③ pre = cur; cur = next null <- 1 <- 2 <- 3 null ↑ ↑ pre cur
此时 cur == null，循环结束，return pre → 新头是 3：
▼text复制代码3 -> 2 -> 1
▼java复制代码/** * Definition for singly-linked list. * public class ListNode { * int val; * ListNode next; * ListNode() {} * ListNode(int val) { this.val = val; } * ListNode(int val, ListNode next) { this.val = val; this.next = next; } * } */ class Solution { public ListNode reverseList(ListNode head) { ListNode pre = null; ListNode cur = head; while (cur != null) { ListNode next = cur.next; cur.next = pre; pre = cur; cur = next; } return pre; } }
Review
文章是这一篇，关于 Shopify 单纯使用 MySQL 解决超卖的问题，原文链接： https://shopify.engineering/scaling-inventory-reservations
防止超卖一般需要两个操作：
- Reserve（预留）：支付开始时，把商品标记为已预留（短时占用，比如几分钟）。
- Claim（核销）：支付成功后，从库存 MySQL 扣减数量。
预留商品不能太久，要不然影响销量；支付成功核销不能太迟，否则客服有的忙了
Shopify 系统之前的做法是：
1、把预留操作再 Redis 里面进行，每一个商品一个 key ，如果触发预留操作就是用 DECR，核销操作就是 INCR。
2、核销完成之后就需要更新 MySQL
问题：
看起来很完美，Redis 能扛住并发，MySQL 也不会被直接打爆。但是真的这么完美吗？其实我们想一下，维护一套 Redis 集群当然这不是最大的问题，最大的问题就是不能把这两步合成一个原子操作，可能会出现超卖或者少卖问题。那么有没有更好的解决方案？
有没有其他的方案，有的稳重中提到了使用 MySQL8.0 的 SKIP LOCKED （下面有这个的介绍）新特性进行解决，怎么解决？
很巧妙，他把库存不单独存储再一个行里面，而是有多少库存插入多少行记录，在加持上这个 SKIP LOCKED 特性，不仅保持的 ACID 而且还减少 Redis 维护成本，非常舒服～
虽然之前没有办法解决的问题，但是现在由于 MySQL 的更新，解决起来也更简单，时代真的是会变化的。
面试鸭上面也有关于 SKIP LOCKED 的介绍 https://www.mianshiya.com/question/1780933295505174530#heading-5
Tips
1、Github Action 打包 docker image 真的好用，现在 AI 时代让 AI 写一个 yml ，之后用 Github Desktop push 到远程上面也非常方便。我本地 build 需要花了很久才还没好，我直接暂停。
2、Cursor 会读取 Claude 的 skills 会占用很多宝贵的 context ，建议检查一下
3、之前看社区说 Opus5 效果不太好，有人说可以用 Opus4.8 plan + Opus5 执行
Share
大佬的观点 https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers
作者反驳「写代码很容易，难的是想清楚做什么」：写代码本身就是硬手艺——高薪、面试、经典著作、天才程序员和遍地 bug 都说明这一点；反过来，「定需求更难」也经不起推敲，否则 PM、调研、客成早该是公司明星。真正重要的是两者都要：既懂系统怎么建，也懂为什么建。面对 AI 变革别靠自我安慰，要好奇又批判地适应；变的是工具与角色，不变的是复杂度、维护、用户说不清需求。别把理解、判断和品味外包给 AI。
PS 我最近还看到开发 FFmpeg 和 VLC 的 Podcast（虽然没看完😂） ，大佬是真的牛
