关于活动类型的并发问题

  写活动类型的项目,经常会遇到并发问题,有时候甚至会把服务器给撑爆,那么遇到这种问题一般很急,而且这类活动通常还不少,自然应当记录一下。(正常逻辑上的错误当然不会单独去说,这里指出一些常见的问题)


  假设我们的服务器在这次活动中崩溃了。我们怎么进行操作呢。


1.检查服务器(这里以阿里云为例)   

  首先得知道服务器的指标,最重要的指标有cpu,内存,宽带。这三者,每一个都会直接造成服务器卡顿不止,前两者甚至会使服务器崩溃。

  配置图如下图所示-》

image.png

  实例图如下所示(12-30号12点我们的服务器就卡爆了)

image.png

所以,如两个示例图,出现的原因就在于宽带,所以一般的解决方案就是三种

1、升级宽带(少量钱,最为直接,无需任何配置

2、购入新服务器(负载均衡或者高性能按量付费,一般来说是要提前有准备,因为也比较花费时间)

3、限流(看业务情况,也需要花费一定时间)


以上三者,不管哪一种,我们首先都得知道一个问题就是宽带怎么计算的。

这里以上图一为例,已知我们服务器的宽带的峰值是5M,我们的的网站每个页面大小是10KB,所以我们的宽带仅能支持并发量是 5000/8/10 = 63人(1Byte=8bit) 。


2.服务器检查完毕之后,就是代码的编写情况,最最常见的是两种情况

1、超发

   超发的问题一般而言也就是并发的问题,如果非并发情况你还能超发,那,哥算你厉害。

   一般而言,在活动类型项目,当并发量高并且涉及到金钱的交易的时候一定要在逻辑判断的最后一项在补充一个用户抽奖记录的查询判断(比如只能抽取一次,你就要判断有几条这个用户的记录,并且所有的更新和插入语句都要在事物当中);并发的人很有可能是同一个人,尤其是在于页面比较卡顿的情况下,没有给他返回信息;而我们的中奖信息又必须及时返回(同步)。(当然,我们还可以使用php锁之类的方式)


2、如果是现金红包不实时的问题

   如果可以,还是不建议实时发,当然,无奈得很,都得实时,目前老迪这边在高并发的情况下确实没有什么高招,现在都是微信的接口,一般而言采取队列的方式,并且记得要在队列的当中在次验证一遍确保准确无误,可以采用多进程的方式,让红包发送的更快。


1

关注者
0 个评论