自动补全几乎是所有搜索类产品的标配功能：电商网站的商品搜索、文档站点的关键词提示、社交平台的@提及，都依赖它来提升输入效率。这类场景有一个共同特点——查询频率极高，对响应延迟极其敏感，通常要求在几毫秒内返回结果。如果每次按键都去查询关系型数据库的LIKE语句，数据库很快就会被拖垮。Redis的sorted set（有序集合）天生支持按成员字典序排序和范围读取，正好契合自动补全的核心需求。本文将从原理、数据设计、具体实现到生产优化，完整讲解如何用sorted set搭建一套可靠的自动补全服务。
一、为什么sorted set适合做自动补全
Redis的sorted set是一个由唯一成员（member）和分值（score）组成的有序结构，底层在成员较少时使用listpack（旧版本为ziplist），数据量增大后转换为跳表（skiplist）加哈希表的组合结构。跳表让成员按照score排序存放，同时当score相同时，成员本身会按字典序排列。这个特性是实现自动补全的关键：只要把所有score设为0，整个集合内的成员就会严格按照字典序组织，范围查询等价于前缀匹配。
自动补全的本质是“找出所有以某个前缀开头的词”。在字典序中，以ab开头的词一定连续排列在a开头词之后、ac开头的词之前。因此查找前缀ab的候选词，只需要定位这个前缀区间的起点和终点即可，时间复杂度是O(log N)，远优于无序集合的全量扫描。配合Redis单线程内存操作的特点，即使集合里有几十万个词条，单次查询也能稳定在1毫秒以内。
此外sorted set还天然提供了去重能力（成员唯一）和按rank分页的能力（ZRANGEBYLEX支持LIMIT参数），这两点在设计带热度排序的补全结果时非常有用。相比用数据库LIKE或者ES做前缀搜索，Redis方案在延迟和部署成本上都有明显优势，特别是候选词规模在百万级以内的场景。
二、数据设计与核心命令
设计上有两种常见思路。第一种是所有候选词放进一个大key，全部score设为0，用字典序范围查询；第二种是按前缀拆分成多个小key，例如prefix:ab、prefix:abc，每个key里存放该前缀下的候选集。大key方案结构简单，写入只需一条ZADD；前缀拆分方案查询时直接ZRANGE整个key，但写入放大严重——一个词“redis”要写入prefix:r、prefix:re、prefix:red等六个key。下面以大key方案为例演示核心用法。
import redis
r = redis.Redis(host='127.0.0.1', port=6379, db=0)
KEY = "autocomplete:terms"
def add_terms(terms):
# score统一为0，成员自动按字典序排列
mapping = {term: 0 for term in terms}
r.zadd(KEY, mapping)
def complete(prefix, limit=10):
# 构造范围上界：把前缀最后一个字符加1
# 例如前缀"red"的范围是 [red, ree)
start = "[" + prefix
last = chr(ord(prefix[-1]) + 1)
end = "(" + prefix[:-1] + last
if prefix[-1] == chr(0x10FFFF):
end = "+"
return r.zrangebylex(KEY, start, end, start=0, num=limit)
add_terms(["redis", "redise", "redhat", "reduce", "python", "java"])
print(complete("red"))
# 输出: [b'redhat', b'redis', b'redise', b'reduce']
ZRANGEBYLEX的区间语法需要特别注意：方括号表示闭区间，圆括号表示开区间。起点用“[red”表示包含red本身，终点用“(ree”表示不包含ree，这样刚好覆盖所有red开头的词。计算上界的办法是把前缀最后一个字符的码点加一，替换原字符。这个方法在绝大多数情况下正确，但要小心处理末尾字符是最大码点、多字节UTF-8字符等边界情况，代码里做了相应兜底。
如果希望按热度而非字典序返回结果，可以在写入时把score设为搜索次数，改用ZRANGEBYSCORE配合区间过滤，或者采用混合方案：先用字典序查出候选，再从热度zset中取score做内存排序。两种方式各有取舍，前者查询快但无法做前缀匹配，后者灵活但多了一次网络往返，可以用pipeline合并。
三、生产环境的坑与优化
第一个要面对的问题是中文前缀。中文字符串在Redis中按字节比较，UTF-8编码下常用汉字基本按Unicode码点顺序排列，因此“北”开头的前缀查询通常能正确工作。但如果候选词中混杂了全角符号、emoji或者用户输入包含繁简体混排，字典序就可能出现意料之外的边界问题。稳妥的做法是在应用层对输入做标准化处理（统一转小写、去空格、简繁转换），再写入和查询Redis，保证两边的编码规则一致。
第二个问题是key的体量控制。百万级词条的大key在做ZADD删除旧词时可能触发阻塞，建议用ZREMRANGEBYLEX定期清理冷词，删除操作放在低峰期执行，或者改用前缀拆分方案把压力分散到多个key上。查询端一定要加LIMIT限制返回条数，避免某个高频前缀（比如单字母）一次性拉出上万条记录把带宽打满。
def safe_complete(prefix, limit=10):
if not prefix or len(prefix) > 32:
return []
prefix = prefix.strip().lower()
# 只返回前缀合法的结果，防止恶意构造长串打爆服务
if not prefix.isalnum() and not all('\u4e00' <= c <= '\u9fff' for c in prefix):
return []
return complete(prefix, limit)
def refresh_hot_terms(term_scores):
# 用pipeline批量更新热度，减少网络往返
pipe = r.pipeline()
for term, score in term_scores.items():
pipe.zadd("autocomplete:hot", {term: score})
pipe.execute()
第三个问题是高可用与降级。Redis宕机时补全功能不应该拖垮整个搜索链路，客户端要设置合理的超时（比如50毫秒）并在异常时返回空列表或静态配置的热门词。如果补全服务QPS非常高，可以在应用本地加一层短TTL的缓存（如1秒的guava cache），把相同前缀的重复查询挡在进程内，这一层能轻松削减大半的Redis压力。
最后补充一点可观测性：对补全接口记录查询QPS、Redis延迟分位数和无结果率。无结果率偏高往往说明词库覆盖不足，需要补充词条来源；延迟抖动则可能是出现了大key或热点前缀，应结合监控及时调整拆分策略。整体而言，sorted set方案以极低的复杂度换来了毫秒级的响应速度，是中小规模自动补全场景里性价比最高的方案之一，当词条规模增长到千万级以上时，再考虑迁移到专门的搜索引擎。
Redissorted set自动补全修改时间：2026-09-04 07:16:42