淘宝的秒杀小弟我感觉并不复杂，用二次事务模式可以很容易的实现
淘宝的秒杀我感觉并不复杂，用二次事务模式可以很容易的实现
嗯，核心思想应该就是“层层过滤”
对，直接在应用那边就筛掉了
我也赞成 。。。当然了。。过滤的时候 是不应该去访问DB 的。。
但是。。成功的 那些个。。用户订单 的处理 我觉得 还得用事务。。。。。。
他们楼上说的。。不用事务 应该是在 过滤的时候 呵呵。。。。不知道我理解的对不对。。。。
有个帖子说了，太长了另起一楼。大部分的观点都是“硬碰硬”，其实没有必要，如果仅仅是秒杀，我觉得没有那么复杂。
系统架构：
秒杀程序实现：
关键点：
将事务分开，在应用层的事务并不严格，可以快速的处理大量并发，不需要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秒内算完就行了。
欢迎讨论。
6 楼
sdh5724
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%能完成支付环节。
记数器， 原则上可以分层的。
第一个阶段:
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%能完成支付环节。
7 楼
ustcfrank
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%能完成支付环节。
记数器， 原则上可以分层的。
第一个阶段:
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%能完成支付环节。
嗯，核心思想应该就是“层层过滤”
8 楼
tedeyang
2010-11-15
做互联网的还有不用k/v的吗？
用了k/v还有不知道原子操作的吗？
知道了原子++--还有什么悬念吗？
用了k/v还有不知道原子操作的吗？
知道了原子++--还有什么悬念吗？
9 楼
dabian_guo
2010-11-15
其实完全不需要那么复杂， 假设有20台服务器，发放20个秒杀奖品。每个机器有1个AtomicInteger来完成自己负责的1台发放就全部搞定了，其他未中标的请求根本就不需要访问远程数据，也不需要访问远程K/V系统。
如果说有m台机器，发放n个奖品，也很容易进行简单的前期分配。
说到底，根本就不需要真正的“绝对公平”发放。
如果说有m台机器，发放n个奖品，也很容易进行简单的前期分配。
说到底，根本就不需要真正的“绝对公平”发放。
10 楼
achun
2010-11-15
在有事务处理的DB下，这个基本上没啥讨论的
还弄出来个页面AJAX2次判断，，，，
主要考虑压力问题就够了
这要靠从DB SERVER和memcached这些解决了
其他没啥问题
还弄出来个页面AJAX2次判断，，，，
主要考虑压力问题就够了
这要靠从DB SERVER和memcached这些解决了
其他没啥问题
11 楼
dabian_guo
2010-11-15
假设有10万个请求抢购20个物品，理论上只有20个有效请求。如果把其他请求也都丢到数据库或者KV系统去处理，就是很失败的架构设计。
12 楼
tedeyang
2010-11-16
引用
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.
}
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.
}
13 楼
aws
2010-11-16
dabian_guo 写道
假设有10万个请求抢购20个物品，理论上只有20个有效请求。如果把其他请求也都丢到数据库或者KV系统去处理，就是很失败的架构设计。
对，直接在应用那边就筛掉了
14 楼
renpeng301
2010-11-16
能秒杀到的都东西都是垃圾东西啊 好东西是秒不到的啊 啊啊
ipad iphone4啊啊啊啊
ipad iphone4啊啊啊啊
15 楼
fujohnwang
2010-11-16
操， 还不复杂阿， 看你这标题我就感觉很复杂了
16 楼
8821249
2010-11-16
lz的意思是 先用信号量来过滤掉大部分的请求。减少对数据库的压力。不过当集群中机子多到一定数量时，这个给数据库带来的压力也还是不小。
另外同时多商品秒杀时，其信号量的管理是个问题。
秒杀前用户持续刷新商品页也是一个要考虑的问题
另外同时多商品秒杀时，其信号量的管理是个问题。
秒杀前用户持续刷新商品页也是一个要考虑的问题
17 楼
dragonsoar
2010-11-16
还秒上隐了，大家，呵呵~
其实没有这么复杂的~
其实没有这么复杂的~
18 楼
java_wzf
2010-11-26
tedeyang 写道
做互联网的还有不用k/v的吗？
用了k/v还有不知道原子操作的吗？
知道了原子++--还有什么悬念吗？
用了k/v还有不知道原子操作的吗？
知道了原子++--还有什么悬念吗？
19 楼
rabbitbug
2010-12-13
使用缓存的，不考虑事务的
万一秒杀过程中某一台缓存服务器当机了怎么办？
部份数据丢失怎么考虑？
万一秒杀过程中某一台缓存服务器当机了怎么办？
部份数据丢失怎么考虑？
20 楼
nurenok
2010-12-14
秒杀追求个大概也差不vuduol，客户也不知道
21 楼
whao189
2010-12-24
rabbitbug 写道
使用缓存的，不考虑事务的
万一秒杀过程中某一台缓存服务器当机了怎么办？
部份数据丢失怎么考虑？
万一秒杀过程中某一台缓存服务器当机了怎么办？
部份数据丢失怎么考虑？
我也赞成 。。。当然了。。过滤的时候 是不应该去访问DB 的。。
但是。。成功的 那些个。。用户订单 的处理 我觉得 还得用事务。。。。。。
他们楼上说的。。不用事务 应该是在 过滤的时候 呵呵。。。。不知道我理解的对不对。。。。
22 楼
yangyi
2010-12-24
应该把“秒杀”服务器和订单服务器分开，秒杀的情况只需要用硬的loadbalance，标记上时间戳来过滤即可，另外秒杀的数据包肯定是有超时的，1秒+偏移就可以直接丢弃了，重定向到秒杀失败的页面。对于成功标记了时间戳的数据请求，可以应用一定的算法进行计算，说到底，我还是不知道什么是秒杀啊
23 楼
mercyblitz
2010-12-27
比如，20个宝贝，放在20台机器上面，玩秒杀！ 如果客户想玩的话，会有LB算法重定向到这20台机器上面来。只要每台确保这个宝贝原子性就行了。
秒杀到了，这个过程放在内存中就行了！交易再用事务！
上面宝贝机器模型是1：1模型，可以推至M：N模型，M必须是N的倍数即可。
这样的设计和实现，不是很简单吗？
秒杀到了，这个过程放在内存中就行了！交易再用事务！
上面宝贝机器模型是1：1模型，可以推至M：N模型，M必须是N的倍数即可。
这样的设计和实现，不是很简单吗？
24 楼
chenkan2000
2011-01-10
LZ研究一下秒杀软件比较实在。
25 楼
netbuddy
2011-01-14
淘宝“双十一”事件中的数据库架构优化
http://www.infoq.com/cn/interviews/jf-taobao-database
这篇文章可以看看
http://www.infoq.com/cn/interviews/jf-taobao-database
这篇文章可以看看