@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 和 出轨模式（隐私空间）？

比如我这个例子，UserService ，OrderService 都是静态存在的，唯一依赖是运行时的 Connection ，再怎么互相调用，再怎么交错也不会出错
https://i.imgur.com/amUjFxG.png

笨方法：延迟初始化
普通方法：抽出一层
聪明方法：不要用类来组织它们，自然就不存在循环依赖了

*typo: rock -> rpc

感觉不如去研究 ScalaPB 或者 akka-grpc ，那才是真正的通用 RPC 框架

真要是对比 RPC 框架的话也不应该拿 Akka actor 对比，Akka remote/cluster/sharding 那都是做分布式系统建模的，压根不是给通用 rock 场景准备的方案

我在安飞驰学的，场地在高科中路上，距离我上班园区 5 分钟
科目三去迪士尼附近的那个考场练车，我还是挨了几次骂的，总是忘了操作顺序