转java 3年了，记一个最近的坑； 临近818，苏宁小店线上 app 搞了个秒杀活动，后台服务出现了异常。 活动是周五 10 点，收到了系统的告警短信，同事开始有人在公司豆芽（苏宁内部通信工具）反馈有部分用户下单失败； 在监控仪表盘上也可以看到访问量开始剧增，同时响应时间开始变长，中台价格系统开始报错，导致后面的接口系统报错。 去日志平台查看了价格系统接口的调用情况。我们可以看到接口响应时间是慢慢变慢的，最后开始出现了报错现象。去查看报错信息 Timeout 报错。 查看耗时过长接口的调用明细，可以看到价格系统的接口已经开始出现了积压，后面的接口需要等待前面的接口处理完成了才会处理，所以接口的耗时也不断的增长。查看了下代码逻辑只是从 Redis 里读取数据，应该几毫秒就处理的事情怎么会这么慢导致了积压呢？难道 Redis 出现了问题？ 还真是，原来价格系统是和主数据系统共用的一套 Redis [两组（一主两从）] 图片贴出的是其中两台主库的压力分别是 72w 和 62w 。内存使用率也是居高不下。 给价格系统独立申请了两组 Redis，晚上通宵发布（苦逼啊）。 当晚升级后，做了次压测，价格接口可以支持峰值 70w 次/分钟的调用，这周五的活动从仪表盘上也是看到轻轻松松无压力了。（0ms 是因为仪表板精确到ms 四舍五入了） 总结 1.没有按活动人数评估系统压力做相应的压力测试，导致生成事故。做活动时候产品和运营应该预估好活动人数和开发沟通，开发应该对目前的系统能否支持这样的流量有一个认知不能想当然，如果不确定可以联系测试做压力测试。很显然这次的事故并没有做相关的工作。 2.没有降级方案对服务进行熔断或降级，导致前台系统直接报错。 如果你看到了这里，那么请长按二维码，关注我，一起成长！ 好文要顶 关注我 收藏该文 nivanafish 关注 - 10 粉丝 - 3 +加关注 0 0 « 上一篇：Javascript模块化编程（二）：AMD规范 posted @ 2018-08-27 15:25 nivanafish 阅读(96) 评论(0) 编辑 收藏 刷新评论刷新页面返回顶部 注册用户登录后才能发表评论，请 登录 或 注册，访问网站首页。 【推荐】超50万VC++源码: 大型组态工控、电力仿真CAD与GIS源码库！ 【推荐】企业SaaS应用开发实战，快速构建企业运营/运维系统 【推荐】ActiveReports 报表控件，全面满足 .NET开发需求 qcloud0814 最新IT新闻: · 微软重发KB4100347更新 导致设备无法启动 · 腾讯投资三个失误 · 警告！中国90%AI初创企业将在两年内落败出局 · 光有动量被证实！未来可用光的力量驱动星际飞船 · 盖茨、谷歌看中的“重口味”科技，正挑战无创测癌 » 更多新闻... 华为CH0822 最新知识库文章: · 如何招到一个靠谱的程序员 · 一个故事看懂“区块链” · 被踢出去的用户 · 成为一个有目标的学习者 · 历史转折中的“杭派工程师” » 更多知识库文章... 搜索 阅读排行榜 1. Node.js 学习笔记(一)(260) 2. Node.js 学习笔记(二)(229) 3. GItHub学习笔记(223) 4. Javascript模块化编程（二）：AMD规范(125) 5. Javascript模块化编程（一）：模块的写法(121) 评论排行榜 1. Node.js 学习笔记https://www.cnblogs.com/fishlynn/p/9542477.html