一个秒杀系统的设计
一直想写一个秒杀系统的设计,网上有烂大街的教程,虽然有的写得很不错,但是还是自己设计的来的清楚,基本思路就是拦截+负载+缓存+异步
,流程如下(文字改天补上):
每一个生产者都需要向队列中生产消息,不同的生产者生产消息需要有所区别,供对应的消费者消费消息,这个是队列名称之为 Topic或者Subject
队列的消息需要一个存储的介质,Kafka的对应的存储为文件存储,生产者生产的消息存储在MessageLog
, 然后根据不同的消费和路由规则路由,投递到对应的服务器上面,产生对应的ConsumerLog.
当投递的消息比较多的时候,就需要对ConsumerLog进行分片,分到不同的服务器上面,这个分片称之为partition
,对于Kafka来说,一个Consumer
一般和Partition
成倍数关系,一个Consumer可以消费一个或者多个Partition
.
Broken可以理解为消费者的服务器。
在通信的过程中,Client
与Server
建立TCP
连接需要三次握手,为什么需要三次握手呢?又是怎么握手的过程?
TCP连接是可靠的通信方式,必须要保证两端都同时有效,且线路通畅。
如同两个人通话,但并不确定对方能不能听到,经历几次才能确保通信方式可靠呢?
1 | A: 请求连接,收到请回复密码1 |
通过上面的分析,可以明确的知道为什么TCP
需要三次握手,因为少了任何一次,都不能确保当前的网络是通畅的。
Q:使用两次握手会有什么问题?
A: 如果使用两次握手协议,B不知道A是否能够收到自己的消息,如果B此时进行补偿,就有可能多次发送。如果B此时忽略,A可能真的没有收到消息。
如果B的消息在传输的过程中丢失了,A也将不知道B有没有真正的准备好。
实际具体过程如下:
在分布式环境中,为了保证业务数据的正常访问,防止出现重复请求的问题,会使用分布式锁来阻拦后续请求。具体伪代码如下:
1 | public void doSomething(String userId){ |
上面的代码很简单,查询db中有没有对应的user数据,如果有的话,执行更新操作,如果没有则插入。
我们知道,上面的代码是线程不安全的,在多线程的环境中,就会出现问题。为了能够保证数据的正确性,在单机环境下,我们可以使用synchronized
的方法,来保证线程安全,具体修改:
1 | public synchronized void doSomething(String userId){ |
在单机器的环境下,能够解决线程安全的问题,那在分布式环境下呢? 这个时候需要用到分布式锁
.
分布式锁需要借助其他组件来实现,常用的有redis
和zookeeper
。下面我们就用redis的实现,来说明下问题,分布式锁具体的实现方法如下:
1 | public void doSomething(String userId){ |
上面的代码解决了在分布式环境中的并发的问题。但同样需要考虑一个问题,如果insert操作和update操作异常了,分布式锁不会释放,后续的请求还会被拦截。