如何在Golang中通过自定义序列化函数将多维数组扁平化存入Redis

你可能会想，直接用 json.Marshal 把多维数组序列化后扔进 Redis，不是挺省事吗？但实际跑起来问题不少。Go 的 json.Marshal 在处理 []interface{} 或嵌套 slice 时，遇到 nil 元素、混合类型（比如 []interface{}{1, "a", []int{2, 3}}）或多层指针，很容易翻车。更要命的是，Redis 根本不懂 JSON 结构，你存进去的只是一串字节流，后续想按“某一层子数组”做范围查询或原子更新，根本无从下手。这里的关键不是“怎么序列化”，而是按业务语义进行可控的扁平化——把多维关系映射成一组带前缀的 key-value 对。

为什么不能直接用 json.Marshal 存多维数组到 Redis

说白了，json.Marshal 的通用序列化方案，在 Redis 面前就是个“黑盒”。你存进去的是字节流，Redis 不会帮你解析 JSON 里的嵌套关系。那当你需要单独操作某个子元素，比如更新第 2 行第 3 列的值，或者查询所有第 1 列大于 100 的行，就会陷入“先全量读取、反序列化、修改、再全量写入”的尴尬循环。这不仅效率低，还容易在并发场景下出现数据不一致。所以，真正的解决方案是：放弃通用序列化，按照业务需求，把多维数组“拍平”成 Redis 能理解的 key-value 结构。

用 redis.Pipeline + 自定义键生成函数批量写入

假设你有一个 [][]string，想存成类似 user:123:tags:0、user:123:tags:0:0、user:123:tags:0:1 这样的结构。这就需要你自己拆解维度，并设计 key 的命名规则。这个环节有几个坑要避开：

• 不要用冒号 : 做唯一分隔符。如果原始数据本身包含 :（比如时间戳或 URL），解析时就会产生歧义。建议使用不可见字符如 \x00，或者固定长度编码（如 00001 表示索引 1）。
• 写入操作必须用 pipeline。单个 SET 命令的网络开销很大，而且无法保证原子性。redis.Pipeline 可以把多个命令合并成一次请求，失败时整批回滚，性能和安全都有保障。
• 千万别在循环里反复调用 client.Set。每次调用都涉及建连接、发命令，性能会差一个数量级。

// 示例：扁平化 [][]string 到 redisfunc flattenAndStore(client *redis.Client, baseKey string, data [][]string) error {pipe := client.Pipeline()for i, row := range data {rowKey := fmt.Sprintf("%s:%d", baseKey, i)pipe.Set(rowKey, len(row), 0) // 存长度，方便后续读取时预分配for j, item := range row {itemKey := fmt.Sprintf("%s:%d:%d", baseKey, i, j)pipe.Set(itemKey, item, 0)}}_, err := pipe.Exec()return err}

读取时如何还原多维结构而不爆内存

读取是另一个挑战。Redis 没有类似“获取所有 user:123:tags:*:*”的原生命令。KEYS 在生产环境是被禁用的，因为它会阻塞主线程。必须用 SCAN 命令，但 SCAN 返回的 key 是无序的，你需要靠 key 的命名规则来重建索引关系。

• 先使用 SCAN 匹配 baseKey + ":*" 获取所有行 key，再对每个行 key 扫描其下的 ":*" 子项。两层 SCAN 是安全的，但要注意游标管理，避免遗漏或重复。
• 不要一次性 GET 所有子项。如果某行有上万列，pipe.Get(...) 会把全部值加载进内存，很容易导致 OOM。应该按需分页，或者改用 HGETALL，把每行存成 Hash（更适合列数固定的场景）。
• 注意 TTL 的设置。如果给每个子 key 单独设过期时间，容易出现“行头存在但子项已过期”的脏数据。推荐的做法是：只给顶层 key（如 user:123:tags）设 TTL，子项共享这个过期时间。

用 redis.HSet 替代多层 key 的适用边界

如果你的多维数组本质上是“固定列名的二维表”（比如 []map[string]string），直接用 HSET user:123:profile name "Alice" age "30" 会更合适。Hash 天然支持字段级读写，不存在的字段会自动忽略，而且 HGETALL 返回有序 map，比拼接 key 省事得多。

• 只有当需要按“某列范围”查询时（比如“所有第 2 列值 > 100 的行”），才值得用多 key 方案。否则，就是在给自己增加复杂度。
• Hash 不支持嵌套结构。HSET user:123:tags 0 "go" 1 "rust" 可以，但 HSET user:123:nested 0:0 "a" 会被当成字符串字段名，Redis 不会解析里面的冒号。
• 如果一定要嵌套，可以考虑用 json.RawMessage 存储最内层数组，外层用 Hash 字段控制维度。这样既兼顾了可读性，又实现了扁平化。

说到底，真正的难点从来不是“怎么存”，而是“以后怎么删其中一行”或者“怎么给第 i 行第 j 列加个过期时间”。这些操作在 key 命名方案里，全得手动推导。漏掉一个 DEL，就会留下孤儿数据，成为隐患。