2.12 云 Redis 最佳实践 + 其他 NoSQL

课程简介

本课程将深入探讨云数据库 Redis 在生产环境中的两大“痛点”——大 Key（Big Key）和热 Key（Hot Key）的成因、危害及解决方案。此外，我们将系统介绍腾讯云 NoSQL 家族的其他核心成员，包括 MongoDB、Memcached、CTSDB（时序数据库）、VectorDB（向量数据库）、KonisGraph（图数据库）以及专为游戏打造的 TcaplusDB。

学习目标

通过本课程的学习，您将能够：

• ✓ 解决 Redis 痛点：掌握大 Key 和热 Key 的排查方法及拆分、读写分离等优化策略。
• ✓ 掌握 NoSQL 选型：了解 MongoDB、Memcached 等数据库的特性与适用场景。
• ✓ 熟悉新兴数据库：理解时序数据库、向量数据库、图数据库在 AI、物联网及社交网络中的应用价值。
• ✓ 了解行业专库：认识 TcaplusDB 在游戏行业的高并发优势。

---

第一部分：云 Redis 最佳实践 —— 大 Key 与热 Key

本部分导读
Redis 性能虽强，但并非无懈可击。90% 的 Redis 生产故障都源于 Key 设计不当。

一、定义与识别

1.1 什么是大 Key (Big Key)?

大 Key 本质上是 Value 过大。它不是 Key 本身的字符串长，而是 Key 对应的 Value 占用内存大或包含元素多。

判定标准： - String 类型：Value > 10 MB。 - Set/List/ZSet 类型：成员数量 > 1 万个。 - Hash 类型：成员数量 > 1000 个，且总大小 > 1000 MB。

1.2 什么是热 Key (Hot Key)?

热 Key 是指访问频率极高的 Key，导致流量倾斜。

判定标准： - QPS 倾斜：某一个 Key 的 QPS 达到数千甚至上万（如实例总 QPS 10万，某个 Key 占了 5万）。 - 带宽倾斜：某个 Key 占用大量带宽（如一个 Hash Key 频繁被 HGETALL）。

二、成因与危害

2.1 大 Key 的危害

1. 阻塞请求：Redis 是单线程架构，操作大 Key（如删除、序列化）耗时久，会阻塞后续请求，导致响应超时。
2. 内存不均：在集群架构中，导致某个分片内存爆满（OOM），引发数据逐出或节点宕机。
3. 网络拥塞：读取大 Key 产生巨额流量（如 1MB * 1000 QPS = 1GB/s），打满网卡带宽。
4. 主从中断：同步大 Key 易导致主从复制超时中断。

成因： - 直接存储二进制文件（图片/视频）。 - 列表/集合无限增长，未设置清理机制。 - 业务设计缺陷，未对数据分片。

2.2 热 Key 的危害

1. 节点过载：热点所在的 Redis 分片 CPU 飙升，成为系统瓶颈。
2. 缓存击穿：热 Key 宕机或过期瞬间，海量请求直接打到底层数据库，引发雪崩。
3. 扩展失效：单纯增加分片无法解决单 Key 热点问题。

成因： - 突发热点事件（爆款商品、热点新闻）。 - 刷单/爬虫攻击。 - 复杂查询（如大范围 Range）。

三、解决方案

3.1 大 Key 优化策略

1. 清理数据：定期清理 List/Set 中的无效旧数据。
2. 压缩 Value：使用 Snappy、Gzip 等算法压缩数据后再存入 Redis。
3. 拆分 Key (Split)：
   • Hash 拆分：将大 Hash 表 H_KEY 拆分为 H_KEY_1, H_KEY_2...
   • String 拆分：将大字符串切片存储。
   • 取值优化：禁止使用 HGETALL，改用 HMGET 按需获取。
4. 监控告警：利用腾讯云监控设置“内存增长率”和“带宽使用率”告警。

3.2 热 Key 优化策略

1. 读写分离：
   • 增加只读副本 (Slave/RO)，将读流量分散到多个节点。
2. 本地缓存 (Local Cache)：
   • 在应用服务器（Client）本地缓存热 Key（如 Ehcache/Guava），不再请求 Redis。
3. Key 复制 (Scatter)：
   • 将 HotKey 复制为 HotKey_1, HotKey_2... 并分布在不同分片上，客户端随机访问其中一个副本。

---

第二部分：腾讯云 NoSQL 家族

本部分导读
不同的业务场景需要不同的数据库。无论是文档、图形、时序还是向量数据，都有其专属的“神器”。

一、云数据库 MongoDB (文档型)

TencentDB for MongoDB 是基于开源 MongoDB 打造的高性能文档数据库。

• 特性：
  • Schema-free：数据结构灵活（JSON/BSON），适合快速迭代。
  • 自动分片：内置 Sharding 机制，轻松扩展至 PB 级存储。
  • 全托管：自动监控、备份、回档。
• 适用场景：
  • 游戏：存储玩家装备、属性（字段多变）。
  • 社交/内容：评论、文章、动态（非结构化）。
  • 物联网：设备日志上报。

二、云数据库 Memcached (缓存型)

TencentDB for Memcached 是高性能、纯内存的 Key-Value 存储服务。

• 特性：
  • 极简架构：纯 KV，不支持持久化（重启数据丢失），专注于极致性能。
  • 超低延迟：亚毫秒级响应，单机 QPS > 50万。
  • 多线程：相比 Redis 单线程，Memcached 多线程模型在大 Value 读写上更具优势。
• 适用场景：
  • Session 共享。
  • 简单缓存：数据库查询结果缓存、图片/页面缓存。

三、时序数据库 CTSDB (Time Series)

TencentDB for CTSDB 专为处理随时间产生的数据而设计。

• 特性：
  • 高效写入：针对时间序列数据（Append-only）深度优化。
  • 数据分层：冷热数据自动分离，降低存储成本。
  • 强大分析：支持时间窗口聚合、降采样查询。
  • 兼容性：兼容 InfluxDB 协议。
• 适用场景：
  • IoT 物联网：传感器采集、智能电表。
  • 监控运维：服务器 CPU/内存监控数据。
  • 车联网：车辆轨迹、状态上报。

四、向量数据库 VectorDB (AI 专用)

Tencent Cloud VectorDB 是面向 AI 时代的数据库，专用于存储和检索向量数据（Embeddings）。

• 特性：
  • 高性能检索：支持十亿级向量数据的毫秒级相似度检索（KNN）。
  • AI 集成：与大模型（LLM）生态无缝对接。
• 适用场景：
  • 大模型知识库 (RAG)：存储文档向量，辅助 LLM 回答问题。
  • 推荐系统：基于用户画像向量推荐相似商品。
  • 以图搜图：图片特征向量检索。

五、图数据库 KonisGraph (Graph)

TencentDB for KonisGraph 用于处理高度连接的数据。

• 特性：
  • 图模型：存储节点（Node）和边（Edge），直观表达实体关系。
  • 深层查询：高效处理多度关联查询（如“朋友的朋友的朋友”）。
  • 兼容性：支持 Gremlin 查询语言。
• 适用场景：
  • 社交网络：好友推荐、社群发现。
  • 风控反欺诈：识别资金流转闭环、关联排查。
  • 知识图谱：实体关系管理。

六、游戏数据库 TcaplusDB

TcaplusDB 是腾讯专为游戏设计的 NoSQL 数据库。

• 特性：
  • Protobuf/JSON：支持游戏常用的序列化协议。
  • 存算融合：结合了缓存的高性能（内存）和数据库的持久化（磁盘）。
  • 记录级回档：支持精确回档某个玩家的数据，不影响全服。
• 适用场景：
  • MOBA/MMORPG：王者荣耀、和平精英等海量在线游戏。

---

课程总结

知识点回顾

1. Redis 优化：大 Key 拆分+压缩，热 Key 读写分离+本地缓存。
2. NoSQL 选型：
   • 文档灵活存 MongoDB。
   • 简单高速缓存存 Memcached。
   • 监控数据存 CTSDB。
   • AI 向量存 VectorDB。
   • 社交关系存 KonisGraph。
   • 游戏数据存 TcaplusDB。

架构师实践清单 (Checklist)

• [ ] Redis 健康度：是否定期分析了 RDB 文件，排查大 Key？
• [ ] 热点防护：是否具备热 Key 自动发现和降级机制？
• [ ] 数据库选型：是否在用关系型数据库硬抗非结构化日志？（考虑 MongoDB/CTSDB）
• [ ] AI 架构：构建大模型应用时，是否引入了向量数据库作为外部知识库？

本章课程到此结束。下一章，我们将讲解 2.13 消息队列及最佳实践。