@micean 没见过有在秒杀业务上做加法的，业务做减法才是常态吧。

如果硬要在秒杀系统上加跨商品结算的话，我选择 saga pattern ，可能每单结算时间会长一点，但不会降低每个商品交易吞吐量，总吞吐量影响也不大。

@Huelse 呜呜呜😭，哪壶不开提哪壶，呜呜呜😭

@micean 我列举单机数据的意思是，“我只用单机（甚至单核）就可以做的比别人集群更快”
而不是我只能用单机，实际上我是用的框架是 akka-cluster-sharding ，是一套水平伸缩集群，意味着并发抢购多件商品的时候，性能是随着节点增加而近乎线性增长的。

而且，你说场景更像网络游戏的话，akka-cluster-sharding 的一大优势应用场景就是 MMORPG ，腾讯和暴雪都在用 akka 做百万同服同时在线。

加锁减库存的问题在于，锁掉整个商品的长时间事务，这个商品的交易会被串行化导致吞吐量急剧下降。
如果采用预扣除算法，又会要求所有其他组件都要设计回滚操作，增加了整个架构的成本。

https://devsisters.github.io/shardcake/docs/#a-simple-use-case
这两天刚发现的新 JVM 项目，也是可以面向游戏场景应用的

https://i.imgur.com/eGt4y1F.png

既然是 Java 的话，akka-cluster-sharding 了解一下，国内腾讯网易淘宝游戏等都有应用，轻松扛百万玩家在线

@allgy 今年是 2022 年，Pauseless GC 已经诞生十几年了

@micean 如果你了解 STM 的话就不会这么说了，软件事务远比分布式事务更容易实现，也更容易做到高并发高吞吐量，几行代码能描述清楚的规则，犯不着上分布式事务，上了分布式事务你不得设计回滚么？

而且我的事务以持久化视为事务提交并返回客户端，已经把系统最重要的部分模拟出来了，且保证正确性。

@micean STM （ Software transactional memory ）软件事务内存，https://hackage.haskell.org/package/stm

@winchang 扎心了，扎心了

不过说真的，我要是失业了，我就学好英语去卷国外的远程工作，函数式方向时薪能给到 $100/h 左右

@micean 这可太简单了
如果仅允许一次下单，直接前过滤，TPS 丝毫不受影响
如果允许多次下单，但总购买数量不能超过 n 个，那无非就是在软件事务内存里多加一个 if/else branch ，TPS 下降可能都低于可测量误差了

@sujin190 “整个分布式锁本来也就只在加减一才串行” 这不就是串行了么？如果失败了你还得再分布式里处理回滚，复杂度不就上升了么？

而且我是秒杀在 1 个根上就可以做到一秒接近 3 万笔交易，横向扩展也没有上限，整个系统除了业务 Java 进程，只需要 数据库 + 负载均衡就可以运作了，维护成本更低。显然更小吧

@sujin190 磁盘和网络 IO 都需要时间，即使是内网，最简单的 KV 访问也需要 >1ms 时间
你用分布式锁，怎么和软件内存中实现的事务比，直接输在起跑线上了好吧

访问 L1/2/3 到内存，时间单位可都是 ns ，内存运算完事务扔给磁盘持久化，磁盘写入多快，秒杀就能有多快。
高下立判

@buster 是的没错，扫了一眼他的文章，和我思路基本一致，不过他没提供代码示例

我用的 akka-projection 是依赖 akka-cluster-sharding 和 akka- persistence 实现的

@sujin190 并不是
1. 我的例子代码中已经保证了库存严格不超售，且订单记录有审计。
2. 其他系统和核心下单系统并不属于一个 Domain ，属于可以垂直拆分的组件，同时，折扣优惠，封控属于可以被前置业务逻辑检查的，也绝对不应该被合并到下单事务中一起处理
3. 崩溃恢复已经被 akka-projection 实现了，当然自己实现也不难，从快照+快照以后发生的日志快速回放一遍很容易。

分布式锁是最差最差的方案了，使用了分布式锁以后，你的库存扣减逻辑很难高过 100tps ，这是理论上限

路由器拿的是地址前缀，NAS 再根据 SLAAC 分配一个静态地址和几个动态地址，ipv6 变化的时候就去 ddns 重新注册一下地址。

ipv6 地址那么多，两端看到的都是真实地址了，不像过去 v4 要用端口转发做 NAT

@wdwwtzy

因为在计算机体系结构中
L1/2/3 >> Memory >> SSD > Network
所以只要开始扯 Redis ，就已经输在起跑线上了
限制秒杀系统极限的有两个因素
1. CPU 的 IPC 和 主频 ：提供锁
2. 磁盘顺序写入速度：提供持久化

结论显而易见，数据库只存储交易日志，事务由程序保证，以数据库写入响应视为事务提交
同时将交易日志的持久化做批量化聚合，一次写入一批以最大程度减少 磁盘 / 网络 的 IO 响应次数

做到以上几点，软件正确性和性能就都得到了保证，在此之上还可以利用负载均衡 hash ，或引入 akka cluster sharding 等分布式集群组件来做横向扩展和故障转移，一个接近理论上限的秒杀系统就完成了。

这也就是为什么我选择了 CQRS 模型的 Akka-Projection

@winchang 如果有意向研究 Scala 方向的技术的话，建议沿着你 quill + http4s 那条路(changzhiwin/mvc-quill)接着走，比如从 quill 层直接返回 cats-effect 的 IO ，全程不参与 Future 。还有用 Tagless final 来替换 class 构造参数的注入形式等等

文章昨天才开始写，示例代码已经放 GitHub( https://github.com/mingyang91/akka-ticketing) 了。
在我笔记本连远程数据库的环境中，单商品每秒接近三万的订单确认速率，完全不需要引入任何的 MQ / Redis / 主从分表等复杂中间件

正好在写一篇关于秒杀抢购系统的文章，我先说结论：抢购秒杀系统考验的是你对计算机体系结构的认知，所有涉及 Redis / 分布式锁的方案，有一说一，路走窄了

前两天我自己写的秒杀例子，在我笔记本上使用 2 核心，性能大约是
!!!: 17704ms consume 524287
折合每秒 2.96 万单，模拟的是 50 万请求同时抢购同一件商品，尚未做拆分。

代码： https://github.com/mingyang91/akka-ticketing

通话录音，NFC 和 出轨模式（隐私空间）？