第一次做练习项目遇到的问题

Z033

大佬们，练手的项目是个SpringCloud项目，项目中有个点赞，评论，还有优惠卷、会员、购物车。点赞，我是这样实现的：用户点一下赞就放进redis中，使用的是hash结构，key是一个like + 被点赞的作品id,域是用户的id，值是点赞类型（可以点赞也可以点踩，1是赞，2就是踩。这样就需要两个不同的key，一个记录点赞，一个记录点踩，然后要去这两个key里判断域是否存在）。用户点一下就先去Redis中看看有没有这个域，没有就将点赞的操作放到里面,重复点就删除掉这个域。点一次后就向mq发消息，然后添加到数据库。这样用户一直点赞取消也会对数据库进行操做的，而且redis中就存放这么多用户的点赞数据吗？什么时候搞到数据库里面？redis中的数据是否要删掉。还是搞个xxl-job定期将redis中的点赞信息添加到数据库？但是这样就有一个问题了，什么触发分布式定时任务？而且定时任务也会影响性能。评论我也是这样子，通过MQ将消息插入到数据库，这样虽然快速给用户反应了，但是实际上还是跟数据库交互了，而且特别频繁把？我在想知道有没有什么优化的思路和手段？会员遇到的问题是：如果用户开通会员我如何告诉知道他什么时候过期提醒他？我能想到的方案是两个：一个是通过mq。当你开通会员后就将消息放入死信队列（就是一个月后进入死信队列）。在死心队列判断你是否过期，没有过期就继续把它丢到死心队列中。过期就修改。第二个是：通过xxl-job每天定时查询用户表看看哪些用户快过期然后那个跟mq那个差不多。第一个的问题是消息积压会不会太多了。第二个每天都要做会不会太消耗性能了。有没有好的办法。最后就是购物车的问题了，这个是最头痛的。我把一个商品加入购物车就是往redis中存放数据，那如果他将那个商品+ 1呢？我什么时候把redis中的数据同步到数据库？如果是定时任务那设置的时间是多少呢？然后redis中的key是否要删掉？希望各位大佬可以帮我解决一下疑惑。我可能表达不是很清楚希望大佬指正

pjy612

首先咱不是大佬，也没参与过电商项目的，只是简单想想。

HASH结构：
   Like_作品ID1：
           用户ID1：赞或踩
           用户ID2：赞或踩
   Like_作品ID2：
           用户ID1：赞或踩
           用户ID2：赞或踩
赞和踩是互斥的吗？ 不是互斥的那可能需要多存，互斥的话 点多少次都直接写值就是了。
这种有缓存支援的数据 直接扔队列慢慢写db就是了。后端处理时 如果是一批批处理的，能归档并一下自然更好。

关于数据落库，特别频繁是多频繁？？？数据库没挂，没长时间CPU占用100%，没有高并发锁库锁表，那就不频繁。。。
害怕写数据，就不怕数据丢吗？
单机应用 负载不够的话，悠着点就算了，都上提分布式，配合缓存还怕啥。

会员过期，得看你有多少用户量。
用户量没到很大的数量级的话 每天查一下也不会有多少性能损耗。 查的内容也是 到期小于当前天数+X 天 触发一次消息就是了。
用户量非常大的话，提前塞队列，然后等着触发，触发时再检查一下，看是实际执行，还是重新塞队列看你自己了。当然如果能有手段每天再整理下队列数据，相同的并掉取最大就更好了。


购物车 就看你怎么设计了。
简单的就

Car_用户id：
       商品ID1：数量
       商品ID2：数量
增减在有必要的情况下 你可以尝试配合 redis的Lua 达到原子化命令效果。

但是单纯的+1 实际上也是前端拿最后的值传回来。不然开两个浏览器，来回切 不蛋疼了。。。

cosmos2023

谢谢分享

Z033

pjy612 发表于 2023-7-25 20:09
首先咱不是大佬，也没参与过电商项目的，只是简单想想。

HASH结构：

大佬，点赞是全部存redis中吗？因为你用户多点赞多，会占用redis中的内存吧。

pjy612

Z033 发表于 2023-8-5 11:50
大佬，点赞是全部存redis中吗？因为你用户多点赞多，会占用redis中的内存吧。

? 缓存啊，没人看到时候就没了...
另外 redis 也有自己的持久化啊。。。

Z033

pjy612 发表于 2023-8-5 16:46
? 缓存啊，没人看到时候就没了...
另外 redis 也有自己的持久化啊。。。

我把每个用户的点赞行为都存Redis中。然后数据可能过大。我把用户的点赞行为存到Redis中，使用hash缓存，然后设置域的过期时间有七天。然后七天后就不管了。

pjy612

Z033 发表于 2023-8-6 10:26
我把每个用户的点赞行为都存Redis中。然后数据可能过大。我把用户的点赞行为存到Redis中，使用hash缓存， ...

有没有可能，你读写Hash时 针对 field 操作 其实 不占用太多内存？

甚至 只是点赞的话 这种简单数据你都可以不用 hash 直接用 kv ，确保相同的前缀方便查询即可。

有必要的话  隔一段时间 刷一下缓存。
一般系统是 没有缓存的 先走全流程。
然后 如果数据量 和并发量造成系统瓶颈的话，再看哪里需要加缓存 加快 访问速度和流畅性。

点赞数的合集 甚至可以直接放一个字段 然后让 redis去自增和递减。
最后得到一个 最适合自己系统的缓存结构。