Recommended
More Related Content
Viewers also liked
Viewers also liked (11)
Similar to 微博在大规模、高负载中的典型问题
Similar to 微博在大规模、高负载中的典型问题 (20)
微博在大规模、高负载中的典型问题
- 2. • 有哪些问题 • 如何排查 • 如何预防
- 3. 关于微博和微博平台 app后端 web后端 开放平台 微博平台 ⼿手机客户端 weibo.com 第三⽅方应⽤用展现 适配 服务
- 4. 关于大规模、高负载 • 一些数据 - 8亿注册用户 - 8000万+DAU - 1.75亿MAU • 典型场景 - 固定活动 • 吐槽春晚 • 让红包飞 - 突发事件 • #马航370# • #周一见# • 《我错了》
- 5. 关于问题 功能问题 • 发不出微博 • 未读数不准 • 500/502/503 • ……
- 6. 关于问题 性能问题 • 刷微博慢 • 提醒延迟 • 接⼝口响应时间⻓长 • ……
- 10. 案例二：功能异常导致性能下降 • 背景： - docker@春晚红包 - 应对极端流量，应用docker进行快 速服务调度 • 现象： - SocketTimeout - Connection Refuse • 原因： - nat方式组网时，底层基于iptables - iptables底层基于netfilter内核模块 - Netfilter模块保持65536个链接做 NAT转换 A B C
- 11. 典型问题的特点 • 出现场景 - 访问量量级增加 - 引入新组件 • 问题表现 - 一般表现为应用崩溃、服务不可 用或系统雪崩等 • 原因排查 - 量变到质变，低负载经验不适用 - 问题往往牵扯多个领域 为什么我不知道？
- 12. • 有哪些问题 • 如何排查 • 如何预防
- 13. 监控 • Dashboard - 基于graphite - 集中展示 - 定量分析 • Trace - 追踪链路，显示请求调用链 - 分析节点异常：平均值、历史数据
- 14. 日志 • 信息要完整 - 业务日志：包含关键路径与异常 - 性能日志：性能统计与分步耗时 - 容器日志、系统日志也很重要 • gc log、/var/log • 分维度过滤 - 时间：出问题的时间点 - 请求：uid、requestid - 级别：WARN/ERROR • 集中检索 - ELK/agent(jpool) - 平衡效率和成本
- 15. 查看现场
- 16. 查看现场 • 快照分析 - 功能：观察程序当前的状态 - 场景：程序当前处于整体异常状态 - 举例：gdb、Xmap、mat、jstack • 调用分析 - 功能：观察调用和调用栈 - 场景：请求出错、请求慢、偶发错误 - 举例：btrace、Xtrace • 聚合分析 - 功能：按某些维度采样、聚合和对比数据 - 场景：查找性能问题 - 举例：perf、Xstat、Xtop
- 17. 分析原因 • 问题经常隐藏在： - 应用：死锁、内存溢出、依赖资源 - 系统：jvm、kernel、tcp - 硬件：硬件故障、网络 • 联合排查 - 开发 / 运维 / dba / 网络 / 系统 / 硬件
- 18. 案例：春晚演练时服务出现异常 • 背景 - 演练方案：跨机房迁移用户请求 - 逐渐迁移流量的过程中，web服 务突然僵死，大量返回503 - 接口吞吐量低于理论值2-3倍 nginx(机房1) web rpc1 cache mysql rpc2 web rpc1 cache mysql rpc2 nginx(机房2) web 1:30% 1:35% 1:40% 1:45% QPS$
- 19. 定位问题 • 监控和日志 - 异常时的现象 • rpc1服务大量超时，处理队列堵塞 • rpc1服务器CPU idle普遍降低至10% • 后端资源没有波动 rpc接⼝口响应时间 nginx(机房1) rpc1 cache mysql rpc2 web rpc1 cache mysql rpc2
- 20. 重现问题 • 重现现场 - 直接压测没有重现问题 - 通过tcp copy引流线上流量，问题重现
- 22. 瓶颈分析 • 瓶颈分析 - 通过perf发现close系统调用消耗了大量cpu - 通过jstack发现大量线程卡在nio的closeIntFD上
- 23. 瓶颈分析 • 瓶颈分析 - 通过perf发现close系统调用消耗了大量cpu - 通过jstack发现大量线程卡在nio的closeIntFD上 - 通过strace发现close系统调用的处理时间很长
- 24. 瓶颈分析 • 瓶颈分析 - 通过perf发现close系统调用消耗了大量cpu - 通过jstack发现大量线程卡在nio的closeIntFD上 - 通过strace发现close系统调用的处理时间很长 - 通过对比压测发现旧版内核频繁调用close时有性能问 题
- 25. 解决问题 • 解决方式 - 升级内核 • 确保问题被修复 - 开发环境验证 - 测试环境验证 - 线上环境验证 • 确保没有引入新的问题 - 灰度上线，观察服务状态 • 功能无异常 • 性能未下降 解 决
- 26. tips：当心解决问题的陷阱！ • 案例：追查性能问题 - 现象：接口突然开始超时 - 原因：访问量突增，大量读取 静态内容缓存，mc出现带宽 瓶颈 - 解决：增加本地缓存 - 结果：压测时性能仍然有问题 web服务器CPU瓶颈 顺便加个统计 1:30% 1:35% 1:40% 1:45% CPU
- 28. • 有哪些问题 • 如何排查 • 如何预防
- 29. 高可用架构设计 • 服务隔离 - 按部署隔离 • 分机房部署 • 核心服务独立部署 • 服务独立化部署 - 按调用隔离 • 异步队列 • 快速失败
- 30. 可靠的系统实现 - 耦合方式：同步 / 异步 /丢弃 调⽤用⽅方 服务⽅方 thread buffer queue thread buffer queue 服务⽅方
- 31. 可靠的系统实现 - 耦合方式：同步 / 异步 /丢弃 - 异常处理的异常处理：不要让事情变得更糟
- 32. 压测与演练 • 真实流量压测 - 模拟实际请求模型：TCPCopy - 模拟后端资源异常：TouchStone(tc)
- 33. 最后再说几句 - Q：如何判断一个系统在大规模、高负载下是否可靠？ - A：没有实际流量验证前一定不可靠，验证后也不一定是可靠的。 - Q：压测压出问题怎么办？ - A：压测压不出问题怎么办？ - Q：处理预案是越多越好吗？ - A：一个演练过的预案要好过十个没有演练过的预案。 - Q：我特别害怕自己做的系统在高负载时出故障，怎么办？ - A：微博平台欢迎你:)