25,980
社区成员
发帖
与我相关
我的任务
分享“点赞”功能的高并发问题
现在实现了点赞功能，主要涉及了两个表，一个保存被点的数量，另一个是某一个对哪些点了赞。现在的问题是每次点赞都会进行数据的读写操作（特别是写），并发的话会导致数据库压力太大，请问如何解决？谢谢。
...全文
请发表友善的回复…
发表回复
qq_23238511 2015-09-13
- 打赏
- 举报
写并发一般都是加队列进行控制的，比如zeromq，rabiitmq，如果前端用户连续操作这种问题，可以在前端页面限制啊。。服务器响应总归是有时延的。
okkk 2015-09-10
- 打赏
- 举报
我正打算做这个：
每个地址提供一个编号【或则直接就是URL地址】 - urlID
每个用户有一个唯一的ID -userid
一个Hash数据库 key = userid + urlID 存在该key表示关注，不存在，表示没有关注。
该Hash数据库可以用userid进行分布式【负载均衡】，并发量可以保证 10 0000笔/S
Hash数据库为主表，在判断关注有效的情况下，向另一个以urlid为主键的文件发送日志： urlid userid operate
operate包括 关注 取消关注 数量读取 等，改日志记录与第3步的表向对应。operate可能会有很多
对于 关注 取消关注 需要以appendfile的方式记录到文件 【append方式的瓶颈在磁盘速度，或网卡速度】
最后修改urlid为主键的表，获得当前有效的总赞数。
该表应该是标准的列数据库，用url地址的hash值进行分布式管理
geodetic 2014-11-12
- 打赏
- 举报
需要分布式就上redis，如果规模不大只是单机，直接缓存在jvm中即可。
healer_kx 2014-10-30
- 打赏
- 举报
赞同这种办法，
一般我会再加入Gearman这种东西，来帮你进行异步的写入MySQL。
zihua2005 2014-10-28
- 打赏
- 举报
redis我也是用这个来实现的点赞,点赞时候把点赞的唯一标示 加redis的前缀作为键,值就是点赞的数量了,注意同步,注意redis里数据的更新,关键点掌握就可以了!
1.redis数据是否要放到自己的库中,如果需要要定时把redis数据更新到自己数据库表中
2.如果记了两份 那重启程序时 数据库表记录要和redis数据进行对比,把redis没有的数据进行添加,有数据但是 redis 点赞数少的进行更新.
redis其实可看作缓存 也可看作库!
pricks 2014-10-28
- 打赏
- 举报
一般除了redis或memcached，还能怎样呢？自己开发个新的东东？要么还是基于文件的，要么还是基于内存的
顶多在后端加上异步消息机制罢了
HelloNet 2014-10-28
- 打赏
- 举报
多大访问量对这个要求这么高？一般的站点没必要考虑那么多吧呵呵。
小在在 2014-10-24
- 打赏
- 举报
这样是不是会有一个数据处理延时的问题？？比如你取消赞进入了队列，这个时候数据还没有处理，但其它的用户此时看到的还是包含你之前赞过的数据
ydm305365 2014-10-23
- 打赏
- 举报
我们现在的点赞和取消赞，我们前面放redis ,中间放activemq,后面放数据库，压力到不是问题，点赞时，首先检查该用户是否对该内容点过赞，如果有，就提示你点过赞了，如果没有那么在redis记录用户和该内容的赞关系，然后发消息到activemq 中去处理后续事情，但是现在遇到一个问题，如果我对一个内容点赞了，发消息到后面去处理，但这个时候，假如因为什么事情卡住了，或者处理慢了，用户马上又取消了赞，也发消息到后面去处理了，但这个时候的顺序就出现问题了，我取消赞的逻辑先走完，赞的逻辑在去处理，那这样问题就出现了，我本来对该条数据已经取消赞了，可能数据库了还记录着你对该条内容是点赞的状态，我现在有一种方案去解决这种问题，就是从赞队列取数据处理时，把该条数据放入一个redis set 中，处理完了在从set 中删除了，那么取消赞队列的时候去检测 刚刚队列是否有该内容，如果有说明我还没处理完，那么取消暂时等待，如此。但我总感觉此中方案不理想，请问各位是否有好的方案。
skyw941 2014-10-21
- 打赏
- 举报
点赞的人应该不用展开，你设一个字段就行，把点赞的ID加起来，超过多少长度就不加了，这个子段可以和点赞数量放一张表里。
joyhen 2014-09-28
- 打赏
- 举报
一点建议：
是否可以重复点赞（一般只是一次动作就结束了），如果一次动作，ui上确切说js处理上，应该点击后禁掉，防止重复提交；
后台处理上用一个线程，为保障资源最大化，建议看此文：http://www.codeproject.com/Articles/821220/Throwing-a-Great-Block
ahopedog 2014-09-28
- 打赏
- 举报
还有个笨笨的方法，点击一下LOG4J记一个日志，后台一个任务再慢慢处理。单线程处理觉不会出问题。
andy_liucj 2014-09-25
- 打赏
- 举报
我记得新浪微薄就是用的redis或者ｍｅｍｃａｃｈｅｄ来实现阅读数功能的
Jaaaaaaaava 2014-09-25
- 打赏
- 举报
这个问题我现在也在研究
应为我现在也是这样
还有在 查询类似关注好友微博
假设每页 20条
每条微博 都有点赞 所以当前用户 每次都要 匹配是否点赞过当前微博 从而显示不同的图标
我的表设计跟你是一样的 所以现在这样查询起来 发出的语句特别多
不知道你现在有没有好点的解决方法
lgycy 2014-09-23
- 打赏
- 举报
redis不会用，
micro19890 2014-09-01
- 打赏
- 举报
支持redis
yanghongjy 2014-08-28
- 打赏
- 举报
好吧，不重复点赞需求省不了。
这个用 5 楼的
写入数据库， 数据集群优化， 分库分区什么的，或者改用非关系型数据库 nosql
用队列来抗压
原子性调事务
埃尔库鲁斯 2014-08-28
- 打赏
- 举报
哪些点过赞最主要的作用是记录谁点过什么资源的赞，点赞不可重复，另一个作用就是做个记录。你就把点赞记录做个列表给用户看？
名字什么的最讨厌 2014-08-04
- 打赏
- 举报
同意二楼的说发，取消点赞的两个表完全可行，上记录锁也很重要，我觉得最好根据点赞字段加上partition
sweat89 2014-08-04
- 打赏
- 举报
点赞这个东西就不要用关系数据库拉~~
加载更多回复（6）
