Online DDL 的核心目标是：执行 ALTER 时不阻塞业务读写。理解它要抓住三个阶段和三种锁。一、ALGORITHM 的三种模式· ALGORITHM=COPY：建临时表 → 逐行拷贝 → 改名。全程锁写，大表极慢，5.5 及之前只有这种方式；· ALGORITHM=INPLACE：在原表上做变更，不拷贝整表（部分操作仍需重建），允许并发 DML；· ALGORITHM=INSTANT：只改数据字典元数据，秒级完成，8.0 引入并持续扩展支持范围。可以用 ALTER TABLE t ... , ALGORITHM=INPLACE, LOCK=NONE 强制指定，不支持时会直接报错而不是静默降级——这点很实用，能提前发现「以为不锁表其实锁了」。二、Online DDL 的三个阶段1. Prepare：持有 EXCLUSIVE MDL（元数据锁）的短暂窗口，检查条件、准备日志空间；2. Execute：真正执行变更，期间降级为 SHARED_UPGRADABLE 或允许并发 DML，同时把期间的 DML 记录到 online log（row log）里；3. Commit：再次短暂持有 EXCLUSIVE MDL，把 online log 里的变更应用上去，提交元数据。关键点：两个 EXCLUSIVE 窗口都很短，但如果此时有长事务持有 MDL，DDL 会排队等待，而排队中的 DDL 又会阻塞后续所有请求——这就是「Online DDL 把库拖死」的经典原因。上线前务必先查 information_schema.INNODB_TRX 和 performance_schema.metadata_locks。三、哪些操作可以不锁表（INPLACE / INSTANT）常见支持 INPLACE + 并发 DML 的：· 添加/删除二级索引（最典型，8.0 还支持 INSTANT 加列）；· 添加/删除外键约束（需 foreign_key_checks=0 更快）；· 修改列的 NULL / NOT NULL（需配合 strict 模式）；· 修改 VARCHAR 长度（在不超过 255 字节边界内可以 in-place，跨边界要重建）；· 重命名列/表（8.0 支持 INSTANT）；· 修改 AUTO_INCREMENT 值、修改注释、设置默认值（8.0 INSTANT）。通常必须 COPY（锁写）的：· 修改列类型（如 INT → BIGINT、VARCHAR → TEXT）；· 修改字符集（CHARSET/Collation）；· 加/删主键（部分场景可以 in-place 重建）；· 修改 ROW_FORMAT；· 表的重建类操作（OPTIMIZE、FORCE）。四、大表 DDL 的工程实践即使是 INPLACE，也要考虑：· 磁盘与 IO：重建类操作会临时占用接近表大小的空间；· 主从延迟：DDL 在从库串行重放，大表可能延迟几分钟到几小时；· online log 大小：innodb_online_alter_log_max_size 太小会失败；· 替代方案：超大表用 gh-ost 或 pt-online-schema-change，通过影子表 + binlog 同步，把影响面控制住，还能限速、可暂停。五、一句话总结Online DDL 不是「完全不锁」，而是「把锁的窗口压到极短」；能不能不锁表取决于具体操作类型。上线前用 ALGORITHM=INPLACE, LOCK=NONE 试一次，报错就说明要走 gh-ost 这类方案了。

开发者成长中心是华为云开发者生态里做「任务 + 积分 + 权益」的模块，理解它的结构比记住入口更重要。一、它解决什么问题把分散在各个板块的行为（学课程、做实验、发文章、提建议、参赛）统一成可度量的「成长值」，再用积分兑换权益（代金券、认证考试机会等）。本质是一套行为激励系统。二、任务体系的三层周期· 每日（DAILY）：签到、发布文章、回答问题被采纳、提交建议。特点是每天刷新，是稳定的积分来源；· 每周（WEEKLY）：通过一项微认证、实践一个实验、参加开发者活动、参与赛事、建议被采纳/被实现。每周一刷新；· 每月/长期（MONTHLY/LIMIT）：赛事晋级、展览馆发布作品、实名认证（一次性）。注意「完成条件」的区别：有的是提交即算（提交建议），有的是审核通过才算（建议被采纳、文章审核），有的是他人行为触发（回答被采纳、建议被实现）。这决定了积分到账的快慢。三、积分怎么用积分可以在积分商城兑换代金券（10 元 / 20 元 / 50 元等档位）、认证考试机会等。兑换有库存和等级限制，部分商品需要实名认证。兑换是扣减式的，扣完总分会下降，但任务完成记录不受影响。四、几个实用经验1. 先看任务周期再安排：每日任务优先做（稳定 +30~+60），每周任务里「微认证 +200」和「展览馆 +200」性价比最高；2. 区分「已完成」和「已到账」：任务卡片显示「已完成」不等于积分已入账，比如微认证要求拿到证书（考试通过后 1 个自然日发证）才给分；3. 积分明细里能看到每笔流水（来源、分值、时间、变动后余额），对不上账时以流水为准；4. 连续签到有阶梯奖励，断签会重置，长期看每天 +10 也值得坚持；5. 建议类任务的审核周期通常是 1-2 个工作日预审，采纳与否由产品团队评估，不要指望当天到账。五、入口主入口是开发者中心的成长中心页面（developer.huaweicloud.cn/grow），任务卡片、积分明细、兑换记录都在这一页。学堂侧的微认证/实验任务会跳转到 edu.huaweicloud.cn，论坛侧任务跳转到 bbs.huaweicloud.cn。如果目标是攒积分换代金券，性价比排序大概是：每日任务（稳定）> 微认证/展览馆（单次高分）> 实验（每周 +50）> 赛事（周期长但分值高）。

这个问题要拆成两半回答：为什么同一个事务内多次查询结果一致，以及 Read View 到底在什么时候创建。一、结论先说RR（可重复读）下，Read View 在事务中第一次执行快照读（普通 SELECT）时创建，并且整个事务复用这一个 Read View，直到事务结束。这就是「同一事务内多次查询看到的数据一致」的根本原因。二、Read View 里存了什么它不是「数据的副本」，而是一组可见性判断依据：· m_ids：创建时活跃（未提交）的事务 ID 列表；· min_trx_id：m_ids 中的最小值；· max_trx_id：创建时系统应分配的下一个事务 ID；· creator_trx_id：创建这个 Read View 的事务自己的 ID。三、可见性判断规则读到一行数据时，看该行对应 undo 版本的事务 ID（trx_id）：1. trx_id == creator_trx_id → 自己改的，可见；2. trx_id min_trx_id → 这个事务在 Read View 创建前就提交了，可见；3. trx_id >= max_trx_id → 创建后才启动的事务，不可见；4. min_trx_id = trx_id max_trx_id → 看是否在 m_ids 里：在（还没提交）则不可见，不在（已提交）则可见。不可见时，就顺着 undo log 的版本链往前找，直到找到一个可见版本。这就是 MVCC 的实现方式——不加锁，靠版本链 + Read View 做快照读。四、RR 与 RC 的核心差别· RR：Read View 只在第一次快照读时创建，之后复用 → 多次查询结果一致（可重复读）；· RC（读已提交）：每次快照读都重新创建一个 Read View → 每次都能看到最新已提交的数据（不可重复读）。所以「Read View 什么时候创建」这个问题的答案，恰好就是 RR 和 RC 的分界线。五、几个必须知道的例外1. 快照读 vs 当前读：SELECT ... FOR UPDATE、LOCK IN SHARE MODE、UPDATE、DELETE 都是当前读，读最新已提交版本并加锁，不走 Read View；2. RR 不能完全避免幻读：快照读靠 MVCC 看不到新插入的行，但当前读（如 UPDATE 后跟 SELECT）可能看到，InnoDB 用 Next-Key Lock 在加锁读时解决；3. 事务 ID 的分配时机：事务 ID 是在事务第一次写操作时分配的，只读事务可能不分配（取决于版本），所以「第一次 SELECT 时创建 Read View」里的 trx_id 规则对只读事务要特殊看待；4. 长事务的代价：Read View 长期不释放，会导致 undo log 无法清理（purge 被阻塞），表空间膨胀。这是长事务最实际的危害，比锁等待更隐蔽。六、实践建议· 事务尽量短，避免在一个事务里做 RPC 或等待用户输入；· 需要读到最新数据时用当前读，别指望 RR 的快照读；· 监控 information_schema.INNODB_TRX 里运行时间过长的事务。

「部署 kimi 模型」通常有两种理解，路径完全不同，先分清再动手。一、只是要调用 Kimi 的能力 → 走 API，不要自己部署Moonshot 的 Kimi 系列是闭源商用模型，官方只提供 API，不提供权重下载。所以如果目标是「在自己的应用里用上 Kimi」，正确做法是：· 在 Moonshot 开放平台申请 API Key；· 用 OpenAI 兼容格式调用（base_url 指向 https://api.moonshot.cn/v1），现有基于 OpenAI SDK 的代码基本改两行就能跑；· 生产环境注意：Key 不要写进前端或仓库，走后端代理；做好超时与重试；按 token 计费，长上下文成本要预估。这条路不需要 GPU、不需要部署，是 90% 场景的答案。二、要私有化部署 → 只能选开源模型如果因为数据合规必须私有化，那 Kimi 本身没法部署，只能选能力接近的开源模型，常见选择：Qwen 系列、DeepSeek 系列、GLM 系列、Llama 系列。部署形态按规模分：· 单机 + vLLM / SGLang：最常用。vLLM 的 PagedAttention 对吞吐提升明显，支持 OpenAI 兼容接口，接入成本低；· 多机多卡 + 张量并行：模型大到单机放不下时用 tensor_parallel_size 跨卡切分；· 量化：INT8/AWQ/GPTQ 能把显存需求降到 FP16 的一半左右，代价是少量精度损失，先测业务指标再决定；· K8s 化：用 KServe / Ray Serve 做弹性伸缩，配合 HPA 按 QPS 扩副本。三、在华为云上的落地路径· ModelArts：适合做微调 + 部署一体，支持从 OBS 加载权重、一键部署成在线服务；· MaaS（模型即服务）：直接调用托管好的开源模型，省掉运维，适合快速验证；· ECS + GPU（如昇腾/GPU 实例）：自己装 vLLM，控制力最强，但要自己管驱动、CUDA/CANN 版本、显存碎片。四、部署时最常踩的坑· 显存估算不准：参数量 × 2 字节（FP16）+ KV cache，KV cache 常被忽略，长上下文时它可能比权重还大；· 只测单条延迟不测并发吞吐：vLLM 的价值在高并发，单条测试看不出差别；· 上下文长度设成模型上限：会显著增加 KV cache 占用，按业务实际需要设；· 忘了配 max_model_len 和 gpu_memory_utilization，导致启动就 OOM。五、给个决策建议如果只是产品里要用对话能力 → 直接调 API，别自建；如果数据不能出内网 → 选 Qwen/DeepSeek 这类开源模型 + vLLM 单机部署，先跑通再考虑扩容；如果是研究或需要微调 → ModelArts 或自建训练集群。

提交错了文件，能不能补救取决于两个因素：提交通道是否已关闭、该赛事是否允许多次提交。按这个顺序判断。一、先确认还能不能重新提交大多数华为云赛事的作品提交页在截止前支持覆盖提交——重新上传会以最后一次为准，页面上通常有「重新提交」「更新作品」按钮。先去「我的赛事 → 作品提交」看按钮是否还可用。如果还能点，直接重传正确文件，这是最快也最稳的路径。注意两点：· 有些赛事限制「每天 N 次」或「总共 N 次」提交，重传前先看规则里的次数限制；· 覆盖提交后建议在页面刷新一次，确认「已提交文件」列表里是新的文件名与大小，别只看提示语。二、通道已关闭怎么办截止后一般无法自助重传，可行的路径有三条：1. 赛事交流群/官方答疑：华为云赛事通常在赛事页有「交流群」入口（微信群或论坛版块）。把情况写清楚——参赛账号、队伍名、作品名、错误文件与正确文件的对比、提交时间截图，请组委会协助替换。这类请求在评审尚未开始时成功率较高。2. 赛事论坛发帖：在开发者大赛版块发帖并 @ 版主，附上工单号或群内沟通记录，便于官方留痕处理。3. 提工单：如果是平台故障导致上传错误（比如上传成功但内容被截断），走工单更合适，需要提供请求时间与页面截图。三、沟通时怎么写更容易被接受· 明确「不是要延期，只是替换文件」，降低对方顾虑；· 给出文件指纹（MD5 或 SHA256），让对方能确认替换的就是你指定的那一份；· 说明错误原因（选错文件 / 压缩包漏文件 / 版本搞混），不要含糊；· 一次性把材料给全，别来回补。四、以后怎么避免· 提交前把作品目录打包后在本地解压验证一遍，确认入口文件、README、依赖都在；· 命名带版本号与日期（如 project-v3-20261018.zip），避免 v2/v3 搞混；· 提交后立刻下载自己提交的文件核对一次，这一步能拦住 90% 的“传错了”；· 提前一天提交，把最后一天留给意外。如果这次确实没赶上，也别放弃：多数赛事有下一期，把这次的复盘写进仓库 README，下一期直接用。

内网访问 ELB 不通，按「链路从近到远」查，一般能定位到具体是哪一跳断的。下面按顺序给排查清单。一、先确认 ELB 有没有内网 IPELB 分公网型和私网型。如果创建的是公网型 ELB，它只有公网 IP，内网机器无法通过内网地址访问——这是最常见的误判。私网型 ELB 才有 VPC 内网 IP，且必须和客户端在同一个 VPC（或已打通的 VPC）里。查法：ELB 控制台看实例的「服务地址」，私网型会显示形如 192.168.x.x 的地址。二、VPC 与子网是否互通· 客户端和 ELB 是否同一 VPC？跨 VPC 需要对等连接或云连接，且两端路由表都要加路由；· 是否同一子网？不同子网默认互通（同 VPC 内），但要确认子网网段没有重叠；· 如果客户端在 IDC（通过专线/VPN 接入），检查专线网关的路由是否包含 ELB 所在子网网段。三、安全组与网络 ACL这是第二大高频原因：· ELB 自身的安全组要放通客户端网段访问监听端口；· 后端服务器（ECS）的安全组要放通「ELB 所在网段」访问业务端口——注意不是放通客户端网段，因为流量经过 ELB 后源地址会变成 ELB 的地址（除非开了透明传输）；· 子网的网络 ACL 是子网级兜底，默认全通，但如果被改过要一并检查（ACL 是无状态的，入站出站都要放）。四、后端健康检查ELB 显示「异常」时，先看健康检查：· 检查端口是否与业务实际监听端口一致（常见错：后端跑在 8080，健康检查配的 80）；· 检查路径是否返回 200（/ 返回 302 或 401 都会被判异常，应改成 /health 这类返回 200 的探针）；· 检查后端 ECS 上是否有防火墙（iptables/firewalld）拦了 ELB 的探针源地址。五、监听器与协议· 监听器端口是否和内网访问的端口一致（比如监听 80 转发到后端 8080）；· 如果配了 HTTPS 监听，客户端用 http 访问会失败；· 四层（TCP）和七层（HTTP）监听对后端的要求不同：七层会带 X-Forwarded-For，四层直接透传。六、用最小化手段定位在内网机器上按顺序试：ping # 通不通（ICMP 可能被禁，不通不代表有问题）telnet 80 # 端口是否可达curl -v http:/// # 有无响应、返回码nslookup 域名> # 用域名访问时先确认解析到内网地址如果 telnet 不通 → 安全组/ACL/路由问题；telnet 通但 curl 502/504 → 后端健康检查或后端服务问题；curl 返回 404 → 监听器转发规则配错。七、几个容易忽略的点· 域名解析到了公网 IP，而内网机器没有公网出口 → 看起来“连不上 ELB”，实际是解析问题；· ELB 开启了「健康检查只允许内网」，但后端在另一个安全组里；· 客户端机器自身有出站限制（企业内网常见），需要单独申请放通。

判断一个业务适不适合上函数，就看三个特征：事件驱动、执行时间短、流量不均匀。三者占两个以上，函数基本是划算的；都不占，就该用 ECS/CCE。一、最典型的五类场景1. 事件驱动的数据处理：对象存储上传触发缩略图生成/转码/OCR、日志投递到 OBS 后触发解析入库、消息队列消费。这类场景函数几乎是唯一优雅解——不用为「偶尔来一批文件」常驻一台机器。2. 定时任务：定时清理、报表生成、数据同步、证书续期。用定时触发器替代 crontab，省掉一台跳板机的运维成本。3. 轻量 API 与 Webhook：给小程序/公众号做回调、第三方支付回调、GitHub Webhook 处理。特点是请求量不大但要求随时可用，按调用计费比包月便宜得多。4. 胶水层/编排层：把几个云服务串起来——调 API 网关 → 校验 → 写数据库 → 发消息。这种「逻辑不重但链路长」的活，写成函数比部署一个服务轻得多。5. AI 推理的前后处理：图片预处理、文本清洗、结果后处理与格式化，配合模型服务做 pipeline。GPU 推理本身不建议放函数，但前后处理非常适合。二、明确不适合的场景· 长连接/常驻服务：WebSocket 服务、长轮询，函数实例会被回收；· 单次执行超长的任务：函数有最大执行时长限制（通常十几分钟），大文件转码、大批量计算要拆片或改用批量计算；· 延迟极敏感的核心链路：冷启动是绕不过去的，除非配预留实例（成本就上去了）；· 重状态服务：函数实例无状态且可能随时销毁，会话、缓存必须外置到 Redis；· 持续高负载：24 小时跑满的场景，函数的按量计费反而比包年包月贵。三、选型对照突发、稀疏、事件驱动 → 函数；稳定中高负载、需要精细调优 → CCE 容器；单体应用、需要完整操作系统控制 → ECS。实践中常见组合是「核心服务跑 CCE + 周边事件处理用函数」，把不稳定的边缘负载交给函数，核心链路保持可控。四、上之前先算两笔账一是调用量账：把月调用次数 × 平均执行时长 × 内存规格，和一台 ECS 的月费对比；二是运维账：省下的机器运维、扩缩容配置值多少钱。很多场景第二笔账才是决定性的。

「agent」这个词现在被用得很泛，实际分成四类，选型先看你属于哪一类：1. 编码类（IDE 内 agent）Cursor、Claude Code、GitHub Copilot、通义灵码、华为云码道 CodeArts Snap、Trae。这类是当前落地最实的——有明确的文件读写和终端执行环境，反馈闭环短。日常写业务代码、改 bug、写测试，效率提升最直接。选型看两点：模型能力（长上下文与工具调用稳定性）和是否支持本地仓库索引。2. 通用自主 agent（浏览器/桌面操作）Manus、扣子空间、各类 computer-use 产品。适合「帮我查资料整理成表」「跑一遍网站流程」这类跨系统的模糊任务。目前瓶颈在稳定性：长链路任务的成功率还不高，适合人盯着用，不适合无人值守。3. 企业工作流编排（最容易被低估）Dify、Coze、n8n、FastGPT。严格说不是「自主 agent」，而是把 LLM 节点嵌进确定性流程。优势是可观测、可回滚、成本可控。企业里真正跑在生产上的，绝大多数是这一类而不是自主 agent。4. 开源框架（自己搭）LangGraph（状态机式，可控性最好）、AutoGen（多 agent 对话）、CrewAI（角色扮演式，上手快）、LlamaIndex（偏 RAG）。本地部署栈常见 vLLM/Ollama + OpenWebUI + Qdrant/Milvus。自己搭的代价是要处理工具调用容错、上下文压缩、并发与限流，工程量不小。怎么选（按场景）· 写代码 → IDE 内 agent，收益/成本比最高；· 固定业务流程（客服、报告生成、数据清洗）→ 工作流编排，别上自主 agent；· 探索性任务、一次性脚本 → 通用 agent 或直接让编码 agent 写脚本；· 有数据合规要求 → 开源框架 + 私有化模型，别无选择。一个务实建议：先别纠结框架，把「工具层」做扎实——把你系统里的能力（查询、写库、发消息）封装成清晰的、有 schema 的函数，任何 agent 框架接进来都能跑。工具层设计得好，换框架成本几乎为零；工具层一塌糊涂，换什么框架都难用。

选型最容易犯的错是「先挑配置再想业务」，正确顺序是先定位瓶颈资源，再按瓶颈选族，最后用计费方式省钱。一、先判断你的负载类型· CPU 密集（编译、转码、加解密、计算）：看主频与 vCPU，选计算型；· 内存密集（Redis、ES、JVM 大堆、数据库）：内存/vCPU 比要 4:1 甚至 8:1，选内存型；· IO 密集（数据库、日志、消息队列）：瓶颈在磁盘 IOPS 与吞吐，云盘规格比 CPU 更关键；· 网络密集（网关、代理、CDN 回源）：看内网带宽与 PPS，选网络增强型；· 潮汐型/低负载（个人站、测试环境）：突发性能型，靠 CPU 积分跑突发。二、几个容易被忽略的性能陷阱1. 突发性能型的积分耗尽：基线通常只有 20%~30%，积分用完就降频到基线，表现为「跑一会儿突然变卡」。生产环境别用它扛持续负载。2. 云盘的 IOPS 才是数据库的命门：ESSD 分 PL0/PL1/PL2/PL3，IOPS 与容量挂钩（容量越小 IOPS 上限越低）。MySQL 建议 PL1 起步，且容量别小于 100G，否则 IOPS 撑不住写入。3. 带宽计费方式：固定带宽（按 Mbit 包月）适合流量平稳；按流量计费适合波峰明显但总量小的场景。注意内网流量免费，同区域多台机器通信走内网能省一大笔，别让服务绕公网。4. vCPU 是超线程：1 vCPU 通常是 1 个超线程，物理核性能约为其 1.5~2 倍。单线程敏感的业务（如某些 Java 服务）要按物理核折算。三、省钱手段（按收益排序）① 包年包月 vs 按需：长期稳定负载包年包月通常比按需便宜 50% 以上；短期/不确定用按需，用完即释放。② 弹性伸缩：无状态服务配 ASG，低谷缩到 1 台，比固定 4 台省得多。③ ARM 架构：鲲鹏实例同规格价格更低，前提是镜像和依赖有 aarch64 版本（Docker 多架构镜像基本没问题）。④ 轻量应用服务器：个人站、小流量 API 用它比 ECS 便宜很多，缺点是规格固定、扩展性差。⑤ 闲置资源清理：挂载未使用的 EIP、快照、按需实例最容易漏钱，开个账单告警。四、别靠猜，压测一遍CPU：sysbench cpu --threads=N run；内存：sysbench memory run；磁盘：fio --rw=randwrite --bs=4k --iodepth=32 --numjobs=4；网络：iperf3 -c 对端。先小规格压出单机 QPS，再按目标流量线性外推并留 30% 余量。经验值：Web 应用单核 200~800 QPS（看框架），据此反推核数是比「凭感觉选 4C8G」靠谱得多的做法。

「跑一段时间就断」几乎都是资源泄漏或被系统杀掉，而不是代码逻辑错。按下面顺序查，基本一轮就能定位：1. 先确认它是怎么死的（最关键）看退出码：137 = 被 SIGKILL（大概率 OOM killer 或容器内存超限）、143 = SIGTERM（被调度器/超时踢掉）、1 = 自己抛异常退出。dmesg -T | grep -i "killed process" 能直接看到是不是 OOM；在容器里看 docker inspect 的 OOMKilled 字段。2. 内存泄漏（最常见）用 ps -o rss= -p PID 每 10 秒采一次，画曲线：单调上升不回落就是泄漏。典型来源：· requests 的 Session 用完没 close()，连接池对象累积；· 全量 response.text 存进 list 当缓存，页面越爬越大；· 解析库（lxml/BeautifulSoup）持有 DOM 引用，循环里没释放；· asyncio 里 create_task 不 await，任务对象堆积；· 全局字典做去重（seen set）无限增长。处理：去重集合落盘（SQLite/Redis）或加 LRU 上限；响应体用 stream=True 边下边处理；定期 gc.collect() 并排查循环引用。3. 文件句柄耗尽lsof -p PID | wc -l 接近 ulimit -n（默认 1024）就会 Too many open files。多见于日志文件不轮转、临时文件不删、socket 未关闭。处理：ulimit -n 65535，日志用 logging.handlers.RotatingFileHandler 或交给 logrotate。4. 连接与端口ss -s 看 TIME_WAIT 数量；短连接高频请求会打满本地端口（约 2.8 万个）。处理：复用 Session + HTTPAdapter(pool_maxsize=...)，或改用长连接。5. 被目标站封禁表现是突然全部 403/429/超时。加请求间隔、UA 池、指数退避重试；不要用无限重试，重试要有上限并把失败项落队列。工程上的根治办法：把爬虫做成可恢复的——① 用 systemd 或 supervisor 托管，挂了自动拉起；② 待爬队列与已爬状态持久化（SQLite 一张表即可），重启后从断点继续；③ 每个 URL 处理独立事务，失败记次数，超过阈值进死信队列；④ 关键指标（成功率、平均耗时、内存、队列长度）打日志，出问题能回溯。做到这四点，「断」就只是个小插曲而不是事故。