杨先生

业务场景：
• CEX 核心交易引擎，处理现货交易（BTC/USDT、ETH/USDT 等主流币对）
• 合约交易（永续/交割）、期权交易
• 需要极致性能和绝对可靠性

架构设计：
• 基于红黑树实现订单簿（买卖盘各一棵树，价格作为 key，同价位订单用链表串联）
• 单线程串行化处理保证订单时序（避免锁竞争，牺牲部分性能换取正确性）
• 每个交易对独立撮合实例（BTC/USDT、ETH/USDT 等独立进程，互不影响）
• 通过消息队列与其他模块解耦（Kafka 异步通信，削峰填谷）

订单类型：
• 限价单（Limit Order，指定价格和数量）
• 市价单（Market Order，按市场最优价成交）
• 止损限价（Stop-Limit，触发价 + 委托价）
• 止损市价（Stop-Market，触发后市价成交）
• 冰山委托（Iceberg，隐藏真实挂单量，每次只显示部分数量，大户常用）
• Post-Only（只做 Maker 赚手续费返佣，如果会立即成交则拒绝）
• FOK（Fill or Kill，全部成交或取消，不接受部分成交）
• IOC（Immediate or Cancel，立即成交剩余撤销）

撮合逻辑：
• 价格优先时间优先（FIFO，买单价格高的优先，卖单价格低的优先，同价位先到先得）
• 自成交防护（防止用户左右手互搏刷量，同一 user_id 买卖单匹配拒绝）
• 最小成交量限制（防止粉尘订单，BTC 最小 0.001）
• 价格精度控制（使用 int64 存储，避免浮点误差，支持 18位小数，价格 = int64 / 10^18）
• 手续费实时计算（Maker -0.02% 返佣，Taker 0.05%，VIP 用户分级折扣）

性能优化：
• C++ 实现峰值可达 10万 TPS，单笔订单延迟 <100μs（从接收到撮合完成）
• 内存池避免 GC（预分配对象池，避免频繁 new/delete）
• 零拷贝减少数据拷贝（共享内存、mmap）
• CPU 亲和性绑定核心（避免 CPU 切换，提高缓存命中率）
• NUMA 架构优化（内存访问本地化）

高可用方案：
• 主备双活（主挂备秒级切换，Keepalived + VIP 漂移）
• 订单簿快照（每秒 Dump 到本地磁盘，mmap 快速加载，恢复时间 <3s）
• Kafka 增量日志（可回放，保留 7天，支持任意时间点恢复）
• 基于 Dump + Recover 机制实现秒级故障恢复
• 系统崩溃后可从最新快照 100% 恢复状态
• 支持热备（实时同步，主备数据一致）和冷备（定期快照，成本低）两种恢复模式
• 数据零丢失（Dump + Kafka 双重保障）

监控告警：
• 撮合延迟监控（P99 延迟 >1ms 告警）
• 订单簿深度监控（深度不足告警）
• 内存占用监控（>80% 告警，防止 OOM）
• Dump 失败告警（快照失败立即告警）
• Kafka 消费延迟监控（延迟 >1s 告警）
• 撮合 TPS 监控（实时监控，峰值预警）

实际痛点：
• 撮合引擎单点故障如何秒级恢复（Dump 快照 + Kafka 回放，实测恢复时间 <3s）
• 如何保证订单时序不乱（单线程串行化，牺牲部分性能换取正确性，多线程会导致时序混乱）
• 内存占用如何控制（订单簿膨胀问题，需要定期清理已成交订单，内存池复用对象）
• 如何防止恶意刷单（频率限制 Redis 令牌桶 + 自成交检测 + 黑名单）
• 价格精度如何避免浮点误差（int64 存储，价格 = int64 / 10^18，避免 0.1 + 0.2 != 0.3 问题）
• 如何处理极端行情（瀑布时订单暴增，内存和 CPU 压力，需要限流保护）
• 如何处理订单簿深度不足（市价单可能无法完全成交，部分成交处理）

实际应用：
• 支撑主流币对交易，峰值 QPS 可达 10万+
• 系统稳定运行，故障恢复时间 <3s

业务场景：CEX 用户需要实时查看币价、K线、深度盘口，Web/App/API 多端同步推送，要求低延迟（<50ms）、高并发（千万级连接）、数据准确不丢失

架构设计：
• 撮合引擎 → Kafka（行情总线，3副本保证可靠性）→ 行情服务（聚合计算，Golang 实现）→ WebSocket 网关（推送，Nginx 负载均衡）→ 用户端，采用分层架构实现解耦和扩展（每层独立扩容）

行情数据类型：
• Ticker（最新价/24h涨跌幅/成交量/最高最低价/买一卖一价）
• K线（1m/5m/15m/30m/1h/4h/1d/1w，OHLCV 数据，开高低收成交量）
• 深度（买卖盘各 20档，实时更新，档位：价格+数量+订单数）
• 逐笔成交（价格/数量/方向 buy/sell/时间戳/成交 ID）
• 24h 统计（开高低收/成交额/涨跌幅/振幅）

推送策略：
• Ticker 100ms 推送一次（合并推送，减少消息量）
• 深度增量推送（只推变化档位，全量推送太耗带宽，首次订阅推全量）
• K线实时聚合（滑动窗口，收盘时推送完整 K线）
• 成交逐笔推送（实时推送，延迟 <10ms）、订阅管理（用户可选择订阅币对和频道，减少无效推送，支持批量订阅）

性能优化：
• Kafka 分区并行（按交易对分区，BTC/USDT 一个分区，ETH/USDT 一个分区）
• Protobuf 压缩（压缩率 70%，减少带宽）
• 批量推送（合并 100ms 内数据，减少推送次数）
• CDN 加速静态数据（K线历史数据）
• 多级缓存（Redis + 本地缓存，减少数据库查询）

连接管理：
• WebSocket 长连接池（单机支持 10万+ 连接，epoll 模型）
• 心跳检测（30s ping/pong，超时断开释放资源，避免僵尸连接）
• 断线重连（客户端自动重连，指数退避 1s/2s/4s/8s）
• 数据补偿（Redis 缓存最近 1分钟数据，重连后补推，避免数据断层）
• 连接限流（单 IP 最多 100 连接，防止 DDoS 攻击，超过限制拒绝连接）

监控告警：
• 推送延迟监控（撮合到用户端延迟 >100ms 告警）
• 连接数监控（单机连接数 >8万 预警）
• 消息丢失率监控（>0.01% 告警）
• Kafka 消费延迟监控（延迟 >1s 告警）
• 慢客户端监控（消息队列积压 >1000 条告警）
• WebSocket 断连率监控（断连率 >5% 告警）

实际痛点：
• 如何处理百万级连接（连接池 + 分布式部署 + Nginx 负载均衡 + epoll 高性能 I/O）
• 如何保证消息不丢失（Kafka 持久化 3副本 + Redis 缓存 + 客户端确认机制 ACK）
• 如何处理慢客户端（消息队列满了怎么办：设置上限 1000 条，超过阈值断开连接，避免影响其他用户）
• 如何保证推送顺序（Kafka 分区保序，同一交易对路由到同一分区，partition key = symbol）
• 如何处理行情风暴（极端行情时消息暴增：批量推送 + 限流 + 降级，优先保证核心数据）
• 如何优化带宽（Protobuf 压缩 + 增量推送 + 合并推送，带宽成本降低 70%）
• 如何处理网络抖动（重连机制 + 数据补偿，保证数据连续性）

业务场景：用户通过 Web/App/API 下单买卖加密货币，需要处理订单创建、校验、撮合、成交、撤销全流程，保证资金安全和交易公平

订单流程：
• 用户下单（Web/App/API）→
• 风控校验（余额充足性/仓位限制/频率限制/价格合理性/自成交检测）→
• 冻结资金（预扣保证金或币种，防止超卖）→
• 发送撮合引擎（Kafka 消息队列，异步处理）→
• 撮合成交（撮合引擎处理，生成成交记录）→
• 通知清算系统（Kafka 消息）→
• 清算系统处理资金变动（解冻 + 扣款 + 手续费）→
• 推送成交通知（WebSocket 推送给用户）→ ⑨记录流水（MySQL 持久化，按月分表）

订单类型：
• 现货订单（买入/卖出）
• 合约订单（开多/开空/平仓）
• 计划委托（价格触发后下单，触发价 + 委托价）
• 止盈止损（TP/SL 自动平仓，盈利/亏损达到目标自动平）
• 追踪止损（跟随价格移动，动态调整止损价）
• 冰山委托（大单拆分隐藏，每次只显示部分数量）

订单校验：
• 余额充足性（现货需要足够 USDT，合约需要保证金，考虑手续费）
• 价格合理性（不能偏离市场价 ±10%，防止乌龙指）
• 最小下单量（BTC 最小 0.001，防止粉尘订单）
• 频率限制（API 每秒最多 10 单，Web 每秒 5 单，防止刷单）
• 自成交检测（同一用户买卖单匹配拒绝，防止刷量）
• 持仓限制（单用户持仓不超过上限，防止风险集中）

数据架构：活跃订单全内存（HashMap 快速查询，<1ms，支持 orderID/user_id/symbol 多维度查询）、订单簿在撮合引擎内存（红黑树，O(logN) 查询）、成交订单异步写 MySQL（按月分表，避免单表过大，历史数据归档）、Redis 做持久化备份（防止内存数据丢失，支持快速恢复）、历史订单归档到 OSS（超过 3个月，节省成本，按需加载）

实际痛点：
• 如何防止重复下单（幂等性：订单 ID 雪花算法 + Redis 去重表，TTL 1小时）
• 如何处理订单撤销（已成交部分如何处理：部分成交不可撤，未成交部分可撤）
• 如何处理部分成交（订单状态机设计：未成交 → 部分成交 → 完全成交/已撤销）
• 如何保证资金安全（先冻结再撮合，失败回滚，TCC 分布式事务）
• 如何处理高并发下单（限流 + 队列削峰 + 异步处理）
• 如何处理订单查询（多维度索引：orderID 主键 + user_id/symbol 复合索引）

性能优化：
• 订单 ID 雪花算法生成
• 幂等性防重复提交
• 异步写库不阻塞
• 批量查询优化
• 索引优化（orderID 主键索引 + user_id/symbol 复合索引）

实际应用：日均处理大量订单，订单提交响应 <50ms，订单查询 <10ms，支持批量下单、批量撤单

业务场景：CEX 需要实时清算用户资金（充值/提现/交易/手续费）、合约盈亏结算、资金费率结算、强平清算，保证账务准确、资金安全

现货清算：
• 订单成交后撮合引擎通知清算系统
• 清算系统解冻并扣除资金（买方扣 USDT 加 BTC，卖方扣 BTC 加 USDT）
• 手续费计算与扣除（Maker -0.02% 返佣，Taker 0.05%）
• 充值到账（链上确认后入账）
• 提现处理（冻结 → 链上转账 → 扣除）

合约清算：
• 开仓冻结保证金（10倍杠杆开 1000U 仓位需要 100U 保证金）
• 标记价格计算（多交易所价格加权，防操纵）
• 未实现盈亏实时计算
• 资金费率结算（每 8h 多空互付，费率 ±0.01%）
• 强平清算（保证金率 <维持保证金率触发）
• 穿仓分摊（亏损超过保证金由风险准备金承担）

清算时机：T+0 实时清算（订单成交立即清算）、定时清算（资金费率每 8h 结算）、日终清算（统计日报）、强平清算（实时监控触发）

数据一致性：
• 分布式事务（TCC 模式：Try 冻结 → Confirm 扣款 → Cancel 回滚）
• 幂等性防重复扣款
• 对账系统（实时对账 + 日终对账）
• 差错处理（人工介入）

技术实现：Redis 分布式锁（防并发扣款）、MySQL 事务（保证原子性）、消息队列异步处理、定时任务（XXL-Job）、流水表记录所有变动

实际应用：日均清算大量交易，保证资金准确性，强平成功率 99.9%，穿仓率 <0.1%

业务场景：
• CEX 新上币种或小币种流动性不足，买卖价差大（>0.1%），用户交易滑点高，需要做市商提供流动性，维持合理价差和深度（主流币对目标 0.01%-0.02%）

做市策略：
• 动态价差策略（根据波动率调整，波动大价差宽，波动小价差窄，ATR 指标计算波动率）
• 网格策略（在价格区间内密集挂单，网格间距 0.05%-0.1%，适合震荡行情）
• 对冲策略（在币安/OKX 对冲风险，库存超过阈值立即对冲，对冲成本 0.05%）
• 深度管理（买卖盘各维持 20档，每档 1-5 BTC，形成深度吸引用户交易）

报价逻辑：
• 获取参考价（币安/OKX 加权平均，防止单一交易所价格异常，WebSocket 实时订阅）
• 计算价差（基础价差 0.015% + 波动率调整 ±0.005%，波动大价差宽保护风险）
• 分层挂单（买盘 -0.01%/-0.02%/-0.03%，卖盘 +0.01%/+0.02%/+0.03%，形成深度）
• 动态调整（每 100ms 重新计算，快速响应市场变化，撤单重挂）

风险控制：
• 库存管理（BTC 持仓不超过 100 个，避免单边风险，库存偏离及时对冲）
• 敞口对冲（持仓超过 50 BTC 立即对冲到币安/OKX，对冲成本 0.05%）
• 止损机制（单日亏损超过 1% 暂停做市，避免持续亏损）
• 异常行情暂停（价格波动 >5% 暂停 1分钟，防止被套，瀑布/插针快速撤单）
• 滑点控制（下单前检查深度，避免冲击成本过大，大单拆分）

实际痛点：
• 如何平衡收益和风险（价差太窄亏钱，太宽没成交，需要动态调整）
• 库存如何管理（对冲成本 vs 持仓风险权衡，对冲太频繁成本高）
• 如何应对异常行情（瀑布/插针如何快速撤单，网络延迟导致撤单不及时）
• 如何处理网络延迟（行情延迟导致报价不准，WebSocket 断线重连）
• 如何防止被夹（大单吃掉挂单后价格反向，损失价差，需要快速撤单重挂）
• 如何处理库存积压（库存偏离如何对冲，对冲时机选择）

性能优化：策略计算 <1ms（内存计算，避免数据库查询）、下单延迟 <10ms（gRPC 调用交易接口，连接池复用）、行情处理 <5ms（WebSocket 实时订阅，本地缓存订单簿）、WebSocket 多路复用（单连接订阅多个交易对）、本地缓存订单簿（避免频繁查询，内存镜像）、批量下单（减少网络开销，单次最多 20 单）

技术实现：
• Golang 高并发（协程并发处理，单机支持 1000+ 策略实例）
• 内存计算（策略参数全内存，避免 I/O）
• WebSocket 实时行情（订阅币安/OKX/本平台行情）
• gRPC 调用交易接口（高性能 RPC，Protobuf 序列化）
• Redis 缓存策略参数（热更新，无需重启）
• Prometheus 监控 PnL（实时监控盈亏，Grafana 可视化）

监控告警：
• PnL 监控（实时盈亏，亏损 >1% 告警）
• 库存监控（持仓超过阈值告警）
• 策略延迟监控（策略计算延迟 >10ms 告警）
• 下单失败监控（失败率 >1% 告警）
• 行情延迟监控（行情延迟 >100ms 告警）
• 对冲失败监控（对冲失败立即告警）

实际痛点：
• 如何平衡收益和风险（价差太窄亏钱，太宽没成交，需要动态调整，根据波动率和成交量实时调整）
• 库存如何管理（对冲成本 vs 持仓风险权衡，对冲太频繁成本高 0.05%，不对冲风险大）
• 如何应对异常行情（瀑布/插针如何快速撤单，网络延迟导致撤单不及时，损失扩大）
• 如何处理网络延迟（行情延迟导致报价不准，WebSocket 断线重连，数据补偿）
• 如何防止被夹（大单吃掉挂单后价格反向，损失价差，需要快速撤单重挂，监控大单）
• 如何处理库存积压（库存偏离如何对冲，对冲时机选择，市场深度不足时分批对冲）
• 如何处理滑点（大单对冲滑点大，拆分小单，TWAP 算法）
• 如何应对竞争对手（其他做市商抢单，策略优化，降低延迟）

业务场景：CEX 面临多种风险：用户爆仓穿仓、恶意刷量、洗钱、API 滥用、价格操纵，需要多层次风控体系保障平台和用户资金安全

合约风控：
• 保证金率监控（实时计算，低于维持保证金率触发强平）
• 强平机制（保证金率 <1.5% 触发，市价单平仓，可能滑点）
• 穿仓处理（亏损超过保证金由风险准备金承担）
• 自动减仓 ADL（风险准备金不足时，盈利用户按比例减仓，避免平台亏损）
• 价格熔断（价格波动 >10% 暂停交易 5分钟，防止恶意操纵）

交易风控：
• 频率限制（API 每秒最多 10 单，Web 每秒 5 单，防止刷单）
• 自成交检测（同一用户买卖单匹配拒绝，防止刷量）
• 刷量检测（短时间大量下撤单标记异常，人工审核）
• 价格偏离检测（下单价格偏离市场价 ±10% 拒绝，防止乌龙指）
• 最大持仓限制（单用户 BTC 持仓不超过 1000 个，防止单一用户风险过大）

实际痛点：
• 如何平衡风控和用户体验（风控太严影响交易，太松有风险）
• 如何处理极端行情（瀑布时强平不及时导致穿仓）
• 如何防止恶意刷量（刷量检测 vs 正常高频交易）
• 如何处理风险准备金不足（ADL 机制如何公平分摊）
• 如何防止价格操纵（小币种深度浅，容易被操纵）

资金风控：
• 提现审核（单笔 >1 BTC 人工审核）
• 异常提现检测（提现地址首次出现、提现频率异常）
• 黑名单地址（已知黑客地址拒绝）
• 大额交易监控（单笔 >10万美元上报）
• 反洗钱 AML（可疑交易标记）

风控层级：用户级（单用户限制）→ 账户级（子账户管理）→ 交易对级（单币种敞口）→ 系统级（全局风险），层层防护

技术实现：
• 规则引擎（Drools 配置规则）
• 实时计算（Flink 流式处理）
• Redis 限流（令牌桶算法）
• 机器学习（异常检测模型）
• Prometheus 监控告警

实际应用：成功拦截大量异常交易、强平成功率 99.9%、穿仓率 <0.1%、有效降低系统风险

分布式架构：微服务架构设计、DDD 领域驱动设计、服务拆分（按业务域）、服务治理（注册发现/配置中心/API 网关）、服务间通信（gRPC/HTTP/消息队列）

高可用设计：熟悉多活架构、容灾设计、故障隔离、熔断降级、限流保护等高可用方案

性能优化：有大规模系统优化经验（4500万 DAU），熟悉数据库优化（索引/分库分表/读写分离）、缓存优化（多级缓存/缓存预热）

技术选型：
• Consul/Eureka 服务发现
• Apollo/Nacos 配置中心
• Kong/Zuul API 网关
• Istio 服务网格
• Prometheus 监控
• Jaeger 链路追踪

容器编排：
• Docker 容器化
• Kubernetes 集群管理
• Helm 包管理
• CI/CD 自动化部署（Jenkins/GitLab CI）
• 监控告警（Grafana/AlertManager）

数据架构：
• MySQL 主从复制
• 分库分表（ShardingSphere）
• Redis 集群
• Kafka 消息队列
• ElasticSearch 日志检索
• ClickHouse 数据分析

编程语言：
• Golang（精通，6年+，高并发/微服务/撮合引擎）
• C++（熟悉，底层优化/性能调优/撮合引擎核心）
• Python（数据分析/脚本/运维工具）
• SQL（MySQL/PostgreSQL 性能优化）

Web 框架：
• Gin（高性能 HTTP 框架，API 网关）
• Fiber（Express 风格，快速开发）
• Echo（轻量级，中间件丰富）
• gRPC（服务间通信，Protobuf 序列化）

数据库：
• MySQL（主从复制/分库分表/索引优化/慢查询优化）
• PostgreSQL（JSONB/全文搜索/复杂查询）
• Redis（集群/哨兵/持久化/分布式锁/限流）
• MongoDB（文档存储/日志存储）
• TimescaleDB（时序数据/K线数据/行情数据）
• ClickHouse（OLAP/数据分析/报表统计）

消息队列：
• Kafka（高吞吐/分区/副本/消费者组/事务消息）
• NATS JetStream（低延迟/轻量级/云原生）
• RocketMQ（事务消息/顺序消息/延迟消息）
• RabbitMQ（AMQP/死信队列/延迟队列）
• Pulsar（多租户/跨地域复制）

缓存与存储：
• Redis Cluster（分片/高可用/Lua 脚本）
• Redis Sentinel（主从切换/故障转移）
• Memcached（简单缓存/高性能）
• OSS/S3（对象存储/历史数据归档）

DevOps 与监控：
• Docker（容器化/镜像构建/多阶段构建）
• Kubernetes（集群管理/服务编排/自动扩缩容）
• Helm（包管理/版本管理/配置管理）
• Jenkins/GitLab CI（CI/CD/自动化部署）
• Prometheus（指标采集/告警规则/PromQL）
• Grafana（可视化/Dashboard/告警通知）
• Jaeger（分布式追踪/链路分析/性能分析）
• ELK Stack（日志收集/检索/分析）
• Ansible（自动化运维/配置管理）

服务治理：
• Consul/Eureka（服务注册发现/健康检查）
• Apollo/Nacos（配置中心/动态配置/灰度发布）
• Kong/Zuul（API 网关/限流/鉴权/路由）
• Istio（服务网格/流量管理/安全策略）
• Sentinel（流量控制/熔断降级/系统保护）

性能优化工具：
• pprof（Go 性能分析/CPU/内存/协程）
• perf（Linux 性能分析/火焰图）
• valgrind（内存泄漏检测/性能分析）
• gdb（调试工具/core dump 分析）
• strace（系统调用追踪）
• tcpdump/Wireshark（网络抓包分析）

测试工具：
• JMeter（压力测试/性能测试）
• Locust（分布式压测/Python 编写）
• wrk/ab（HTTP 压测工具）
• go-stress-testing（Go 压测工具）

WebSocket 优化：
• 连接复用：单连接支持多币对订阅，减少连接数（从 100万连接降至 10万）
• 消息压缩：Protobuf 替代 JSON，压缩率 70%，带宽节省明显
• 批量推送：合并 100ms 内消息，减少推送次数（从 1000次/s 降至 100次/s）
• 增量推送：深度数据只推变化档位，全量推送改增量（数据量减少 90%）
• 心跳优化：30s ping/pong，超时断开释放资源，避免僵尸连接
• 慢客户端处理：消息队列设置上限 1000 条，超过断开连接
• 连接池管理：epoll 模型，单机支持 10万+ 连接
• 负载均衡：Nginx 四层负载，按连接数分配

数据库优化：
• 索引优化：orderID 主键索引 + user_id/symbol 复合索引，查询从 500ms 降至 <10ms
• 分库分表：订单表按月分表，单表控制在 1000万以内，避免大表查询慢
• 读写分离：主库写，从库读，读写比 9:1，主库压力降低 90%
• 慢查询优化：explain 分析执行计划，添加索引，避免全表扫描
• 连接池优化：连接池大小 100，避免频繁创建销毁连接
• 批量操作：批量插入 1000 条/次，性能提升 10倍
• 冷热分离：历史数据归档到 OSS，热数据保留 3个月
• 分页优化：使用游标分页替代 offset，避免深分页慢查询

缓存优化：
• 多级缓存：本地缓存（Caffeine）+ Redis 缓存，命中率 95%+
• 缓存预热：系统启动时预加载热点数据，避免冷启动
• 缓存穿透：布隆过滤器拦截不存在的 key，避免打到数据库
• 缓存击穿：热点数据永不过期 + 互斥锁，避免并发查询数据库
• 缓存雪崩：过期时间加随机值，避免同时失效
• 缓存更新：先更新数据库，再删除缓存（Cache Aside 模式）
• Redis 集群：分片存储，单节点故障不影响整体
• 持久化策略：AOF + RDB 混合持久化，数据安全与性能兼顾

消息队列优化：
• Kafka 分区：按交易对分区，同一交易对消息保序
• 消费者组：多消费者并行消费，提高吞吐量
• 批量消费：批量拉取 1000 条消息，减少网络开销
• 异步发送：异步发送消息，不阻塞主流程
• 消息压缩：Snappy 压缩，压缩率 50%，减少网络传输
• 副本机制：3副本保证可靠性，1个 leader + 2个 follower
• 消费位移管理：手动提交 offset，避免消息丢失或重复消费
• 死信队列：消费失败的消息进入死信队列，人工处理

接口优化：
• 异步处理：耗时操作异步化，接口响应时间从 500ms 降至 50ms
• 批量接口：批量查询订单，减少接口调用次数（从 100次降至 1次）
• 接口合并：多个接口合并为一个，减少网络往返
• 数据预聚合：提前计算好统计数据，查询时直接返回
• 分页优化：限制单页最大 100 条，避免大数据量查询
• 字段裁剪：只返回必要字段，减少数据传输量
• CDN 加速：静态资源使用 CDN，加载速度提升 3倍
• HTTP/2：多路复用，减少连接数，提高并发性能

并发优化：
• 协程池：限制协程数量 10000，避免协程泄漏导致 OOM
• 无锁编程：atomic 原子操作，避免锁竞争
• 读写锁：读多写少场景使用 RWMutex，读并发性能提升
• 分段锁：ConcurrentHashMap 思想，减少锁粒度
• 乐观锁：version 字段，避免悲观锁阻塞
• 限流保护：令牌桶算法，QPS 限制 10000，避免系统过载
• 熔断降级：Sentinel 熔断，故障服务自动降级
• 超时控制：context.WithTimeout，避免请求堆积

内存优化：
• 对象池：sync.Pool 复用对象，减少 GC 压力
• 内存池：预分配内存，避免频繁 malloc/free
• 零拷贝：mmap/sendfile，减少数据拷贝
• 字符串优化：strings.Builder 替代 + 拼接，减少内存分配
• slice 预分配：make([]int, 0, cap)，避免扩容
• 内存泄漏检测：pprof 定期检查，及时发现泄漏
• GC 调优：GOGC 参数调整，平衡内存占用和 GC 频率
• 大对象优化：大对象放堆外内存，减少 GC 扫描

监控与告警：
• 指标监控：Prometheus 采集 QPS/延迟/错误率/CPU/内存
• 链路追踪：Jaeger 追踪请求链路，定位性能瓶颈
• 日志分析：ELK 收集日志，快速定位问题
• 告警规则：P99 延迟 >100ms 告警，错误率 >1% 告警
• Dashboard：Grafana 可视化，实时监控系统状态
• 压测验证：JMeter 压测，验证系统容量和性能瓶颈
• 性能分析：pprof 火焰图，定位 CPU/内存热点
• 慢查询监控：MySQL slow log，优化慢查询