大话程序猿眼里的高并发

 
博客园将不进行维护,转站到个人我的博文:地址
 
大话程序猿眼里的高并发
 
 
 简单理解下高并发:
    高并发是指在同一个时间点,有不少用户同时的访问URL地址,好比:淘宝的双11,双12,就会产生高并发,如贴吧的爆吧,就是恶意的高并发请求,也就是 DDOS攻击
    再屌丝点的说法就像玩撸啊撸被ADC暴击了同样,那伤害你懂得(若是你看懂了,这个说法说明是正在奔向人生巅峰的 屌丝)。
 
 高并发会来带的后果:
    服务端:致使站点服务器/DB服务器资源被占满崩溃,可能产生不是理想中的重复杂乱的数据。
    用户角度:尼玛,这么卡,老子来参加活动的,刷新了仍是这样,垃圾网站,不再来了。
个人经历:
     在作公司产品网站的过程当中,常常会有这样的需求,好比什么搞个活动专题,抽奖,签到,搞个积分竞拍 等等,若是没有考虑到高并发下的数据处理,那就Game Over了,很容易致使抽奖被多抽走,签到会发现一个用户有多条记录,签到一次得到了得到了多积分,等等,各类超出正常逻辑的现象,这就是作产品网站必须考虑的问题,由于这些都是面向大量用户的,而不是像作ERP管理系统,OA系统那样,只是面向员工。
 
下面我进行实例分析,简单粗暴,动态分析,纯属本人我的经验分享, 若有说错,或者有更好的建议或者意见的请留言,你们一块儿成长
 

1,高并发的数据处理:前端

    经过表设计或者SQL语句来防止包并发下的数据错乱问题
    经过程序代码防止包并发下的数据错乱问题
 
-------------------------------------------[我只是美丽的分割线]-------------------------------------------
如例子1(经过表设计防止并发致使数据错乱)
        需求点:
           【签到功能】
            一天一个用户只能签到一次,
            签到成功后用户获取到一个积分
        已知表:
            用户表,包含积分字段
         高并发意淫分析(属于开发前的猜想):
            在高并发的状况下,会致使,一个用户签到记录会有多条,或者用户签到后不止加一积分。
        个人设计:
            首先根据需求我会添加一张签到记录表, 重点来了,这张表须要把用户惟一标识字段(ID,Token)和签到日期字段添加为惟一约束,或者惟一索引,这样就能够 防止并发的时候插入重复用户的签到记录。
            而后再程序代码逻辑里,先执行签到数据的添加(这里能够防止并发),添加成功后再进行积分的添加,这样就能够防止重复的添加积分了。  
            最后我仍是建议全部的数据操做都写在一个sql事务里面,  这样在添加失败,或者编辑用户积分失败的时候能够回滚数据。

-------------------------------------------[我只是美丽的分割线]-------------------------------------------
       
如例子2(事务+经过更新锁 防止并发致使数据错乱 或者事物+Update的锁表机制)
         需求点:
            【抽奖功能】
              抽奖一次消耗一个积分
              抽奖中奖后编辑剩余奖品总数
              剩余奖品总数为0,或者用户积分为0的时候没法进行抽奖
              
         已知表 :
               用户表,包含积分字段
               奖品表,包含奖品剩余数量字段
          高并发意淫分析(属于开发前的猜想):
                在高并发的状况下,会致使用户参与抽奖的时候积分被扣除,而奖品实际上已经被抽完了
         个人设计:
                在事物里,经过WITH (UPDLOCK) 锁住商品表,或者Update 表的奖品剩余数量和最后编辑时间字段,来把数据行锁住,而后进行用户积分的消耗,都完成后提交事物,失败就回滚。
                这样就能够保证,只有可能存在一个操做在操做这件商品的数量,只有等到这个操做事物提交后,其余的操做这个商品行的事物才会继续执行。
                

-------------------------------------------[我只是美丽的分割线]-------------------------------------------node

 
如例子3(经过程序代码防止包并发下的数据错乱问题)
          需求点:
                【缓存数据到cache里】,
                当缓存不存在的时候,从数据库中获取并保存在cache里,若是存在从cache里获取,天天10点必须更新一次,其余时间点缓存两个小时更新一次
                到10点的时候,凡是打开页面的用户会自动刷新页面
         问题点:
                这里有个逻辑用户触发缓存的更新,用户刷新页面,当缓存存在的时候,会取到最后一次缓存更新时间,若是当前时间大于十点,而且最后缓存时间是10点前,则会从数据库中从新获取数据保存到cache中。
               还有客户端页面会在10点时候用js发起页面的刷新,就是由于有这样的逻辑,致使10点的时候有不少并发请求同时过来,而后就会致使不少的sql查询操做,理想的逻辑是,只有一个请求会去数据库获取,其余都是从缓存中获取数据。(由于这个sql查询很耗服务器性能,因此致使在10点的时候,忽然间数据库服务器压力暴增)
         解决问题:
                C#经过 (锁)lock,在从数据读取到缓存的那段代码前面加上锁,这样在并发的状况下只会有一个请求是从数据库里获取数据,其余都是从缓存中获取。
                

-------------------------------------------[我只是美丽的分割线]-------------------------------------------
2,访问量大的数据统计接口:
   需求:
     用户行为数据统计接口,用来记录商品展现次数,用户经过点击图片,或者连接,或者其余方式进入到商品详情的行为次数
   问题点:
     这接口是给前端ajax使用,访问量会很大,一页面展现的时候就会有几十件商品的展现,滚动条滚到到页面显示商品的时候就会请求接口进行展现数据的统计,每次翻页又会加载几十件
   意淫分析:
     设想若是同时有1W个用户同时在线访问页面,一个次拉动滚动条屏幕页面展现10件商品,这样就会有10W个请求过来,服务端须要把请求数据入库。在实际线上环境可能还会超过这个请求量,若是不通过进行高并发设计处理,服务器分分钟给跪了。
   解决问题:
     咱们经过nodejs写了一个数据处理接口,把统计数据先存到redis的list里。(使用nodejs写接口的好处是,nodejs使用单线程异步事件机制,高并发处理能力强,不会由于数据逻辑处理问题致使服务器资源被占用而致使服务器宕机)
     而后再使用nodejs写了一个脚本,脚本功能就是从redis里出列数据保存到mysql数据库中。这个脚本会一直运行,当redis没有数据须要同步到数据库中的时候,sleep,让在进行数据同步操做
 
-------------------------------------------[我只是美丽的分割线]-------------------------------------------
 
3,高并发的下的服务器压力均衡,合理站点架设,DB部署
    如下我所知道的:    
        1,服务器代理nginx,作服务器的均衡负载,把压力均衡到多台服务器
        2,部署redis服务器,或者mongodb服务器,把一些经常使用的查询数据,而且不会常常的变化的数据保存到其余nosql DB服务器中,来减小数据库服务器的压力,加快数据的响应速度。
        3,数据缓存,Cache
        4,JS脚本合理控制请求,如,防止用户重复点击致使的ajax多余的请求,等等。
        5,在高并发接口的设计中可使用具备高并发能力的编程语言去开发,如:nodejs 作web接口
        6,服务器部署,图片服务器分离,静态文件走CDN
 
4,并发测试神器推荐:
         Apache JMeter
        Microsoft Web Application Stress Tool 
        (若是还有更好的工具求推荐,简单易用)
相关文章
相关标签/搜索