秒杀方案收集

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%能完成支付环节。 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值