用户行为轨迹指的是用户在应用内产生的一系列动作序列，例如浏览商品、加入购物车、提交订单、点击广告等。这些数据对推荐系统、用户画像、风控排查都有重要价值。与之对应的技术挑战在于写入频率高、数据量增长快，还需要支持按时间范围快速查询。如果直接使用关系型数据库存储所有行为流水，写入压力和后续清理成本都会很高。Redis凭借其内存特性和丰富的数据结构，成为记录用户行为轨迹的常用中间件。
为什么Redis适合记录用户行为轨迹
用户行为轨迹的典型特点是写入密集。一个中型电商应用在促销期间，可能每秒产生数千次页面浏览、点击和加购操作。这些数据如果不加区分地写入MySQL，会迅速占满连接池，并且频繁的磁盘写入会让数据库的响应时间大幅上升。Redis把所有数据保存在内存中，单线程处理命令的方式避免了锁竞争，同时网络IO多路复用机制使其能够支撑极高的并发写入。
除了性能优势，Redis的数据结构也让轨迹存储更加灵活。例如有序集合（Sorted Set）可以天然按时间戳排序，列表（List）适合维护最近N条记录的队列，哈希（Hash）适合存储用户维度的行为汇总，而Stream类型则能充当轻量级的消息日志。这些结构都支持原子操作，开发者不需要额外维护索引或版本号，就能在写入的同时完成去重、截断和过期清理。对于需要快速上线行为追踪功能的团队来说，使用Redis可以明显降低开发复杂度。
核心数据结构与写入模型设计
记录用户行为轨迹前，首先要明确查询场景。如果是展示用户最近浏览过的20个商品，那么使用列表或有序集合就很合适。列表可以通过LPUSH从左侧插入最新行为，再用LTRIM裁剪到指定长度，保证每个用户的键不会无限增长。下面这段Python代码演示了如何记录并裁剪最近50条浏览记录。
import redis
import time
client = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)
def record_view(user_id, product_id):
key = f"user:{user_id}:recent_views"
timestamp = time.time()
# 使用有序集合，score为时间戳，member为商品ID
client.zadd(key, {product_id: timestamp})
# 只保留最近50条，按时间戳从旧到新排序，删除多余的旧记录
client.zremrangebyrank(key, 0, -51)
# 设置过期时间，防止冷用户数据长期占用内存
client.expire(key, 86400 * 30)
如果需要按行为类型分别记录，比如区分浏览、收藏、加购，可以使用哈希表存储每个行为类别的列表序列。例如键user:1001:actions中，字段view对应一个JSON数组或逗号分隔的字符串。但更推荐的做法是为每种行为类型建立独立的有序集合键，例如user:1001:view、user:1001:cart、user:1001:collect，这样查询某一类行为时不用解析整个用户的所有轨迹。写入时通过ZADD命令以时间戳为score，商品或内容ID为member，天然去重且排序。
对于需要保留完整流水、支持按时间范围拉取的场景，Stream类型是更好的选择。Stream内部维护自动递增的消息ID，支持消费者组和范围查询XRANGE。一条行为记录可以作为一条消息写入Stream，消息体中包含行为类型、目标对象、发生时间和上下文信息。与List相比，Stream不会因为消费者读取而丢失数据，更适合作为后续异步分析的数据源。但Stream的持久化开销略高，需要根据实际写入量评估内存和磁盘压力。
查询优化与过期清理策略
轨迹数据写入后必然面临查询。有序集合支持ZREVRANGE按score倒序获取最新的N条记录，也支持ZRANGEBYSCORE按时间范围过滤。当用户数量庞大时，每个用户的轨迹键都可能成为热键，尤其是活跃用户。一种常见的优化手段是对活跃用户和沉默用户设置不同的过期时间。活跃用户的数据可以在内存中保留更久，沉默用户则设置较短的TTL，例如7天后自动删除。这样既能保证活跃用户的体验，又能控制整体内存水位。
清理过期数据不能等到内存满了才处理。Redis提供了主动过期和惰性删除机制，但对于行为轨迹这种持续写入的场景，大量键同时过期可能引发短暂的阻塞。更好的办法是在写入时顺便清理旧数据，例如使用ZREMRANGEBYSCORE删除早于某个时间戳的记录，或者用ZREMRANGEBYRANK保留固定数量。如果业务允许，还可以在低峰期通过Lua脚本批量扫描并删除过期键。下面是一个在写入有序集合时同步清理30天前数据的示例。
import redis
import time
client = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)
def record_with_cleanup(user_id, product_id, action_type):
key = f"user:{user_id}:{action_type}"
now = time.time()
thirty_days_ago = now - 86400 * 30
# 使用Lua脚本保证原子性：先写入新行为，再清理30天前的旧记录
lua_script = """
redis.call('ZADD', KEYS[1], ARGV[2], ARGV[1])
redis.call('ZREMRANGEBYSCORE', KEYS[1], '-inf', ARGV[3])
redis.call('EXPIRE', KEYS[1], ARGV[4])
return 1
"""
client.eval(lua_script, 1, key, product_id, now, thirty_days_ago, 86400 * 30)
查询优化方面，尽量避免一次性拉取大量记录。如果产品需求是分页展示用户轨迹，可以利用有序集合的rank范围进行分页，而不是把所有数据取回客户端再截断。对于跨用户的行为统计，例如某个商品被多少用户浏览过，则需要维护反向索引，例如以商品ID为键的有序集合或集合类型，记录所有浏览过该商品的用户。这种双向存储会增加写入成本，但能大幅提升统计查询的效率。决定是否维护反向索引，取决于统计查询的频率是否足够高，否则不如使用离线计算。
生产环境中的常见问题与应对
Redis作为内存数据库，数据安全性天然弱于磁盘数据库。如果服务器重启且未正确配置持久化，用户行为轨迹可能全部丢失。通常建议开启AOF持久化，并设置合理的刷盘策略。对于轨迹数据，如果业务能容忍少量丢失，可以选择appendfsync everysec，每秒同步一次，既保证性能又不会在每次写入时都触发磁盘IO。RDB持久化可以作为冷备份，但因其快照间隔较长，不适合作为实时轨迹的唯一保障。此外，混合持久化可以在重写AOF时减少体积，值得在生产环境开启。
另一个常见问题是热Key。某些超级用户或热门商品的行为轨迹键会被大量并发读写，导致Redis实例的CPU不均匀。解决方法包括对热Key进行分片，例如在键后增加哈希桶编号，将用户ID映射到多个子键；或者在应用层增加本地缓存，减轻Redis的压力。但本地缓存会增加一致性维护成本，只适合读取频繁、数据变化不敏感的场景。对于写入热Key，可以通过异步批量写入来缓解，但要注意批量窗口内数据延迟。
内存碎片也是需要关注的指标。行为轨迹中键的生命周期差异较大，频繁创建和删除键容易造成内存碎片。可以定期执行MEMORY DOCTOR检查碎片率，必要时通过重启或开启activedefrag参数进行整理。不过自动碎片整理本身会消耗CPU，建议在低峰期触发。如果内存实在紧张，应优先考虑将冷数据迁移到磁盘型数据库或对象存储中，Redis只保留近期热数据，形成冷热分离的存储架构。
Redis用户行为轨迹用户行为记录Redis数据结构修改时间：2026-09-25 10:45:25