秒杀系统与 CAP 理论解构
秒杀系统因承接天量请求采用分布式,多节点导致网络分区(P),下单阶段用 AP 保可用、付款阶段用 CP 保一致性,业务上两种模式兼顾。
秒杀系统因承接天量请求采用分布式,多节点导致网络分区(P),下单阶段用 AP 保可用、付款阶段用 CP 保一致性,业务上两种模式兼顾。
事务是放大器,用错位置,必出事故
方法名不是描述实现,而是提前暴露风险与边界的工程语言。
如果一个方法名无法回答:是谁在做、是否同步、是否改状态、是否跨系统——那这个命名一定有问题。
一旦动词失真,架构必然腐化。
大语言模型并没有脱离经典计算机科学
它只是把概率论、线性代数、微积分和信息论等推到了一个前所未有的工程尺度
它的“智能感”来自规模、结构与统计规律的叠加
异常值之所以重要,是因为它们决定了系统对未知世界的适应能力上限
亚马逊的尽头是 VC,VC 的尽头是 DI。
发现我在用的obsidian同步方式有三套,记录对比一下
这篇文章不推荐「哪一个最好」,而是回答三个更关键的问题:
- 各自解决的核心问题是什么
- 各自的隐含代价在哪里
- 什么数据,应该放在哪一套里
结论先给出来:
没有“通用最优解”,只有“数据类型 × 风险偏好”的最优匹配。
他人即地狱
— 保罗·萨特