一个秒杀系统的设计
一直想写一个秒杀系统的设计,网上有烂大街的教程,虽然有的写得很不错,但是还是自己设计的来的清楚,基本思路就是拦截+负载+缓存+异步
,流程如下(文字改天补上):
每一个生产者都需要向队列中生产消息,不同的生产者生产消息需要有所区别,供对应的消费者消费消息,这个是队列名称之为 Topic或者Subject
队列的消息需要一个存储的介质,Kafka的对应的存储为文件存储,生产者生产的消息存储在MessageLog
, 然后根据不同的消费和路由规则路由,投递到对应的服务器上面,产生对应的ConsumerLog.
当投递的消息比较多的时候,就需要对ConsumerLog进行分片,分到不同的服务器上面,这个分片称之为partition
,对于Kafka来说,一个Consumer
一般和Partition
成倍数关系,一个Consumer可以消费一个或者多个Partition
.
Broken可以理解为消费者的服务器。
很多成熟的MQ的消息的存储都采用的磁盘的存储模式,可能有人会认为为什么不采用内存?内存的效率不应该更快吗?我开始也有这个疑问,后来才知道顺序IO的时候,才知道不适用内存的原因:
在通信的过程中,Client
与Server
建立TCP
连接需要三次握手,为什么需要三次握手呢?又是怎么握手的过程?
TCP连接是可靠的通信方式,必须要保证两端都同时有效,且线路通畅。
如同两个人通话,但并不确定对方能不能听到,经历几次才能确保通信方式可靠呢?
1 | A: 请求连接,收到请回复密码1 |
实际具体过程如下:
Client
进程发出断开消息,进入FIN-WAIT-1
状态Server
收到断开消息,返回Ack
报文。Server
开始释放连接,Server
进入CLOSE-WAIT
Client
收到Ack
回来的消息,进入FIN-WAIT-2
状态Server
释放资源完成后,再次通知Client
可以关闭连接,Server
进入Last-Ack
状态Client
收到服务器释放完成的消息后,经过2MSL
(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。最终关闭完成后通知Server
Server
收到最后Ack
消息后,直接进入Closed
状态。在分布式环境中,为了保证业务数据的正常访问,防止出现重复请求的问题,会使用分布式锁来阻拦后续请求。具体伪代码如下:
1 | public void doSomething(String userId){ |
上面的代码解决了在分布式环境中的并发的问题。但同样需要考虑一个问题,如果insert操作和update操作异常了,分布式锁不会释放,后续的请求还会被拦截。
所以我们再优化,增加对异常的捕获。
public void doSomething(String userId){
try {
String lock=RedisUtils.get("xxxx"+userId);
if(StringUtils.isNotEmpty(lock)){//说明当前userId已经被锁定
return;
}
RedisUtils.set("xxxx"+userId,userId,1000);//锁定1s
User user=getUser(userId);
if(user==null){
insert(user);
return;
}
update(user);
}
catch(Exception ex){
}
finally{
RedisUtils.delete("xxxx"+userId);
}
}
现在即使是程序异常了,锁会自动释放。但redis的get和set也会存在并发问题,我们再继续优化,使用redis中的setnx
方法。
public void doSomething(String userId){
try {
boolean lock=RedisUtils.setnx("xxxx"+userId,userId,1000);//锁定1s
if(!lock){//说明当前userId已经被锁定
return;
}
User user=getUser(userId);
if(user==null){
insert(user);
return;
}
update(user);
}
catch(Exception ex){
}
finally{
RedisUtils.delete("xxxx"+userId);
}
}
上面的代码好像没有什么问题了,但也存在很大的隐患。
我们分析下,假设第一个请求过来,执行锁定成功,程序开始运行,但是insert和update操作阻塞了1s,第二个请求过来,锁的缓存已经过期,第二个执行锁定成功,这个时候第一个请求完成了锁被释放,第二个请求的锁就被第一次请求释放了,第三次的请求就会造成线程不安全问题。
怎么再去优化呢?问题主要是出现在第一次请求误删锁的问题,所以我们在移除锁的时候要判断能否移除。