Redis学习笔记（九）redis实现时时直播列表缓存,支持分页[热点数据存储]

最新推荐文章于 2024-11-07 08:00:00 发布
原创 最新推荐文章于 2024-11-07 08:00:00 发布 · 1.4w 阅读 · 21 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #架构设计

本文介绍使用Redis有序集合实现直播列表的缓存方案。针对实时性和热点数据特性，采用Redis有序集合存储直播数据，支持高效分页及避免重复数据。通过Lua脚本确保并发安全，并讨论缓存数量控制策略。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

redis系列文章目录

需求说明

在直播平台中，用户查看直播列表，这个列表数据具有时时性，并且是强热点数据，也就是说每时每刻都可能会有新的直播。这些数据如果每次都去数据库读取肯定是不可取的，所以这可以考虑使用redis来实现。

使用redis有序集合来保存直播列表

思路简介

由于每时每刻都有可能会有新的数据进入到sortedset中，所以使用redis的有序集合进行存储。之所以是使用有序集合是考虑到翻页的时候不要有重复数据，如果需求允许重复数据的出现，则可以使用先进先出队列queue。

重复数据出现原因：假如用户当前再看第一页的数据，此时又有两条新数据插入到sortedSet中，那么如果用zrevrange(key, pageSize*pageNum, pageSize*(pageNum+1)进行取值，就会出现2条重复数据了

每生成一条数据，将其添加到redis有序集合中，根据ID（如果id是数值型的）或者时间戳（这个要进行处理，后面会讲）进行排序。取的时候通过以下方法进行取值。

Set<String> zrevrangeByScore(final String key, final double max, final double min, final int offset, final int count)

假如每页5条数据：
第一页：jedisCluster.zrevrangeByScore(key , Double.MAX_VALUE , 0, 0 , 5)
记录第一页中后一条数据的score是M
第二页：jedisCluster.zrevrangeByScore(key , M , 0 ,1, 5)
以此类推。

我这里使用的jedisCluster客户端

如何保证sortedSet集合数量

假如只缓存100条数据，每页10条显示。我们可以采取缓冲区策略，就像redis中保存字符串时使用的SDS动态字符串。我们可以每次在保存的时候检测set的大小zcard，如果zcard超过了120（允许多缓存20个，这样可以减少截取set的操作次数，提高效率），则可以使用以下命令进行截取至100：

jedisCluster.zremrangeByRank(key, 0, jedisCluster.zcard(key)-100)

并发安全

上面的策略存在并发安全问题，它包含两步：
1. 插入数据到set中。
2. 查询sortedSet大小，判断是否大于120
3. 如果大于120，则进行zremrangeByRank操作。

如果在高并发的环境中很容易多次执行zremrangeByRank。

  • 解决办法：

使用lua脚本，将上面操作写到lua脚本中。在lua脚本中执行的操作是原子性的，是线程安全的。不过要注意redis在执行lua脚本时是不可以处理其他请求的

翻页超过了缓存大小

这种情况的话就可以考虑到数据库中查询，或者走搜索引擎，毕竟用户看的最多的还是前几页的数据。具体要缓存多少数据要根据实际业务进行计算.

简述什么是缓存热点数据和冷数据 ？
weixin_39291964的博客
06-25 68
短时间内被高频访问的数据，通常承载系统80%以上的请求量（二八定律）[citation:1][citation:3][citation:6]。
redis存储List集合
06-16
用C#Winform做的一个上传excel，读取excel内容然后将其存储到redis的一个小demo,一个好用的地方就是读取excel的方法，公用的~
redis 存储列表
love_521_的博客
03-17 873
lpush key value #添加元素 lrange key start stop #查看列表中元素，返回列表key中指定区间的元素，区间以偏移量start和stop制定，如果从左边第一个到最后一个 lrange key 0 -1 #移除列表中的元素 #移除并返回列表key的头元素 lpop key #移除并返回列表的尾元素 blpop key #列表中没有值，可以阻塞住 rpop key #移除并返回列表key的中间元素 lrem key count value eg:lrem username
Redis存储结构之列表（List）
大道至简
11-23 3315
经典场景：消息队列 Redis列表只是字符串列表，按插入顺序排序。您可以向Redis列表的头部或尾部添加元素。 常用的方法有：lpush、rpush、lpop、rpop、blpop、brpop、lrange BLPOP BRPOP BRPOPLPUSH LINDEX LINSERT LLEN LPOP LPUSH LPUSHX LRANGE LREM LSET LTRIM RPOP RP...
Redis--------Java Redis存储对象列表
LJH_java10086的博客
10-03 1448
需要注意的是，Java序列化不是最优的序列化方式，因为它会产生较大的对象存储和传输负担。另外，如果使用Jackson等JSON序列化库，我们可以将对象列表序列化为JSON格式，具有更好的可读性和可测试性。Java Redis可以使用Java序列化的方式存储对象列表。
redis数据类型-列表(List)
weixin_43919497的博客
06-03 293
菜鸟教程：https://www.runoob.com/redis/redis-lists.html 简介 Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。 它的底层采用的是双向链表所以对两端的操作性能很高，通过索引下标的操作节点性能会很差。 常用命令 # 从左边/右边插入一个或多个值。 lpush/rpush <key> <value1> <value2> <value3> .... # 从
黑马点评Redis学习笔记
weixin_43982558的博客
07-18 1826
项目是前后端分离，不是微服务缓存可以减少后端负载，减少相应时间，但会带来数据一致性成本，也会引入缓存穿透击穿等问题redis在电商秒杀中扮演重要角色在某些情况下使用自增ID不好，需要使用全局ID生成器生成唯一ID好处有：1，避免ID被猜测到，2，方便分布式分多个表扩充数据（否则ID会重复发生冲突）全局ID需要满足这些特性，而Redis正好都符合这些要求，所以可以用Redis来做对于分布式系统来说，或许有多个数据库，但Redis作为中间件只有1个（或集群），可认为它是唯一的。
Redis学习笔记
weixin_43691773的博客
10-18 393
Redis学习笔记 文章目录Redis学习笔记一、NoSql入门及概述1.是什么2.作用（1）易扩展（2）大量数据高性能（3）多样灵活的数据模型（4）传统的RDMS vs NOSQL3.NoSQL数据库的四大分类对比二、Redis介绍1.是什么2.Redis 优势三、Redis的安装1、Redis 在window的安装1、Redis 在Linux的安装三、Redis解析配置文件1.Units 单位2.INCLUDES 包含3.常见配置redis.config介绍四、Redis 的java客户端 Jedis五
C# Redis学习笔记
weixin_41470202的博客
02-21 778
介绍：Redis 是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。Redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。补充：支持存储的value类型相对更多，包括string、list、set、zset(sortedset –有序集合) 和hash(哈希类型)。在此基...
苍穹外卖项目解读(三) redis、cache缓存解读
代码的尽头都是数学
08-01 3173
redis cache
Redis系列-06 Redis性能优化实战与常见面试题解析：缓存策略、架构调优与热点问题
yangwei2048的博客
08-04 388
本文介绍了Redis性能调优的多种策略，主要包括：合理设置键值过期时间，利用惰性删除节约内存；启用Redis 4.0的lazy free特性，将删除操作放在子线程中执行，避免阻塞主线程；设置内存上限并配置淘汰策略，详细分析了LRU和LFU算法原理及适用场景；建议禁用时间复杂度高的查询命令。文章还提供了具体配置示例，帮助读者根据业务需求选择最适合的优化方案，以提升Redis的运行效率和稳定性。
Redis - List 列表
ketil27的博客
11-07 3191
列表类型是⽤来存储多个有序的字符串，如图2-19所⽰，a、b、c、d、e五个元素从左到右组成 了⼀个有序的列表，列表中的每个字符串称为元素（element），⼀个列表最多可以存储 2^32 − 1 个元 素。在Redis中，可以对列表两端插⼊（push）和弹出（pop），还可以获取指定范围的元素列表、 获取指定索引下标的元素等（如图2-19和图2-20所⽰）。列表是⼀种⽐较灵活的数据结构，它可以 充当栈和队列的⻆⾊，在实际开发上有很多应⽤场景。
Redis - list 列表
q322359的博客
03-24 1384
列表类似于 Java 中的数组或者顺序表，在 Redis 中，可以对列表两端插⼊（push）和弹出（pop），还可以获取指定范围的元素列表、 获取指定索引下标的元素等。列表是⼀种⽐较灵活的数据结构，它可以充当栈和队列的⻆⾊，在实际开发上有很多应⽤场景。：list 内部的编码方式并不是一个简单的数组，更接近于双端队列。
Redis之List列表
tq02的博客
07-17 1168
Redis的列表结构讲解，命令和内部编码！
【Redis】Redis数据结构——List列表
zxj20041003的博客
08-23 1248
列表类型是⽤来存储多个有序的字符串，如图 2-19 所⽰，a、b、c、d、e 五个元素从左到右组成了⼀个有序的列表，列表中的每个字符串称为元素（element），⼀个列表最多可以存储 个元素。在 Redis 中，可以对列表两端插⼊（push）和弹出（pop），还可以获取指定范围的元素列表、获取指定索引下标的元素等（如图 2-19 和图 2-20 所⽰）。列表是⼀种⽐较灵活的数据结构，它可以充当栈和队列的⻆⾊，在实际开发上有很多应⽤场景。
Redis 数据类型list（列表）
weixin_47363690的博客
10-11 1869
Redis 的列表（List）是一种数据结构，它按照插入顺序存储字符串元素。列表是有序的，这意味着元素在列表中的位置是有意义的，并且可以被索引。列表非常适合用来实现队列和栈这样的数据结构。
Redis之快速列表
凯凯王的技术生涯
12-11 199
文章目录早期实现Quicklist压缩深度 早期实现 Redis早起版本存储list列表数据结构使用的是压缩列表ziplist和普通的双向链表linkedlist，也就是少时用ziplist，多时用linkedlist 链表的附加空间相对较高，prex和next指针要占去16字节（64bit系统的指针是8个字节） 每个节点内存单独分配，加剧内存的碎片化，影响内存管理效率 Quicklist 后续版本中采用quicklist代替了ziplist和linkedlist。 代码如下 struct ziplis
Redis核心原理与实践--列表实现原理之ziplist
binecy
09-19 422
列表类型可以存储一组按插入顺序排序的字符串，它非常灵活，支持在两端插入、弹出数据，可以充当栈和队列的角色。 > LPUSH fruit apple (integer) 1 > RPUSH fruit banana (integer) 2 > RPOP fruit "banana" > LPOP fruit "apple" 本文探讨Redis中列表类型的实现。 ziplist 使用数组和链表结构都可以实现列表类型。Redis中使用的是链表结构。下面是一种常见的链表实现方式adlist
Redis实战（七）-列表
专注基础架构领域
09-16 242
列表（list）类型是用来存储多个有序的字符串，如图2-18所示，a、b、c、d、e五个元素从左到右组成了一个有序的列表，列表中的每个字符串称为元素（element）。在Redis中，可以对列表两端插入（push）和弹出（pop），还可以获取指定范围的元素列表、获取指定索引下标的元素等。列表是一种比较灵活的数据结构，它可以充当栈和队列的角色，在实际开发上有很多应用场景。 1、新增 （1）从右边插入元素 rpush key value [value .....
springboot+redis项目，帮我实现用户发布的笔记内容使用feed流的智能排序模式，在每次用户登录后，依据用户的爱好推送相关的笔记
最新发布
02-21
<think>嗯，我现在要做一个基于Spring Boot和Redis的项目，实现用户发布的笔记内容使用feed流的智能排序，每次用户登录后根据他们的爱好推送相关笔记。这个需求听起来有点挑战，不过我来慢慢理清楚思路。 首先，我需要理解什么是feed流。Feed流通常指的是像社交媒体那样，用户可以看到动态更新的内容列表，比如微博的时间线或者抖音的推荐流。智能排序的话，应该是指根据用户的兴趣对内容进行排序，优先展示他们可能更感兴趣的内容。 用户发布的笔记需要被存储，然后在用户登录时按照他们的爱好推送。所以，首先得有个用户模型，记录他们的兴趣爱好。可能需要在用户注册或设置的时候收集这些信息，或者通过分析用户行为动态收集，比如他们点赞、收藏的笔记类型。 接下来，笔记的内容也需要有标签或者分类，这样才能和用户的兴趣匹配。例如，每个笔记可能有多个标签，比如“科技”、“美食”、“旅游”等。用户的兴趣可能也是这些标签中的一个或多个，或者根据他们的行为动态计算出来的权重。 然后是Feed流的存储和排序问题。Redis在这里可能用来缓存用户的feed流，因为它的高性能和数据结构适合这种场景。比如，可以使用Sorted Set来存储每个用户的feed流，score代表排序的权重，根据用户的兴趣匹配度来计算这个score。 那如何计算每个笔记对于用户的推荐权重呢？可能的因素包括：笔记标签与用户兴趣的匹配度、笔记的发布时间（新内容可能更优先）、互动量（点赞、评论数）等。可能需要一个算法来综合这些因素生成一个分数，作为排序的依据。 具体步骤可能如下： 1. 用户注册/登录时，收集或更新他们的兴趣标签。比如用户选择了喜欢“科技”和“旅游”，或者系统根据他们的行为分析出兴趣权重。 2. 当用户发布笔记时，为笔记打上相应的标签。这一步可能需要自然语言处理来自动提取关键词，或者让用户手动选择标签。 3. 当笔记被发布后，系统需要将这条笔记推送给可能感兴趣的用户。这里有两种模式：推模式（写时扩散）和拉模式（读时扩散）。推模式是在发布时就将笔记插入到各个可能感兴趣用户的feed流中，适合用户量不大的情况；拉模式是用户登录时再去查询所有相关笔记并排序，适合用户量大但数据量大的情况。这里可能需要结合两者，或者根据项目规模选择。 4. 使用Redis存储每个用户的feed流，使用Sorted Set结构，其中成员的score是计算出的推荐分数。当用户登录时，直接从Redis中按照score倒序获取前N条笔记。 那么如何实时计算每个用户的兴趣分呢？比如，用户的兴趣可能存储为一个哈希表，记录每个标签的权重。笔记的标签也会有权重，或者至少是存在的标签。当笔记发布后，系统需要计算该笔记与每个用户的兴趣匹配度，然后更新到相应用户的Sorted Set中。 例如，用户A的兴趣是{"科技": 0.8, "旅游": 0.5}，笔记B的标签是“科技”，那么匹配度可能是0.8。再加上笔记的其他因素，比如时间戳转换为分数（比如发布时间越新，分数的一部分越高），互动量的权重等，综合计算出总分。然后，这个总分作为Sorted Set的score，将笔记B加入到用户A的feed流中。 不过这样的计算可能在发布时对所有用户进行计算，这样会不会很耗资源？比如，如果有一百万用户，每个笔记发布都需要遍历所有用户计算匹配度，显然不可行。这时候可能需要优化，比如预先对用户分群，或者使用倒排索引。例如，维护一个标签到用户的索引，当笔记带有某个标签时，只将该笔记推送给关注该标签的用户。 或者，在用户登录的时候，拉取所有最近发布的带有用户兴趣标签的笔记，并进行实时排序。这时候可能需要结合数据库查询和Redis缓存。比如，用户登录时，根据他的兴趣标签去查询最近一段时间内的相关笔记，然后根据算法计算每个笔记的推荐分数，并排序返回。为了提升性能，可以将结果缓存到Redis中一段时间，或者使用Redis来存储这些计算后的分数。 不过这样的话，每次用户登录都需要进行一次计算，可能会影响响应时间。这时候可能需要异步处理，比如定期（比如每小时）预计算用户的feed流，并存储到Redis中，用户登录时直接获取。但这可能会影响实时性，新发布的笔记不会立即出现在feed流中。 所以需要权衡实时性和性能。可能采用混合的方式：推模式用于实时性高的部分，比如用户关注的作者的新笔记，而拉模式用于基于兴趣的推荐，通过预计算或异步任务更新Sorted Set。 另外，关于Redis的数据结构，每个用户维护一个Sorted Set，其中保存笔记ID和对应的分数。当需要获取feed流时，使用ZREVRANGE命令按分数从高到低获取。 具体实现步骤可能如下： 1. 用户兴趣建模： - 用户表中有兴趣标签字段，或者单独的用户兴趣表，记录用户对不同标签的权重。 - 可以通过用户行为（如点赞、收藏、点击）动态更新兴趣权重。 2. 笔记标签提取： - 笔记发布时，提取标签，并存储到数据库中。 3. Feed流生成： - 当新笔记发布时，根据笔记的标签，找到可能感兴趣的用户，计算每个用户的推荐分数，并将笔记ID和分数添加到相应用户的Sorted Set中。 - 或者，使用定时任务，定期为每个用户生成最新的feed流，将符合条件的笔记计算分数并存入Redis。 4. 用户登录时，从Redis中获取自己的Sorted Set中的笔记ID，按分数排序，再查询数据库获取笔记详情。 关于计算推荐分数的具体方法，可以采用简单的加权求和，例如： 分数 = 兴趣匹配度 * w1 + 时间衰减因子 * w2 + 热度（点赞数等） * w3 其中w1、w2、w3是各因素的权重，需要根据实际情况调整。 时间衰减因子可以使用如：1 / (1 + 时间差（小时）)，或者指数衰减如e^(-λ * 时间差)，让新发布的笔记分数更高。 热度可以取笔记的点赞数、评论数等，进行归一化处理。 兴趣匹配度可以通过计算用户兴趣标签与笔记标签的余弦相似度，或者简单相加用户对应标签的权重。 比如，笔记的标签是["科技", "旅游"]，用户的兴趣权重是{"科技":0.8, "旅游":0.5}，那么匹配度可以是0.8 + 0.5 = 1.3，或者取平均等。 具体实现时，可能需要将标签存储为向量，然后计算相似度，但可能比较复杂。初期可以简化处理，比如只计算共有标签的权重之和。 举个例子，假设用户A的兴趣权重是{"科技":0.8, "旅游":0.5}，笔记B的标签是["科技", "美食"]，则匹配度为0.8（因为只有"科技"匹配），而如果另一个笔记C的标签是["旅游", "摄影"]，则匹配度0.5。这样，B的匹配度高于C，所以B的分数更高。 当然，这只是一个简单的例子，实际可能需要更复杂的算法，比如协同过滤、机器学习模型等，但对于初期项目，可能先用简单方法实现，再逐步优化。 现在考虑技术实现： Spring Boot项目结构： - 用户服务：处理用户信息、兴趣标签的获取和更新。 - 笔记服务：处理笔记的发布、存储、标签提取。 - Feed流服务：负责生成和获取用户的feed流。 - Redis：存储用户的feed流Sorted Set。 当用户发布笔记时，笔记服务保存到数据库，并提取标签。然后，触发一个事件，比如RabbitMQ消息，通知Feed流服务有新笔记需要处理。 Feed流服务接收到新笔记事件后，根据笔记的标签，查询所有可能有兴趣的用户（比如，用户的兴趣标签与笔记标签有交集），然后为每个用户计算该笔记的推荐分数，并将笔记ID和分数添加到相应用户的Sorted Set中。 这里的问题是如何高效地找到对某笔记感兴趣的用户。如果用户量很大，逐个检查每个用户的兴趣标签是否与笔记标签匹配会很慢。这时候可能需要使用倒排索引，比如在Redis中维护一个标签到用户ID的集合。例如，每个标签对应一个Set，保存所有关注该标签的用户ID。当笔记带有标签A、B时，取出这些标签对应的用户集合，合并去重，得到目标用户列表。 例如，当笔记的标签是“科技”和“旅游”，则从Redis的“tag:科技”和“tag:旅游”这两个Set中取出所有用户ID，合并去重，然后这些用户就是需要推送的目标用户。 这样，在用户更新他们的兴趣标签时，需要同步更新对应的标签用户集合。例如，当用户A添加了兴趣标签“科技”，则将他/她的ID添加到“tag:科技”的Set中。 这样，当处理新笔记时，可以快速找到需要推送的用户列表。 然后，为每个用户计算该笔记的分数，并将笔记ID添加到他们的Sorted Set中。同时，可能还需要限制每个用户的Sorted Set的大小，比如只保留最近的1000条，避免内存占用过大。 当用户登录时，调用Feed流服务，从Redis中获取他们的Sorted Set中前N条笔记ID，然后查询笔记服务获取详细信息，返回给客户端。 至于计算分数，可以设计一个ScoreCalculator组件，根据笔记的标签、时间、热度，以及用户的兴趣权重，计算出一个综合分数。 例如，分数计算： score = (用户兴趣权重总和) * 兴趣权重系数 + (发布时间的时间衰减分数) * 时间系数 + (笔记点赞数 / 最大点赞数) * 热度系数 其中，各系数可以配置，根据AB测试调整。 时间衰减分数可以使用如：Math.exp(-0.1 * hoursSincePublished)，或者类似方法，让新笔记的分数更高。 具体实现时，当处理新笔记，对于每个目标用户，需要获取该用户的兴趣权重，比如从用户服务中获取，或者从Redis缓存中获取。 可能的优化点： 1. 用户兴趣权重可以缓存在Redis中，避免频繁查询数据库。 2. 使用消息队列异步处理笔记的推送，避免阻塞主流程。 3. 分页获取feed流，避免一次性加载过多数据。 4. 定期清理Redis中的旧数据，比如只保留最近一周的笔记在Sorted Set中，过期的自动删除，可以通过设置ZREMRANGEBYSCORE来实现。 可能遇到的问题： - 用户兴趣标签的更新如何同步到倒排索引（标签到用户的Set）中。比如用户修改了兴趣标签，需要从旧的标签Set中移除，添加到新的标签Set中。 - 大量用户的情况下，新笔记的推送处理可能耗时较长，需要分布式处理，或者批量处理。 - 分数计算可能需要实时获取笔记的热度数据（如当前点赞数），但如果在推送时固定了分数，后续点赞如何更新分数？这可能需要在点赞时更新所有相关用户的Sorted Set中该笔记的分数，或者定期重新计算分数，这可能会比较复杂。或者，热度因素在分数中的权重较低，或者不考虑实时更新，只在推送时计算一次。 例如，当笔记发布时，根据当时的点赞数（0）计算分数，之后点赞数增加，但Sorted Set中的分数不会更新，这可能导致新的点赞无法影响排序。这时候可能需要另一种机制，比如定期刷新热门笔记的分数，或者当有点赞时，触发分数更新。不过这需要权衡系统复杂性和实时性需求。 可能对于初期版本，先不处理热度更新，只考虑发布时间和兴趣匹配度，后续再迭代加入热度因素。 总结步骤： 1. 用户兴趣管理： - 用户选择兴趣标签或系统自动分析。 - 用户兴趣存储在数据库，并缓存到Redis，同时维护标签到用户的倒排索引（Redis Set）。 2. 笔记发布： - 保存笔记到数据库，提取标签。 - 发送消息到消息队列，触发feed流处理。 3. Feed流处理： - 根据笔记标签，从倒排索引中找到目标用户。 - 对每个目标用户，计算笔记的推荐分数。 - 将笔记ID和分数添加到用户的Sorted Set中，并修剪保留最近一定数量的笔记。 4. 用户登录获取Feed流： - 从Redis中按分数倒序获取笔记ID列表。 - 查询笔记详情，返回给用户。 技术组件： - Spring Boot作为后端框架。 - Redis用于存储倒排索引和用户Feed流。 - MySQL/PostgreSQL存储用户和笔记数据。 - RabbitMQ/Kafka用于异步消息处理。 - 可能用到Spring Data Redis，JPA/MyBatis等。 示例代码结构： 用户服务： - UserController：处理用户注册、登录、兴趣标签更新。 - UserService：管理用户数据，更新兴趣标签时同步更新Redis倒排索引。 笔记服务： - NoteController：处理笔记发布。 - NoteService：保存笔记，提取标签，发送消息到队列。 Feed流服务： - FeedConsumer：监听消息队列，处理新笔记事件，计算分数并更新用户Feed流。 - FeedService：提供获取用户Feed流的方法。 Redis结构示例： - 倒排索引：SET结构，key为"tag:科技"，value为用户ID集合。 - 用户Feed流：ZSET结构，key为"user:feed:{userId}"，成员为noteId，score为推荐分数。 代码示例片段： 用户更新兴趣标签： ```java // UserService public void updateUserInterests(Long userId, List<String> tags) { // 更新数据库 userRepository.updateInterests(userId, tags); // 更新Redis倒排索引 String oldKey = "user:interests:" + userId; Set<String> oldTags = redisTemplate.opsForSet().members(oldKey); // 移除旧的标签关联 if (oldTags != null) { for (String tag : oldTags) { redisTemplate.opsForSet().remove("tag:" + tag, userId); } } // 添加新的标签关联 for (String tag : tags) { redisTemplate.opsForSet().add("tag:" + tag, userId); } // 保存当前用户的标签 redisTemplate.delete(oldKey); redisTemplate.opsForSet().add(oldKey, tags.toArray(new String[0])); } ``` 处理新笔记： ```java // FeedConsumer @RabbitListener(queues = "note.published") public void handleNotePublished(NotePublishedEvent event) { List<String> tags = event.getTags(); Set<Long> userIds = new HashSet<>(); for (String tag : tags) { Set<Long> users = redisTemplate.opsForSet().members("tag:" + tag); if (users != null) { userIds.addAll(users); } } for (Long userId : userIds) { double score = calculateScore(userId, event.getNoteId(), event.getPublishTime(), event.getTags()); redisTemplate.opsForZSet().add("user:feed:" + userId, event.getNoteId(), score); // 修剪，保留最新的1000条 redisTemplate.opsForZSet().removeRange("user:feed:" + userId, 0, -1001); } } private double calculateScore(Long userId, Long noteId, Instant publishTime, List<String> tags) { // 获取用户兴趣权重 Map<String, Double> userInterests = getUserInterests(userId); double interestScore = tags.stream() .mapToDouble(tag -> userInterests.getOrDefault(tag, 0.0)) .sum(); // 时间衰减，比如按小时计算 long hoursSincePublished = ChronoUnit.HOURS.between(publishTime, Instant.now()); double timeDecay = Math.exp(-0.1 * hoursSincePublished); // 热度，假设noteService可以获取当前点赞数 int likeCount = noteService.getLikeCount(noteId); double normalizedLikeScore = likeCount / 1000.0; // 假设最大1000 // 综合分数 return interestScore * 0.5 + timeDecay * 0.3 + normalizedLikeScore * 0.2; } ``` 获取Feed流： ```java // FeedController @GetMapping("/feed") public ResponseEntity<List<Note>> getFeed(@RequestParam Long userId) { Set<Long> noteIds = redisTemplate.opsForZSet().reverseRange("user:feed:" + userId, 0, 99); List<Note> notes = noteService.getNotesByIds(noteIds); return ResponseEntity.ok(notes); } ``` 这只是一个简化的示例，实际中需要考虑更多细节，比如异常处理、性能优化、缓存策略等。例如，用户兴趣可能存储在Redis的Hash结构中，而不是每次都查询数据库。另外，计算分数可能需要异步处理，避免阻塞消息消费者。 可能还需要考虑冷启动问题，即新用户没有兴趣标签时的推荐策略，比如推荐热门笔记或随机抽样。 此外，对于大规模用户，逐个处理每个用户的方式可能不够高效，需要考虑分批处理或使用更高效的数据结构和算法。例如，使用Redis的批量操作或者Lua脚本来优化性能。 总之，这个项目需要结合Spring Boot的业务处理、Redis的高效数据结构和异步消息机制，通过合理的算法实现智能排序的Feed流推送。</think>为了实现基于用户兴趣的智能排序Feed流，结合Spring Boot和Redis的项目可以按照以下步骤进行设计和开发： -- ### **1. 系统架构设计** - **用户兴趣模型**：记录用户的兴趣标签及权重。 - **笔记标签系统**：为每篇笔记提取关键词或分类标签。 - **Feed流生成**：根据用户兴趣实时/定时计算笔记推荐分数，存储到Redis。 - **推荐策略**：综合兴趣匹配、时间衰减、热度等因素生成排序。 --- ### **2. 技术栈** - **Spring Boot**：后端核心框架。 - **Redis**：存储用户Feed流（Sorted Set）和标签倒排索引（Set）。 - **MySQL**：存储用户、笔记数据。 - **消息队列（如RabbitMQ）**：异步处理笔记发布事件。 - **可选工具**：Spring Data JPA（数据库）、Spring Data Redis（缓存操作）。 --- ### **3. 核心实现步骤** #### **3.1 用户兴趣建模** - **存储用户兴趣** 用户注册或设置时选择兴趣标签（如“科技”“美食”），或在行为（点赞、收藏）中动态计算权重。 ```java // 用户兴趣表（示例） @Entity public class UserInterest { @Id private Long userId; private Map<String, Double> tags; // 标签及权重（如 {"科技": 0.8}） } ``` - **Redis倒排索引** 维护标签到用户的映射，加速新笔记推送时的用户匹配： ```bash # Redis结构示例 SET "tag:科技" {user1, user2, ...} SET "tag:美食" {user3, ...} ``` #### **3.2 笔记发布与标签提取** - **发布笔记时提取标签** 通过用户输入或NLP工具（如HanLP）自动提取标签： ```java @Service public class NoteService { public void publishNote(Note note) { List<String> tags = extractTags(note.getContent()); // 提取标签 note.setTags(tags); noteRepository.save(note); // 发送消息到队列，触发Feed流处理 rabbitTemplate.convertAndSend("note.published", new NoteEvent(note)); } } ``` #### **3.3 Feed流生成（推模式）** - **异步处理新笔记** 消息
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

快乐崇拜234

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值