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

  事故时常有,最近特别多!但每次事故总会有人出来背锅!如果不是自己的锅,解决了对自己是一种成长,如果是自己的锅,恐怕锅大了,就得走人了,哈哈哈。。。

  这不,最近又出了一个锅:从周五开始,每天到11点就不停的接到服务器报警,对于一般的报警,我们早已见怪不怪了,然后作了稍微排查(监控工具: CAT),发现是redis问题,没找到原因,然后过了一会自己就好了,所以刚开始也没怎么管他。然后,第二天报警,第三天报警,领导火了,然后只好说,要不等到周一上班咱们再解决吧!


  周一,开发同学还没去找运维同学查问题,运维同学倒先紧张起来了。
  原因是,他们从监控(监控工具: granfana, zabbix)上发现,服务器到这个点就会有一个访问量的暴增,真的是暴增哦,从图中可以看出,一个笔直的线就上去了。然后运维同学也给出了具体哪些接口的访问次数,然后给出了对比性的数据,在这个点的接口访问次数比其他时间要多上一倍以上的访问量。

  然后开始排查:
  1. 是不是代码有问题?
    确认最近项目有上线吗?我擦,我还真有一个项目是差不多这个时间上去的,吓死我了,赶紧查看代码是否有漏洞存在,几经排查后,确认没有问题。然后,抛弃该条路。


  2. 是不是代码里连接redis后,不释放该连接?
    从连接原理上和代码逻辑上,确认代码连接redis都是短链接,本次访问完成后释放该连接。(针对该问题,我还一度怀疑redis的连接可能被默默重用,但最终证明我是错的)
  3. 对比之前没有报警时的访问情况和现在的情况?
    对比之后,在没有该问题时,也会有流量高峰,但是不是这个点,而且服务器也是正常运行。所以可以肯定,是后面发生了什么,才导致的问题!
  4. 会不会是定时任务反复访问自己的服务器,从而导致该流量高峰?
    仔细检查任务中心(quartz),以及每台机器上的crontab,确认异常的脚本发生。不过,后来,我们曾一度花了很长时间在排查这个可能性上!
  5. 统计每个接口的访问量,对比问题前与问题后?
    对于该问题,主要通过统计服务器的访问日志,如apache的access_log, 得到接口地址,当然了,我们都是很多的集群环境,如果要在每台机器进行日志搜索,自然是要累死人的。咱们使用 salt工具,进行一台机器上直接搜索所有机器上的日志文件,进行统计。如:

salt ‘cc*.cc‘ cmd.run "cat access_log | awk -F ‘ ‘ ‘{print $9}‘ | sort | uniq -c" > 1.log # 该处的双引号不一定能用哦

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

    再现某些接口,正常的访问只能是get,但是去发现有post请求,以为是异常请求,于是找了一台测试环境下访问日志,也进行相应的统计:

grep -E ‘POST /x/cc/public/notice |POST /x/cc/Public/init ‘ access_log | less

    结果,一样搜索出该情况,由于机制决定,最终确认该情况也为正常访问。

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

cat access_log | awk -F ‘ ‘ ‘{print $2}‘ | sort | uniq -c > 1.log

    最后,发现,ip都是无规律分布的,我们假设是被肉机模拟的ip,但是这条路也已经走不通了。

  8. 统计每个开放域名的访问情况,以确认是否是某个不安全的域名被扫描或者攻击了?
    其实这个工作应该是留在前面进行的,但是我们也是到了后面,实在没了方向,才又折回来的,统计方法和(5)是一样的。

cat access_log | awk -F ‘ ‘ ‘{print $2}‘ | sort | uniq -c > 1.log

    然后,发现我们好几个业务的域名都暴增了,然后又没方向了,因为并不是哪个特定的业务出了问题,而是整体的。

  9. 查看业务日志代码,检查是否出现了相应的访问后端接口缓慢或异常的情况?
    我随机抽看了下某台机器的日志,发现一切访问都正常,除了几个redis读取的异常外,然后我作出了判定,后端接口没有问题。当然,这最终证明了我是错的,因为正是由于后端服务响应慢,从而导致了前端请求一直挂起,从而redis连接未释放情况,从而导致许多的redis连接!
  10. 根据统计中发现,在出现问题,access_log中,有大概的" OPTION * " 的请求,为什么?
    日志如下:

0 127.0.0.1 cc.c.com - - [24/Jun/2017:21:21:47 +0800] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.3 (CentOS) (internal dummy connection)" 85 202 "-"

    该请求达到好几十万的访问,然后我们又去找,为什么会有这种请求,然后努力模拟这种请求,甚至想用线服务器地址作为请求对象,最终也没有模拟出这种情况,因为无论怎么请求,都会有一个相对路径地址产生,而且在OPTION成功之后,会默认触发一次GET请求。

    最终证明,这只是apache在管理子进程时,对自身进程的监听所产生的access log日志,对不是问题的方向。
  11. 所有问题都排查了,仍然不知道这流量是从哪里来的,只能问其他人了?
    突然有人想起,产品改过某个流控规则,提示文案为”xx业务在xx点开抢,不要错过“!我靠,这不是秒杀系统了吗?流量不暴增才怪!
  12. 终于找到问题了,然后再是拉上架构师,去理论!!!

  原来是虚惊一场啊(业务人员一不小心搞的秒杀活动~,流量暴增属正常情况),虽然服务器多次挂掉,但是由于不是自己的锅,悬着的心总算掉下来了。

  但是,归根结底,还是我们的系统不够牛逼啊,对于这突发的流量,一下没扛住,当然,在本案中,主要表现为redis没有扛住压力,赶紧强化进来吧!~

  对于推送活动一类的操作,一定要先跟技术运维做好沟通,将所有的流量预估,机器新增,安全因素考虑在内。让系统做好足够的准备,才能安稳地去搞自己的活动,否则任何一个环节都可能导致瓶颈,从而合使服务瘫痪。(应对这种情况,我们只有一种办法,重启服务甚至服务器)

  当然,这里有个问题也是我没想太明白的,就是有时候对于调用第三方的东西,你搞活动不去跟别人打招呼(一般情况都不会),那么,你的系统扛住了压力,那么别人的系统呢?

时间: 2024-10-08 21:28:47

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

我所经历的一次Dubbo服务雪崩,这是一个漫长的故事

在一个处理用户点击广告的高并发服务上找到了问题.看到服务打印的日记后我完全蒙了,全是jedis读超时,Read time out!一直用的是亚马逊的Redis服务,很难想象Jedis会读超时. 看了服务的负载均衡统计,发现并发增长了一倍,从每分钟3到4万的请求数,增长到8.6万,很显然,是并发翻倍导致的服务雪崩. 服务的部署: 处理广告点击的服务:2台2核8g的实例,每台部署一个节点(服务).下文统称服务A 规则匹配服务(Rpc远程调用服务提供者):2个节点,2台2核4g实例.下文统称服务B 还

NoSQL初探之人人都爱Redis:(3)使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时呢,也使响应延迟加剧.这也说明

Spring Cloud微服务架构实现+Guava缓存+redis+数据库设计+微服务原理改造房产销售

Spring Cloud微服务架构实现+Guava缓存+redis+数据库设计+微服务原理改造房产销售 一.分布式服务框架的发展 1.1 第一代服务框架 代表:Dubbo(Java).Orleans(.Net)等 特点:和语言绑定紧密 1.2 第二代服务框架 代表:Spring Cloud等 现状:适合混合式开发(例如借助Steeltoe OSS可以让ASP.Net Core与Spring Cloud集成),正值当年 1.3 第三代服务框架 代表:Service Mesh(服务网格) => 例如

因Window服务器自动更新并重启导致WebSphere服务故障一例

最近公司购买了两台Windows Server 2008 R2服务器用于提供提供Web服务,A机器安装了IHS+DM+WAS8.5集群,B机器安装了Oracle11gR2用于数据存储,两台机器均可连接互联网. 服务部署头天晚上部署,测试没有任何问题,早上用户打电话反馈无法正常访问站点,远程登录后发现IHS+DM服务正常,但是集群没有启动,查看任务管理器发现没有nodeagent和集群中server的进程,手动启动nodeagent后启动集群,两个Server正常启动,随后正常提供服务.当时怀疑服

Redis解决强制关闭Redis快照导致不能持久化错误

今天在使用composer添加Redis缓存的时候,运行Redis发生错误: 127.0.0.1:6379> set dachou dadachou (error) MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis

redis加入到windows服务命令

执行以下命令Redis-server.exe --service-install redis.windows.conf删除服务redis-server --service-uninstall开启服务redis-server --service-start停止服务redis-server --service-stop redis-server --service-install –service-name redisService1 –port 10001redis-server --servic

记一次存储故障导致数据库坏块处理过程

记一次存储故障导致数据库坏块处理过程 线上架构说明:     IBM DS4800存储一套     P560小机HA架构一套     两个数据库资源组平时run在HA架构中的任意一台中,资源组全部使用共享存储 问题描述: 由于存储在数据库运行过程中发生了异常宕机,导致两个库存在不同程度的坏块 错误信息及解决过程 数据库A: A:root:/db2dumph/istclhis > 2016-04-09-04.26.10.787138   Instance:istclhis   Node:000 P

使用ElasticSearch+LogStash+Kibana+Redis搭建日志管理服务

1.使用ElasticSearch+LogStash+Kibana+Redis搭建日志管理服务 http://www.tuicool.com/articles/BFzye2 2.ElasticSearch+LogStash+Kibana+Redis日志服务的高可用方案 http://www.tuicool.com/articles/EVzEZzn 3.示例 开源实时日志分析ELK平台部署 http://baidu.blog.51cto.com/71938/1676798?utm_source=t

时间不对导致vSAN服务无法启动

今天在做vSAN实验的时候发现一个问题,如果ESXi主机的时间不对(与当前时间相差太远)会导致ESXi主机的vSAN服务无法配置和启动.[说明]在安装ESXi 6.x版本时,为ESXi主机配置了默认的证书,证书的有效期为5年(以安装时主机的时间为基准).在大多数的情况下,为ESXi主机调整为正确的时候即可启动vSAN服务.如果调整为正确的时间后仍然不能启动,此时要查看ESXi主机"证书"时间,如果为主机颁发的证书的截止时间已经早于当前时间,需要重新为ESXi主机重新申请证书才能正常使用