@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 分钟
科目三去迪士尼附近的那个考场练车，我还是挨了几次骂的，总是忘了操作顺序

放资源池不就行了，学 jdbc 的 connection pool 呗。

买 Office 365 赠送的 1TB OneDriver ，Win/Mac 都有客户端自动同步，完全不担心数据会丢失
重要数据我还会同时丢到 iCloud 和 Google Drive 上做个备份

我用 jb-compose

f1 :: A -> B
f2 :: C -> D
f3 :: B -> D -> E
f4 :: E -> R

let b = f1(a)
let d = f2(c)
let e = f3(b, d)
let result = f4(e)

直接把业务依赖编码进类型里不就完事了？

@haimall 无差别打击了，别人晚上载着老婆孩子回家，碰上你教唆别人放的钉子出了车祸，你负责么？

1. 我提的 byd 宋 dmi ，满油续航一千多公里，我看 M5 续航里程也差不多
2. 想要蓝牌的话可以拍，听说新能源车也可以上蓝牌，而且蓝牌跟人走，万一哪天新能源政策没了，你的车牌还在手里。