个人简介 & 后台通用心法

从互联网到游戏的后台复习心法

记住，也许只有一种失败——是不善言辞的表达。

一句话心法

分而治之，读写分离。 读有读的优化，写有写的优化。读加缓存、加备份、冷热分离、动静分离；写加分片、减少锁、加缓冲、削峰限流。最后借鉴 MySQL 的 MVCC、JUC 的 CAS、共享锁、独占锁——其本质是一样的。

场景问题

横跨互联网与游戏两个方向，面对的核心问题始终是：如何在不同业务形态下把高性能、高可用、分布式这三件事讲清楚、做扎实。面试的第一分钟要判断什么该讲、什么该藏。

📣 面试当天要用的开场话术，见面试开场自我介绍叙事脚本（主线：风险把控 + 稳定性，含 60 秒电梯版与引导路线图）。

两段工作经历

互联网期（某互联网安全公司） — 智能硬件后台 · 网络安全 DDOS 攻防。

Web 全栈：jQuery → Vue/React、Gulp → WebPack、给 PHP 写扩展
CoreDNS / PublicDNS · Erlang 高并发编程 · 内核编译 · ARM 服务器信创

游戏期（某头部游戏大厂）

某短视频中台：工程效能建设 · 流量录制回放 · RPC 框架开源协同小组成员
某头部游戏工作室：某端转手游上云 · 某格斗手游攻坚 · 某 MOBA 手游 · 某射击手游
主要方向：自研 Mesh · 编译优化 · 商业化系统 · 研效工具 · AI 与游戏后台落地

实现方案

开源与团队参与

PHP 开发组：早期文档翻译
互联网期：开源 Meshery 服务网格压测框架社区参与
短视频中台期：流量录制回放开源协同小组联席成员
某射击手游：商城/充值/抽奖/VIP 系统负责人，从 0→1 完成商城与支付、付费测试到上线

万能公式：概念 → 场景 → 坑 → 填法

是什么 → 为什么选 → 踩过什么坑 → 怎么填的

举例（分布式锁）：

是什么：防止多机同时改同一数据
为什么选：秒杀库存对比 ZK/Redis，选 Redis（快）
踩过坑：长事务导致 Redis 锁提前过期，第二个人闯入
怎么填：紧急引入 Redisson 看门狗，后台自动续期

为什么这么做

🌟 高性能：先问场景，再给方案

秒杀、配置中心 18w QPS、序列化/反序列化压测；有些操作应下沉到客户端本地
Kafka 架构与高性能：Rebalance、消息可靠性、顺序性
定位性能瓶颈的顺序：观测→采样→分层排除（网络/磁盘/CPU/锁）
四层 vs 七层负载：为什么不选 Istio？卡在 Envoy 的 3 倍 socket 与 XDS 全量下发；更适合 HTTP，不支持点对点，跨集群还要 CROSS 模块，路由策略有限

🌟 高可用：故障发生时可控、可隔离、可恢复

请求太多？限时、排队、削峰
下游变慢？超时、重试、熔断、隔离
核心服务挂了？降级、冗余、故障转移
重复请求？幂等、防重、状态机
上线前预防？压测、监控、混沌工程、演练、容量评估

🌟 分布式：为什么必须做取舍

要快就得数据不一致——同步等所有机器变慢；要不停工就得允许延迟。这就是 CAP。

分布式概念地图

概念	解决什么问题
CAP	强一致 / 不卡顿 / 不怕断网 · 三选二
BASE	折中方案：允许中间不一致，只要最终一致
Paxos	一群随时可能死机的节点，如何达成唯一共识（理论鼻祖）
Raft	Paxos 简化版：选 Leader、写流水账（工程可实现）
ZAB	ZooKeeper 专用同步协议（选主+日志复制，同类 Raft）
Gossip	像村头大妈传八卦，一对一互传，最后全网都收到（超大集群适用）
一致性哈希	扩缩容时只有极少数据需要搬家，大部队不受影响

微服务四大件的职责

组件	职责比喻
RPC	修路的：让远端服务像本地调用一样
API 网关	看门大爷：鉴权、限流、路由，唯一入口
配置中心	全校大广播：改配置无需重启，广播一喊立即生效
注册中心	动态通讯录：谁开机就登记，谁死机就划掉

为什么别的选择不行

游戏后台 vs 互联网后台的本质

关注点根本不同：

单次响应绝对延迟 vs 整站吞吐/并发承载
游戏选择"单线程无锁"：人与人、人与怪状态高度交织，加锁代价太大；游戏是计算密集型，单线程无锁循环延迟最低
互联网选择"多线程/协程"：请求彼此独立（无状态），大量时间在等 DB I/O，多协程异步能压榨吞吐

为什么游戏单线程 / 互联网多线程

维度	游戏后台	互联网后台
状态耦合	强状态、强关联（AOE、扣血、吸血、眩晕多线程加锁太重）	无状态、弱关联（甲乙买东西无本质关系）
密集类型	CPU 计算密集（20~60Hz Tick，视距/碰撞/伤害/寻路）	I/O 密集（等 MySQL、Redis、第三方 API）
并发模型	单线程无锁 + 帧循环	多协程/多线程 + 异步
数据位置	几乎全在内存	主要在数据库/缓存

Istio 为什么慢？（不是控制面 Istiod，慢的是每个 Pod 的 Envoy Sidecar）

协议栈"反复横跳"：Context Switch + 数据拷贝
沉重的 L7 解析：认得 HTTP/1.1、HTTP/2、gRPC、Dubbo，能力都是代价
XDS 全量下发：500 服务 × 10 Pod = 每个 Envoy 内存维护 5000 实例；扩缩容一波爆炸

沉淀结论

分布式常见坑

分布式 ID：雪花算法时钟回拨坑——ID 瞬间重复
分布式锁：锁提前过期坑——业务没跑完 Redis 就放锁；需要看门狗续期
分布式事务：TCC/Saga 写补偿代码 + 幂等；MQ 最终一致性最常用；强一致性能差

HTTP/1.1 → HTTP/2 → HTTP/3 的线头阻塞演进

HTTP/1.1：一个 TCP 通道内请求串行 → 只能开多 TCP 连接（三次握手 + 慢启动 + 6 连接对 CPU/内存都是压榨）
HTTP/2：多路复用 + 二进制分帧 + HPACK 头部压缩 + Server Push；一个 TCP 承载全部请求
痛点：TCP 层线头阻塞——共用滑动窗口，一个包丢，整条流都停摆
HTTP/3：底层换 QUIC/UDP，每个"流"独立控制，一个流丢包不影响其他流

面试第一分钟：什么该讲，什么该藏

讲主线：一句话概括每段经历，不背简历
讲关键项目：某端转手游上云 · 某格斗手游 · 某射击手游支付/商城
讲你解决了什么：一致性、复用率、跨集群、多通道 CVM
备选深挖点：Mesh 演进 · Redis 版本 · K8s CNI · Agent Loop（对应本站其他 6 个专题）

软技能心法

技术是入场券，软技能决定天花板。面试官不只看你会不会，更看你能不能带、能不能扛、能不能一起走远。

沟通表达：把复杂讲简单

金字塔原理：先结论后论据。回答问题先给"是/否/结论"，再展开"因为一、二、三"。别让人猜你要说什么。
STAR 讲项目：Situation（背景）→ Task（目标）→ Action（我做了什么）→ Result（量化结果）。重点在 Action 用"我"不用"我们"，Result 一定要有数字。
翻译能力：对上讲价值（省了多少成本、扛住多少 QPS），对下讲方案（怎么落地、边界在哪），对齐比正确更重要。
一句话心法："如果你不能简单说明白，说明你还没真懂。" —— 能把 Istio 为什么慢讲给非技术的人听懂，才是真懂。

向上管理：让老板放心

对齐预期：接需求先问"什么时候要、优先级多高、验收标准是什么"，别闷头做完发现方向错了。
同步节奏：坏消息要早说、主动说。风险提前暴露是负责，出事了才说是背锅。
给选择题不给问答题：汇报问题时带上"方案 A / B + 我的建议 + 需要你拍板的点"，别把开放问题直接甩回去。

协作与冲突：技术分歧怎么收场

对事不对人：争的是方案不是输赢。用数据和场景说话——"这个场景下 A 的尾延迟更低"，而非"我觉得 A 更好"。
不同意但执行（disagree and commit）：充分表达后若团队定了别的方向，就全力把它做好，别阴阳怪气。
Code Review 心态：评审是提升代码质量不是挑刺，评论对代码不对作者；被 review 时把"防御"换成"感谢"。

学习与成长：如何保持技术敏锐

第一性原理：新技术先问"它解决了什么老方案解决不了的问题"，而非追新。Raft 之于 Paxos、HTTP/3 之于 HTTP/2 都是这个思路。
费曼学习法：学完能给别人讲明白才算学会——本站每个专题的"为什么别的选择不行"就是自测。
广度 + 深度 T 型：一横（知道全貌，能画出分布式概念地图）+ 一竖（至少一个方向能钻到源码/内核级）。
复盘文化：每个线上故障、每次面试失利都写复盘。"同一个坑不踩第二次" 比多学一个框架更值钱。

责任心与 Owner 意识

端到端负责：从需求到上线到线上告警都是我的事，不是"代码提了就完了"。某射击手游商城从 0→1 的底气就来自这。
主动补位：看到没人认领的坑主动接，看到隐患主动提。Owner 不是职级给的，是自己扛出来的。
长期主义：写别人能维护的代码、留能复用的文档、做能沉淀的工具（研效方向的本质）。

面试软技能加分项

反问环节：结尾主动问"团队现在最大的技术挑战是什么""这个岗位半年内最想解决的问题"——展示你在思考"进来能干什么"。
诚实边界：不会就说不会，但补一句"我会这样去查/去学"。装懂被追问穿帮是致命的。
情绪稳定：被连环追问、被质疑方案时，把它当技术讨论而非攻击。稳得住的人，团队才敢把关键系统交给你。

内容来源

综合整理自个人后台从业经历与通用架构心法。