用户点赞、收藏频繁操作数据混乱问题

最新推荐文章于 2025-04-04 15:23:40 发布
最新推荐文章于 2025-04-04 15:23:40 发布
阅读量1.8k 收藏 2
点赞数
分类专栏： java 数据库 文章标签： 数据库 数据 事务 select
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wanzhix/article/details/71550552
版权

用户在点赞时频繁操作时，导致数据库点赞记录多条。
编码流程是用户点赞时，先去查询是否有点赞记录，有则取消点赞（删除点赞更新状态），反之点赞（新增点赞记录）。但是频繁操作时点赞记录会出现多条，点赞计数也会异常变动。
原因：没有事务，查询点赞记录返回前可能已有数据更新，但未查到数据。
解决方案：加上for update （select * from public_like for update）

中通科技数仓数据治理实践
爱吃辣条的博客
04-05 1143
中通科技数仓数据治理实践
字节跳动数据分析面试题及参考答案
大模型大数据攻城狮的专栏
12-03 606
ABtest 和置信度相关，进行 AB 测试的时候样本量要如何选取？ AB 测试与置信度紧密相连，置信度体现了我们对测试结果的信任程度。 首先，要理解置信度的概念。比如我们设置置信度为 95%，这意味着如果我们重复进行多次 AB 测试，有 95% 的情况下得到的结果是可靠的，即真实的差异确实存在于 A 组和 B 组之间。 样本量的选取取决于多个因素。一是基础指标的方差。如果指标的方差较大，比如用户停留时间这个指标，不同用户之间差异巨大，那么就需要更大的样本量来准确估计差异。例如，对于一
PHP学习7：数据库记录用户点赞和收藏的东西，并且切换icon、php返回多个echo，怎么取出返回值？
qq_44139411的博客
03-07 1044
数据库记录用户点赞和收藏的东西，并且切换icon，php返回多个echo，怎么取出返回值？
收藏:spring 操作数据库如此简单
解决问题收藏
11-04 146
[quote]以前一直都没有试过，前几天打算把wordpress换成自己写的程序，就想到了数据的导入和导出，首先想到的是用数据库工具来导。可是觉得有些麻烦，我自己的程序是用spring+hibernate的。后来我就试了一下spring的JdbcTemplate,就和HibernateTemplate一样的好用。首先增加一个连接到wp数据库的dataSource o...
如何来提高点赞业务的并发性
最新发布
2301_81124241的博客
04-04 901
如何来提高点赞业务的并发性
点赞和关注功能
qq_45832461的博客
11-28 1714
全面详细阐述如何实现点赞和关注功能！
JAVA项目点赞功能如何实现?如何利用缓存优化？如何防止刷赞?
weixin_73077810的博客
10-09 2935
本文对业务中的点赞功能做出详细的思路整理，搭配着缓存优化和防刷策略讲解，提高对于该类业务的理解
新浪微博「点赞功能」数据库如何设计的？
九章算法的博客
03-25 6445
刚在北大学长的《系统架构设计》讲座上听到这部分内容，觉得还蛮有意思的，这里简单交流一下 【点赞功能】的基本设计思路分两种： mysql直接落地存储； 利用点赞的业务特征来扔到redis中，然后离线刷回mysql 一、mysql方案 对于大多数中小型项目，低于千万级并发的数据，基本可以用mysql分表+cache完成。 这种方法只要做两个表就可以了： 1、记录文章被点赞的次数，有多少人点过赞 2、记录哪些文章被点赞过 常用的查询有： 查询用户点赞过的文章 select post_id from star
用户界面设计：提升抖音点赞任务平台操作便捷性的策略
[用户界面设计：提升抖音点赞任务平台操作便捷性的策略](https://tbadcimg.tbadc.com/uploads/allimg/20230131/1-2301310K21E10.jpg) # 摘要 用户界面设计在提升用户体验和软件互动性方面发挥着至关重要的作用。...
数仓体系与数据治理全集
weixin_44687655的博客
04-06 3666
数据仓库（Data Warehouse），可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。
【数据结构】顺序表：与时俱进的结构解析与创新应用
Miracle_86的博客
04-21 4160
数据结构是计算机存储、组织数据的方式。数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。数据结构反映数据的内部构成，即数据由哪部分构成，以什么方式构成，以及数据之间存在的相互关系。 | 数据结构 | 顺序表 |
赞：高并发点赞的详情解决方案
02-09
高并发点赞问题 高并发请求下，服务器替换创建线程。 高并发请求下，数据库连接池中的连接数有限。 高并发请求下，点赞功能是同步处理等。 解决方法： 初步 我们通过约会Redis缓存避免高并发写数据库而造成数据库压力，同时约会Redis缓存提高读的性能，基本可以解决问题。 第二步 为了解决高并发请求下，点赞功能同步处理所带来的服务器压力（Redis缓存的压力或数据库压力等），我们发布MQ消息中间件进行异步处理，用户每次点赞都会推动消息到MQ服务器并同时返回，这样用户的点赞请求就及时结束，避免了点赞请求线程占用时间长的问题。同时，MQ消息中间件接收到消息后，会按照“自己的方式”及时消费，还可以用MQ消息中间件来限制流量并进行同步处理等。 整个流程，如下图所示 详细设计 1.Redis数据结构设计 使用set来存储被点赞的类型id，键为被点赞类型名，value为类型id hash存储某个类型点赞
【狂神说Java】--MySQL(九)规范数据库统计
想握住此生辽阔
03-26 214
9.2 三大范式 为什么需要数据规范化？ 1：因为数据会重复 2：更新会有异常 3：插入异常（无法正常显示信息） 4：删除异常（丢失有效信息） 关系型数据库设计：三大范式的通俗理解 第一范式 要求数据库表中的每一列都是不可分割的原子数据项 第二范式 前提：满足第一范式，每张表只描述一件事情 第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关 咱们把订单号和产品号看成联合主键 第三范式 前提：满足第一范式和第二范式 任何非主属性不依赖于其他非主属性，即在第二范式（2NF）基础上消
项目1在线交流平台-4. 使用radis高性能储存方案-4.开发个人主页-显示点赞信息-redis事务管理
xingzhes_的博客
03-22 600
文章目录功能需求1.dao层-redis的key生成工具更新2. Service层统计用户赞的数量redis点赞事件==decrement(userLikeKey)====increment(userLikeKey)==查询指定用户获取的赞的数量3. controller层处理请求1.点赞异步请求更新2. 访问个人主页的请求4.View层模板处理帖子详情页面点赞事件按钮更新1.对帖子的点赞2.对评论的点赞3.对回复的点赞js的更新js个人主页模板设置处理链接位置1.主页中-个人信息2.主页中-每个帖子的用户
通用点赞设计与实现
热门推荐
专注的博客
11-26 1万+
点赞作为一个高频率的操作，如果每次操作都读写数据库会增加数据库的压力，所以采用缓存+定时任务来实现。点赞数据是在redis中缓存半小时，同时定时任务是每隔5分钟执行一次，做持久化存储，这里的缓存时间和任务执行时间可根据项目情况而定。 优点 1.降低对数据库的影响 2.提高点赞的效率 缺点 1.如果任务挂了，会丢失点赞数据 2.持久化存储不是实时的 时序图 数据库设计 create table s...
具备关联关系的表格执行truncate和drop操作
hxthon的博客
05-12 229
truncate表 SET FOREIGN_KEY_CHECKS = 0; TRUNCATE TABLE blog_markdown; SET FOREIGN_KEY_CHECKS = 1; drop表 SET foreign_key_checks = 0; DROP TABLE blog_markdown; SET foreign_key_checks = 1;
mysql 点赞数据库设计_基于redis实现的点赞功能设计思路详解
weixin_31855625的博客
01-27 4317
点赞其实是一个很有意思的功能。基本的设计思路有大致两种， 一种自然是用mysql等数据库直接落地存储， 另外一种就是利用点赞的业务特征来扔到redis(或memcache)中， 然后离线刷回mysql等。直接写入Mysql直接写入Mysql是最简单的做法。做两个表即可，1、post_like记录文章被赞的次数，已有多少人赞过这种数据就可以直接从表中查到;2、user_like_post记录用户赞过...
Java利用redis限制重复频繁操作带来的数据问题
默慊的博客
07-02 3607
在项目开发中我们时常会遇到一些前端频繁操作带来的问题，有的时候是误点或者页面卡顿了导致用户以为没有点击重复操作导致出现多次无效请求的现象，这里分享一个Java中利用redis来限制这种现象的方法： 场景： 以 支付场景为例，现有一订单需要去支付，点击支付按钮后因习惯再次点击或者短时间未响应又重复点击会造成多次请求支付接口，造成多次无效请求，也会增加消耗 思路： redis可以设置过期时间，可以通过存储该订单的唯一标识作为key，设置一定的过期时间，就可以避免在这段时间内重复发起请求，失效的key会通
java使用Redis实现点赞功能
kires的博客
02-28 4379
疑问 当看到这个标题，可能会有些大佬有点模糊，因为为什么不用数据库去实现，而用redis来实现这个功能，那我们可以一起来思考一下。 为什么实现redis，而不用数据库 先从安全方面来讲，如果使用数据库，假如用户频繁点赞，取消点赞这些操作的话，那么会给数据库造成压力，如果使用缓存的话，那么压力不会那么大。 从效率方面考虑，redis数据存在与内存，所以速度收到内存影响，数据库存在与硬盘，速度没redis快。 从功能方面考虑，redis只支持几种数据结构，没用数据库支持的多。 Redis几种数据结构的适用场
点赞和收藏数据表设计
02-17
### 点赞和收藏功能的数据库表设计最佳实践 #### 表结构概述 对于点赞和收藏这两种常见的社交互动行为，在设计相应的数据库表格时，应遵循一些基本原则来确保系统的可扩展性、性能以及数据的一致性。 #### 用户表 (users) 考虑到用户作为主体参与点赞或收藏操作，因此需要有一个`users`表用于存储用户的个人信息。此部分不在具体讨论范围内，但它是整个架构的基础组成部分之一[^1]。 #### 文章/帖子表 (posts/articles) 同样地，被点赞或收藏的对象也需要有对应的实体表示，这里假设为文章或帖子形式的内容，并创建名为 `posts` 或者 `articles` 的表来进行描述。这也不是本次重点介绍的部分，不过它同样是不可或缺的一部分。 #### 点赞记录表 (likes) 为了有效地追踪每一个点赞动作并支持后续统计分析等功能，则需建立专门用来保存这些事件信息的新表——即`likes`： | 字段名 | 类型 | 描述 | |--| | id | INT(UNSIGNED)| 主键, 自增 | | user_id | INT(UNSIGNED)| 发起点赞的用户ID | | post_id | INT(UNSIGNED)| 被点赞的文章/帖子ID | | created_at | TIMESTAMP | 记录创建时间 | 其中，`user_id` 和 `post_id` 应设置外键约束分别指向 `users(id)` 及 `posts(id)` ，以此保证参照完整性；同时可以考虑在这两个字段上加上联合唯一索引来防止重复点赞的情况发生。 ```sql CREATE TABLE likes ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id BIGINT UNSIGNED NOT NULL, post_id BIGINT UNSIGNED NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES users(id), FOREIGN KEY (post_id) REFERENCES posts(id), UNIQUE INDEX unique_like(user_id, post_id) ); ``` #### 收藏夹表 (favorites) 类似于点赞机制的设计思路，针对收藏功能也应当构建独立的数据模型——`favorites` 来承载此类交互活动的相关元数据: | 字段名 | 类型 | 描述 | |--| | id | INT(UNSIGNED)| 主键, 自增 | | user_id | INT(UNSIGNED)| 创建该收藏条目的用户ID | | post_id | INT(UNSIGNED)| 所收藏的文章/帖子ID | | title | VARCHAR(255) | 对于所收藏项的一个简短标题 | | note | TEXT | 用户自定义备注 | | created_at | TIMESTAMP | 添加到收藏的时间戳 | 同样的道理适用于这里的外键关系设定与去重措施实施。值得注意的是，“title” 和 “note” 这样的附加属性有助于提高用户体验质量，允许个人根据自己的喜好整理资料。 ```sql CREATE TABLE favorites ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id BIGINT UNSIGNED NOT NULL, post_id BIGINT UNSIGNED NOT NULL, title VARCHAR(255), note TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES users(id), FOREIGN KEY (post_id) REFERENCES posts(id), UNIQUE INDEX unique_favorite(user_id, post_id) ); ``` 通过上述方式组织起来的信息不仅能满足基本业务逻辑的要求，而且便于后期维护升级工作开展的同时也为可能存在的高级特性预留了一定空间，比如基于标签分类管理等更精细化的操作模式探索提供了良好基础。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值