小林coding整合

如何解决秒杀高并发和超卖现象?

第一种是在数据库层面解决,在查询商品时用 for update加排他锁 。第二种是用分布式锁， setnx命令 。这个方法缺点是同一个商品在多用户同时下单情况下，会串行化处理，没办法同一个商品大量下单。第三种是用 分布式锁加上分段缓存 ，比如商品有100个库存，在redis存5个库存key，value都是20，用户下单时对uid进行mod5计算，看落到哪个key上。

超卖过程中，如何利用redis实现高并发？（作业帮）

分布式锁：确保同一时间只有一个请求能处理库存扣减。

原子操作：用decr命令扣减库存。

消息队列：将订单请求放入消息队列kafka中，异步减轻redis压力。

网络

说一下tcp的头部。

源端口号，目的端口号，序列号和确认应答号。序列号解决网络包乱序问题，确认应答号解决丢包问题。

看MySQL的锁。

select * from performance_schema.data_locks\G;

如果 LOCK_MODE 为 X，说明是 next-key 锁； 如果 LOCK_MODE 为 X, REC_NOT_GAP，说明是记录锁； 如果 LOCK_MODE 为 X, GAP，说明是间隙锁；

id 1 5 10 15 20 name lufei suol shan wu xiang age 19 21 22 20 39

select * from user where id > 15 for update; 锁的情况： LOCK_TYPE: RECORD LOCK_MODE: X LOCK_STATUS: GRANTED LOCK_DATA: supremum pseudo-record (20,+inf]

LOCK_TYPE: RECORD LOCK_MODE: X LOCK_STATUS: GRANTED LOCK_DATA: 20 (15,20]

select * from user where id >= 15 for update; 锁的情况： LOCK_TYPE: RECORD LOCK_MODE: X,REC_NOT_GAP LOCK_STATUS: GRANTED LOCK_DATA: 15 15

LOCK_TYPE: RECORD LOCK_MODE: X LOCK_STATUS: GRANTED LOCK_DATA: supremum pseudo-record (20,+inf]

LOCK_TYPE: RECORD LOCK_MODE: X LOCK_STATUS: GRANTED LOCK_DATA: 20 (15,20]

select * from user where id < 6 for update; 锁的情况： LOCK_TYPE: RECORD LOCK_MODE: X LOCK_STATUS: GRANTED LOCK_DATA: 1 (-inf,1]

LOCK_TYPE: RECORD LOCK_MODE: X LOCK_STATUS: GRANTED LOCK_DATA: 5 (1,5]

LOCK_TYPE: RECORD LOCK_MODE: X,GAP LOCK_STATUS: GRANTED LOCK_DATA: 10 (5,10)

mysql默认自动提交

show variables like ‘autocommit’; set autocommit = 0;