• liveshow回顾


      在2017年8月14号的一天接到一个即看即买的项目,大致功能如下

      1.现场走秀直播同步到H5页面

      2.实时显示直播间人数

      3.点赞并实时显示给用户

      4.在某个时间点,可以全体推送一些消息给所有用户

      5.推送的消息里面的商品可以点击购买,加入购物车。

      6.实时聊天,获取用户真实的昵称,头像(基于微信授权)

      7.保存聊天记录,用户在进来后显示最后十条聊天记录

      

      约定29号上线,当时准备采取用workman+mysql的方式来处理这些功能,大约有12个工作日来开发,但是其中因为中间穿插了一个另外的项目花去了四天时间,然后客户临时要求加个RSVP的功能花去一天,最后只剩下了7个工作日来开发这个这个项目,包括前端和后端的整合。因为客户希望在直播的时候推出他们的产品,所以不希望直播全屏,那样会使用户看不到商品,前端解决这个问题加上做完这些页面,总共花了三天时间,我只剩了四天时间。因为时间很紧迫,没有考虑这些设计的合理性,包括上线的峰值和并发都没有进行估算,结果出现了大家预想中的事情,服务器宕机。

      主要表现:

      1.上线10分钟左右,因为直播还没有接入,很多用户在公屏发言,而当时用户的昵称、头像都是保存在数据库的,需要从数据库读取,并且聊天记录要写入数据库。大量的I/O操作,导致mysql内存耗尽,直接mysql gone away了。

      2.在大约八点半左右的时候,一位明星的登场走秀,导致直播间人数暴增,在几分钟之内服务器就挂掉了,白屏了大约一分钟。

      处理方案:

      1.第一次数据库挂掉之后,及时的发现了原因,删除掉了聊天记录的写入之后重启了数据库

      2.在apache挂掉之后,查看服务器发现cpu达到96%,内存耗尽所以挂掉,赶紧重启

      在直播结束之后,我们向服务器公司要了一份当天直播时候的报告:

      

      

      

      

      通过上面图标我们可以发现问题,就是服务器过载了,主要两个原因

      1.实时聊天购物用的是workman,每进入一个人都会建立一个tcp连接,瞬间涌入的人太多导致连接池满载

      2.峰值很高,系统已经发生任务拥塞,Apache和Mysql同时连接内存开销太大,服务器配置是4G内存,4CPU,进程太多不够使用然后消耗系统内存导致服务挂掉

      

      当时服务器挂掉的原因固然是因为服务器配置不高的原因,但是工具选取不对也是很大的因素,后来想了解决方案:

      1 .增加服务器的配置(内存和CPU),或者搭建一个简单的负载均衡系统避免一台机器宕机,整个服务停掉

      2.瞬间涌入人太多的项目要在项目开始前估算峰值,选择服务器

      3.临时修改Apache的最大连接数,满足项目的要求

      4.数据存储改成两层数据存储,用nosql+mysql的方式,在半夜服务器活动少的时候同步数据

      第二天的时候赶紧花了半天的时候,将所有的操作从操作数据库改成了操作redis,redis可以支撑7-10W的并发,比数据库的性能要好很多,将所有的数据存入redis中,在直播的时候直接操作redis。等到直播结束或者服务器闲置的时候,定时执行脚本将数据同步至mysql,查询的时候先查缓存再查数据库。这样可以很大的避免数据库挂掉,服务器崩溃的情况。

      

      在改成redis存储之后,整个代码量减少了大约三分之二,并且redis的操作是原子性的,对于一些递增递减的操作支持很好,不像MYSQL一样,一旦递增递减update之后就会锁定表,阻塞后面的操作,导致mysql挂掉。

       

  • 相关阅读:
    小账本软件设计之数据库设计模式构建
    基于JMeter的Quick Easy FTP Server性能测试
    构建之法 -源代码管理
    小账本APP——软件项目风险管理及解决办法案例
    基于python的Splash基本使用和负载均衡配置
    MQ初窥门径【面试必看的Kafka和RocketMQ存储区别】
    Apollo源码搭建调试看一文就够
    log4j2异步日志解读(二)AsyncLogger
    Disruptor源码解读
    高性能队列disruptor为什么这么快?
  • 原文地址:https://www.cnblogs.com/lina520/p/7458386.html
Copyright © 2020-2023  润新知