冷热数据在go微服务中需按业务规则显式拆分：热数据存redis或lru缓存（ttl略大于热窗口），冷数据异步落库至postgresql分区表或clickhouse，配合brin索引与分区裁剪优化查询。
冷热数据怎么在 Go 微服务里实际拆开存？
Go 微服务里不做显式冷热分离，数据自然不会自己“变冷”或“变热”。关键在于你定义的访问模式和生命周期——比如订单创建后 7 天内高频查询，之后只用于审计或对账，这就是典型的热→冷分界点。拆分不是靠框架自动识别，而是靠业务规则+存储路由逻辑。
-
hot_data存 Redis 或本地 LRU（如lru.Cache），TTL 设为略大于业务热窗口（比如 8 天） -
cold_data落盘到 PostgreSQL 分区表或 ClickHouse，按时间字段（如created_at）做范围分区 - 拆分动作发生在写入路径：先写热库，再异步发消息到队列（如 Kafka），由独立消费者写冷库存档
- 切记不要在 HTTP handler 里同步写两套存储，否则延迟翻倍、失败难回滚
为什么用 Redis 做热数据缓存反而更慢？
常见现象：GET /order/123 接口 P99 从 20ms 突增到 300ms，查下来是 Redis GET 耗时飙升。根本原因不是 Redis 本身，而是 Go 客户端配置和使用方式踩了坑。
-
redis.Client必须复用，每次 new 一个 client 会新建 TCP 连接池，连接数爆炸且无法复用连接 -
Timeout和ReadTimeout必须显式设小（如 50ms），否则网络抖动时 goroutine 卡死在conn.Read() - 不要用
pipeline包一堆无关 key，单次 pipeline 超过 10 个命令就容易触发 Redis 阻塞，不如并发几个GET - 如果热数据结构复杂（如嵌套 map），避免用
json.Marshal存字符串，改用msgpack序列化，体积小 30%、解码快 2 倍
PostgreSQL 冷表查询越来越卡？试试分区 + BRIN 索引
冷数据量上亿后，SELECT * FROM orders WHERE created_at > '2023-01-01' 变慢，不是因为没加索引，而是 B-tree 索引在超大表上维护成本高、缓存命中率低。
- 按月分区：
CREATE TABLE orders_2023_01 PARTITION OF orders FOR VALUES FROM ('2023-01-01') TO ('2023-02-01') - 在
created_at上建BRIN索引（不是 B-tree）：CREATE INDEX idx_orders_created_at_brin ON orders USING BRIN (created_at)，内存占用只有 B-tree 的 1/100，适合时间序列类冷数据 - 查询时确保
enable_partition_pruning = on（默认开启），否则 PG 会扫所有分区 - 避免在分区键上用函数，比如
WHERE date_trunc('month', created_at) = '2023-01-01'会让分区裁剪失效，直接改用范围查询
Go 里怎么安全地把热数据降级到冷存储？
降级不是“删缓存+写冷库”，而是带版本和状态的原子切换。常见错误是缓存刚删，冷库还没写完，这时新请求直接穿透到 DB，雪崩。
立即学习“go语言免费学习笔记（深入）”；
- 给每条热数据加
version字段（int64），冷热库都存；热库更新时 version 自增，冷库写入成功后再更新热库的is_hot = false - 用
sync.Once控制单条数据的首次冷写，避免并发重复落库 - 降级触发时机别只看时间，加一层访问频次判断：过去 1 小时
GET次数 - 冷写失败必须有重试+告警，但重试不能用指数退避塞满队列，建议用带 TTL 的延迟队列（如 PostgreSQL
pg_cron或 RedisZSET）
冷热分离真正难的不是代码怎么写，是业务边界得划清楚——哪个字段必须热？冷数据是否允许分钟级延迟？这些一旦模糊，后面所有优化都会在某个凌晨三点变成线上事故。
