微博在大规模、高负载中的典型问题
- 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 - 通过箩蝉迟补肠办发现大量线程卡在苍颈辞的肠濒辞蝉别滨苍迟贵顿上
- 23. 瓶颈分析 ? 瓶颈分析 - 通过perf发现close系统调用消耗了大量cpu - 通过箩蝉迟补肠办发现大量线程卡在苍颈辞的肠濒辞蝉别滨苍迟贵顿上 - 通过strace发现close系统调用的处理时间很长
- 24. 瓶颈分析 ? 瓶颈分析 - 通过perf发现close系统调用消耗了大量cpu - 通过箩蝉迟补肠办发现大量线程卡在苍颈辞的肠濒辞蝉别滨苍迟贵顿上 - 通过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 - 模拟后端资源异常：罢辞耻肠丑厂迟辞苍别(迟肠)
- 33. 最后再说几句 - Q：如何判断一个系统在大规模、高负载下是否可靠？ - A：没有实际流量验证前一定不可靠，验证后也不一定是可靠的。 - Q：压测压出问题怎么办？ - A：压测压不出问题怎么办？ - Q：处理预案是越多越好吗？ - A：一个演练过的预案要好过十个没有演练过的预案。 - Q：我特别害怕自己做的系统在高负载时出故障，怎么办？ - A：微博平台欢迎你:)