旧博客的异步下单文章，把请求放进消息队列，再由消费者写订单。它很适合展示一个变化：用户请求不必一直等待完整的数据库操作。
这次再看代码，更值得继续讨论的是失败以后会发生什么。消息进了队列就一定有订单吗？库存已经更新，但订单插入失败怎么办？用户重复发一次请求，系统认得出来吗？
下面基于旧学习 demo 做一次代码阅读。它不是生产故障复盘，也没有新的压测结论。
阅读更多...把 Java 面试笔记串成一条工程主线
翻回以前的 Java 笔记，会发现主题已经不少了：HashMap、ConcurrentHashMap、JVM、MySQL、Redis、Spring、MQ，还有项目设计。
这些知识点单独看都很重要。但如果只是把答案一条条背下来，遇到“讲讲你的项目”时，依然容易变成一串组件名称。
可以换一个复习角度：沿着一笔订单走一遍，看这些知识分别解决哪一段问题。
阅读更多...服务启动了，然后呢？一次发布应该怎样验收
镜像打好了，容器启动了，健康检查也是绿色。打开用户入口，看到的却还是旧版本。
这不一定是代码没更新。可能新实例还没接流量，可能入口指向另一组服务，也可能应用加载的配置仍然来自旧文件。
服务内部的成功信号很重要，但它们需要与用户真正经过的路径连接起来。
阅读更多...给 AI 问答做测试：先把错误分清楚
给知识库换了检索策略，测试分数从 80 变成 90，可以上线了吗？
先别急。这个分数到底在衡量什么？搜到了目标文档，答案写得像参考答案，还是用户真的得到了可以使用的结论？
同样一个问题，可能文档找对了、答案却用错了版本；也可能答案正确，引用却点不开。把它们压成一个总分，最需要修复的地方反而不容易看见。
阅读更多...知识库能搜到，为什么还是答不准？
假设有人问：“我们正在用的这个版本，能不能处理扫描件？”
知识库搜到了三份材料：一份产品介绍、一份新版本说明，还有一份测试记录。模型读完以后回答：“支持，上传文件即可。”
听起来很顺。但再看一眼，产品介绍没有写版本，新版本说明说的是下个月准备发布的功能，测试记录只覆盖了一种文档。
问题出在哪里？材料确实找到了，可它们还不足以回答眼前这个问题。
阅读更多...秒杀系列（三）数据库与缓存双写问题的思考
缓存热点数据
在秒杀实际的业务中，一定有很多需要做缓存的场景，比如售卖的商品，包括名称、详情等。访问量很大的数据，可以算是“热点”数据了，尤其是一些读取量远大于写入量的数据，更应该被缓存，而不应该让请求打到数据库上。
阅读更多...秒杀系列（二）如何优雅地异步下订单
简单的订单异步处理实现
介绍
前面几篇文章，我们从 「限流角度，缓存角度」 来优化了用户下单的速度，减少了服务器和数据库的压力。这些处理对于一个秒杀系统都是非常重要的，并且效果立竿见影，那还有什么操作也能有立竿见影的效果呢？答案是对于下单的异步处理。
在秒杀系统用户进行抢购的过程中，由于在同一时间会有大量请求涌入服务器，如果每个请求都立即访问数据库进行扣减库存+写入订单的操作，对数据库的压力是巨大的。
如何减轻数据库的压力呢，「我们将每一条秒杀的请求存入消息队列（例如RabbitMQ）中，放入消息队列后，给用户返回类似“抢购请求发送成功”的结果。而在消息队列中，我们将收到的下订单请求一个个的写入数据库中」，比起多线程同步修改数据库的操作，大大缓解了数据库的连接压力，最主要的好处就表现在数据库连接的减少：
- 同步方式：大量请求快速占满数据库框架开启的数据库连接池，同时修改数据库，导致数据库读写性能骤减。
- 异步方式：一条条消息以顺序的方式写入数据库，连接数几乎不变（当然，也取决于消息队列消费者的数量）。
「这种实现可以理解为是一中流量削峰：让数据库按照他的处理能力，从消息队列中拿取消息进行处理。」
阅读更多...秒杀系列（一）防止超卖
秒杀系统
秒杀系统相信网上已经介绍了很多了，我也不想粘贴很多定义过来了。
废话少说，秒杀系统主要应用在商品抢购的场景，比如：
- 电商抢购限量商品
- 卖周董演唱会的门票
- 火车票抢座
- ……
秒杀系统抽象来说就是以下几个步骤：
- 用户选定商品下单
- 校验库存
- 扣库存
- 创建用户订单
- 用户支付等后续步骤
听起来就是个用户买商品的流程而已嘛！确实，所以我们为啥要说它是个专门的系统呢？
阅读更多...秒杀系列（零）高并发设计
秒杀系列开篇文章，整理分布式微服务设计中，面对高并发场景的一系列潜在问题和处理思路。
阅读更多...
