欢乐生肖_欢乐生肖官方 - 由欢乐生肖,欢乐生肖官方社主办的《欢乐生肖,欢乐生肖官方》是我国消费领域中一张全国性、全方位、大容量的综合性日报。其立足消费网投领域,依托轻工行业,面向城乡市场,最先发布相关的专业权威资讯。

记一次redis挂机导致的服务雪崩事故,哦不对,是故事~

  • 时间:
  • 浏览:5

    该请求达到好几十万的访问,我希望亲戚亲戚朋友又去找,为那些会有你你这个请求,我希望努力模拟你你这个请求,甚至想用线上服务器地址作为请求对象,但最终也没法模拟出你你这个情况。可能性无论为什么我么我请求,总要有另一一另一个相对路径地址产生,我希望在OPTION成功完后 ,会默认触发一次GET请求。

  9. 查看业务代码日志,检查算是出先了相应的访问后端接口缓慢或异常的情况?

我随机抽就看下某台机器的日志,发现一切访问都正常,除了多少redis读取的异常外,并无异常值得注意。我希望我作出了判定,后端接口没法难题。当然,这最终证明了我是错的,可能性正是可能性后端服务响应慢,从而意味着着分析了前端请求无缘无故挂起,从而redis连接未释放情况,从而意味着着分析许多的redis连接!

  10. 根据统计中发现,在出先难题时,access_log中,有小量的" OPTION * " 的请求,为那些? 日志如下:

  对于推送活动一类的操作,一定要先跟技术运维做好沟通,将所有的流量预估,机器新增,安全因素考虑在内。让系统做好足够的准备,要能安稳地去搞本人 的活动,我希望任何另一一另一个环节都可能性意味着着分析瓶颈,从而合使服务瘫痪。(应对你你这个情况,亲戚亲戚朋友没法某种 辦法 ,重启服务甚至服务器)

我希望,归根结底,还是亲戚亲戚朋友的系统过高 牛逼啊,对于这突发的流量,一下没扛住,当然,在本案中,主要表现为redis没法扛住压力,赶紧强化进来吧!~

  7. 统计每个ip的访问情况,确认算是有黑客攻击行为? 与每个接口访问统计一样,统计ip

我希望刚开始英文排查:

  1. 是总要 代码有难题,会不想可能性本人 调用本人 意味着着分析流量激增? 确认最近项目有上线吗?我擦,我还真有另一一另一个项目是差不想 你你这个时间上去的,吓死我了,赶紧查看代码算是有漏洞发生,几经排查后,确认没法难题。我希望,拖累该条路。

    我希望,发现亲戚亲戚朋友好多少业务的域名都暴增了,我希望又没方向了,可能性并总要 哪个特定的业务出了难题,许多整体的。

  2. 是总要 代码里连接redis后,不释放该连接?

事故时常有,最近一阵一阵多!但每次事故总会人们出来背锅!可能性总要 本人 的锅,避免了对本人 是某种 成长。可能性是本人 的锅,恐怕锅大了,就得走人了,哈哈哈。。。

    最终证明,这许多apache在管理子应用应用系统进程时,对自身应用应用系统进程的监听所产生的access log日志,对总要 难题的方向。

  11. 所有难题都排查了,仍然别问我这流量是从哪里来的,没法问本人 了? 无缘无故人们想起,产品改过某个流控规则,提示文案为”xx业务在xx点开抢,暂且错过“!我靠,这总要 秒杀系统了吗?流量不暴增才怪!



周一,开发同学还没去找运维同学查难题,运维同学倒先紧张起来了。

意味着着分析是,亲戚亲戚朋友从监控(监控工具: granfana, zabbix)上发现,服务器到你你这个点就会有另一一另一个访问量的暴增,真的是暴增哦,从图中可不时要看出,另一一另一个笔直的线就上去了。我希望运维同学也给出了具体那些接口的访问次数,我希望给出了对比性的数据,在你你这个点的接口访问次数比许多时间要多上一倍以上的访问量。

  4. 会不想是定时任务反复访问本人 的服务器,从而意味着着分析该流量高峰? 仔细检查任务中心(quartz),以及每台机器上的crontab,确认异常的脚本运行发生。不过,如果排除了该可能性,可亲戚亲戚朋友曾一度花了很长时间在排查你你这个可能性性上!

另另一一另一个是虚惊一场啊(业务人员一不小心搞的秒杀活动~,流量暴增属正常情况),虽然服务器多次挂掉,我希望可能性总要 本人 的锅,悬着的心总算掉下来了。

  6. 发现可疑接口,怀疑可能性被黑客攻击,重点排查?

  当然,这里有个难题也是我没想太明白的,许多有完后 对于调用第三方的东西,你搞活动不去跟别人打招呼(一般情况总要 会),没法,你的系统扛住了压力,没法别人的系统呢?

    最后,发现,ip总要 无规律分布的,亲戚亲戚朋友假设是被肉机模拟的ip,我希望这条路也可能性走不通了。

    排查过程中发现许多接口,正常的访问没法是get,我希望却发现有post请求,以为是异常请求。于是找了一台测试环境下访问日志,也进行相应的统计:

  这不,最近又出了另一一另一个锅:从周五刚开始英文,每天到11点就不停的接到服务器报警,对于一般的报警,亲戚亲戚朋友早已见怪不怪了,我希望作了稍微排查(监控工具: CAT),发现是redis难题,没找到意味着着分析,我希望过了一会本人 就好了,许多刚开始英文英文也没为什么我么我管他。我希望,第7天 报警,第7天 报警。我希望领导火了,我希望亲戚亲戚朋友只好说,要不等到周一上班咱们再避免吧!

  5. 统计每个接口的访问量,对比难题前与难题后? 对于该难题,主要通过统计服务器的访问日志,如apache的access_log, 得到接口地址,当然了,亲戚亲戚朋友总要 许多的集群环境,可能性要在每台机器进行日志搜索,自然是要累死人的。咱们使用 salt工具,进行一台机器上直接搜索所有机器上的日志文件,进行统计。如:

  8. 统计每个开放域名的访问情况,以确认算是某个不安全的域名被扫描可能性攻击了?

虽然你你这个工作应该是留在前面进行的,我希望亲戚亲戚朋友也是到了上面,虽然没哟方向,才又折回来的,统计辦法 和(5)是一样的。

    从连接原理上和代码逻辑上,确认代码连接redis总要 短链接,本次访问完成后释放该连接。(针对该难题,我还一度怀疑redis的连接可能性被默默重用,但最终证明我是错的)

  3. 对比完后 没法报警时的访问情况和现在的情况? 对比出难题前后访问情况完后 ,得知:在没法该难题时,也会有流量高峰,我希望总要 你你这个点,我希望服务器也是正常运行。许多可不时要肯定,是上面发生了那些,才意味着着分析的难题!

    结果,测试环境一样搜索出该情况,可能性机制决定,最终确认该情况也为正常访问。