精华帖 (0) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (11)
|
|
---|---|
作者 | 正文 |
发表时间:2010-11-15
有个帖子说了,太长了另起一楼。大部分的观点都是“硬碰硬”,其实没有必要,如果仅仅是秒杀,我觉得没有那么复杂。
系统架构:
秒杀程序实现:
关键点:
将事务分开,在应用层的事务并不严格,可以快速的处理大量并发,不需要db,也需要网络cache,唯一的操作就是本机内存操作,效率肯定非常高。
应用成功后,在将事务发到DB,这个时候可能由于并发会出现多拍的用户,再由DB过滤一遍,确保不会多拍。
唯一的缺点是事务到DB的同步过程有延迟,这是很快的,毫秒级。所以让(可能拍成功的)用户等两秒,用户应该可以接受。
性能分析:
应用层:基本没有代价,就看服务器处理连接的效率了,程序上只是一个计数器。如果觉得计数器是同步的会慢,就换成普通的int变量,多放几个“可能成功”的买家到 DB层过滤。假设1台机器1秒钟处理2000个请求应该问题不大吧。再假设网友会在60秒内提交完请求(由于时间不一致,很多网友的时钟不一定非常准确),一个服务器也能抗下12万用户。就算1千万网友参加,100台机器也足够了。
如果像taobao的博客所言的在处理100k并发技术,1台机器1秒钟处理10万用户,60秒就能处理600万。1千万并发也不过2台机器的事情。
数据库:数据库的并发来自有多少台应用服务器,应用服务器允许多少“可能买家”通过, 而不是有多少买家来秒杀。如果按照有些网友已经提到的,在机器中提前分配好,比如5台ipad,1台机器1台,其他机器直接报没有。那么DB的压力也就5台机器,可能传入的50个可能买家?计算时间上,也只需要2秒内算完就行了。
欢迎讨论。
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2010-11-15
LZ 对这个秒杀 杀上瘾了! 呵呵!
|
|
返回顶楼 | |
发表时间:2010-11-15
问题是:"接受到请求,count.getAndDecrement()" 这句话,必须是集群的行为,而不是单机的行为。
就不是share nothing了吧 |
|
返回顶楼 | |
发表时间:2010-11-15
秒杀这样的东西,还能考虑事务?说明兄弟你没有浸淫在互联网
|
|
返回顶楼 | |
发表时间:2010-11-15
我只是觉得为啥不用队列呢?
|
|
返回顶楼 | |
发表时间:2010-11-15
ustcfrank 写道 问题是:"接受到请求,count.getAndDecrement()" 这句话,必须是集群的行为,而不是单机的行为。
就不是share nothing了吧 楼主的意思是,这一层只是简单过滤,比如前端server有5台,每台计数5,也就最多放25用户,到达DB层,进行第二次过滤,减少了数据库的压力。 |
|
返回顶楼 | |
发表时间:2010-11-15
最后修改:2010-11-15
这个东西, 很容易控制的。
记数器, 原则上可以分层的。 第一个阶段: define: allowNextStep = 1000 in cache server, it is an atom k/v; int allowNextStep = 0; static volitale bool allowAccessCache = true; if(allowAccessCache) { allowNextStep = allowNextStep.getAndDecrement() ; if(allowNextStep < 0){ allowAccessCache=false; } }else{ ///reject all other user. //support: 1000 users can enter payment step and done check. } 下一个步骤就是 按照类似的方法控制支付成功等业务要的要求了, 这个就很不好具体代码演示了。 因为根据业务要求不同, 需要使用不同的策略。 真正能进入支付阶段是少数人。 如果仅仅一个商品仅仅1000人进入下个阶段。 再怎么烂的架构也能支撑住了。 根据这样处理后, memcached类的群集压力就非常低了。 也就前1000个抢到计数器用户才能进入下一阶段。 其余用户通通的拒绝回去。 秒杀只要再关键细节性能上考虑到。 实际上, 40台左右的虚拟机器就能承受极大的压力。当然在服务器的细节参数设计上, 还有很多要考虑。 实际中,修改为100个人也是可以的。 基本还是100%能完成支付环节。 |
|
返回顶楼 | |
发表时间:2010-11-15
sdh5724 写道 这个东西, 很容易控制的。
记数器, 原则上可以分层的。 第一个阶段: define: allowNextStep = 1000 in cache server, it is an atom k/v; int allowNextStep = 0; static volitale bool allowAccessCache = true; if(allowAccessCache) { allowNextStep = allowNextStep.getAndDecrement() ; if(allowNextStep < 0){ allowAccessCache=false; } }else{ ///reject all other user. //support: 1000 users can enter payment step and done check. } 下一个步骤就是 按照类似的方法控制支付成功等业务要的要求了, 这个就很不好具体代码演示了。 因为根据业务要求不同, 需要使用不同的策略。 真正能进入支付阶段是少数人。 如果仅仅一个商品仅仅1000人进入下个阶段。 再怎么烂的架构也能支撑住了。 根据这样处理后, memcached类的群集压力就非常低了。 也就前1000个抢到计数器用户才能进入下一阶段。 其余用户通通的拒绝回去。 秒杀只要再关键细节性能上考虑到。 实际上, 40台左右的虚拟机器就能承受极大的压力。当然在服务器的细节参数设计上, 还有很多要考虑。 实际中,修改为100个人也是可以的。 基本还是100%能完成支付环节。 嗯,核心思想应该就是“层层过滤” |
|
返回顶楼 | |
发表时间:2010-11-15
做互联网的还有不用k/v的吗?
用了k/v还有不知道原子操作的吗? 知道了原子++--还有什么悬念吗? |
|
返回顶楼 | |
发表时间:2010-11-15
其实完全不需要那么复杂, 假设有20台服务器,发放20个秒杀奖品。每个机器有1个AtomicInteger来完成自己负责的1台发放就全部搞定了,其他未中标的请求根本就不需要访问远程数据,也不需要访问远程K/V系统。
如果说有m台机器,发放n个奖品,也很容易进行简单的前期分配。 说到底,根本就不需要真正的“绝对公平”发放。 |
|
返回顶楼 | |