秒杀的主要瓶颈在数据库，尤其是 MySQL 这种，所以目标是减少无效请求，保证请求到数据库层面的都是有效的，所以用缓存是必要的。


1. 客户端按钮设置隐式冷却

OP 描述的“提交信息后跳转到指定页面”，用户点提交按钮，可能会返回上一页，然后继续提交，这样会生成很多无效的订单，我抢消费券就是这么干的，所以需要加一个冷却时间，用户一直操作，实际上每秒可能只有一次请求

2. 网关层限流

按钮冷却只能防普通用户，网关限流用来防止懂技术的脚本哥，根据 IP 或者 UserId 进行限制请求次数。
或者直接对商品进行限流，例如：如果商品只有 10 个，每秒请求有 10000 个，那么实际上大部分请求都是无效的，允许每秒 100 - 1000 请求进来即可，其他的直接返回「已抢光」，这里可以使用「令牌桶」和「滑动窗口」算法。

3. 服务层

OP 说用 UUID ，我感觉还是后台生成比较好，收到请求后，生成一个 OrderId 放到缓存中，然后通过 MQ 异步创建订单，直接把 OrderId 返回给客户端，再提供一个接口让前端轮询缓存中的订单状态。
MQ 消费完成后更新缓存中的订单状态，客户端发现订单已创建，再去查询真正的订单详情。

服务层使用 Redis 维护库存数量的优点也很明显，如果库存没了直接返回即可，不用调数据库，保证数据库扣减库存、生成订单都是有效操作。

4. 数据库层

通过数据库自身的锁保证原子性，防止超卖，此时数据库基本没什么压力。

这是 xxl-job 的源码，字节就改了个名字而已

https://github.com/xuxueli/xxl-job/tree/master/xxl-job-core/src/main/java/com/xxl/job/core

还以为是那个阿里

150 - 200k 指的是 150 元 至 20 万元

用事务的目的是什么，如果只是为保证多条命令原子性，可以用 lua 脚本

https://i.v2ex.co/DhWRddna.jpeg
mac 上用久了就内存泄露，在 Windows 上打开一堆 idea goland pycharm 都没什么问题，感觉是什么 bug

遇事不决看执行计划

set optimizer_trace="enabled=on";
select count(*) from tb_task where is_deleted = 0 and data_type != 1;
select * from information_schema.optimizer_trace;
set optimizer_trace="enabled=off";

1. 如果图片大部分不是纯色的，那么遍历是最快的
2. 允许小概率出现错误，采样就行，随机取 30%的像素点判断
3. 外包给印度人，肉眼判断

- 内推是最靠谱的，平时积累人脉，加一些技术群 /圈子
- 带作品直接投简历到官方招聘邮箱
- 找猎头，但是有些猎头不靠谱，拿简历瞎推，甚至都不经过本人同意，搞得我现在都不敢找猎头

工资没涨，还降了

HTTP Status 5xx 肯定是服务端抛出来的问题，但不一定应用服务有问题，显然这个是 Nginx (OpenResty) 返回的错误页面，前后端分离架构不太可能是因为 API 导致出现这个问题，建议自己冷静分析一下再去问责

可以将 translog 设置成每次写操作直接 fsync 到磁盘，但是性能会差很多。

Elasticsearch 作为搜索引擎，不应该用数据库的思路来使用，牺牲一点点一致性保证可用性是可以理解的，如果发生崩溃故障，可以手动触发同步宕机前一段时间的数据

@kaiger 这是旧款的无刻 HHKB Type-S ，彩色键帽是单独买的

以前我也纠结过这个问题，始终没有一个完美的方案可以覆盖所有场景，针对不同场景用不同实现比较好。

普通场景允许短时间内缓存不一致的话，一般用 Cache-Aside pattern 。
如果缓存不一致可能带来生产问题，比如，可能造成资损，建议还是用 事务 /分布式锁 方式保证强一致。

Cache-Aside pattern 实现简单，性能也是最好的，很多大厂都在用： https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside

想问一下有转正名额吗？比例是多少？转正之后薪资大概是多少？

怎么聊到 C10K C100K C1000K 了？
并发数和连接数根本就是 2 个概念