1、
这个东西, 很容易控制的。
记数器, 原则上可以分层的。
第一个阶段:
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%能完成支付环节。