点赞功能的并发？每个人的点赞应该不会相互影响，如果有多表修改当然要添加事务啊

这话不好说。捞干的吧。最好写并发的，这样自己以后简历回好看些。

点赞肯定有并发 要考虑的

点赞这玩意，我觉得就是用来烘托气氛的，不需要很精确，大致数值差不多就行了

考虑个锤子🔨，点赞用Redis的Incr就行了

你们点赞数据存在数据库还是redis

我的理解是需要，上面虽然说放redis，或者一个点赞记录一条数据，最后统计 实际上是客户那边需要能手动修改点赞数，对点赞数进行操作排序，最后还是要入库。如果允许多次点赞那就无所谓考虑这个了。

你说的不就是要考虑并发的场景吗？大多数情况下库存、商品、订单这类东西的修改都要考虑并发，复杂结构体的修改也是

点赞用redis的bitmap，每个用户对应一个bit位，互不干扰就不存在并发问题，计算点赞数时对bitmap使用bitcount就行了

这东西一个用户短时间内对一个内容只会点一次赞，高频重复点就是频繁操作直接幂等或拒绝就好。说并发确实可能存在，问题是这玩意真并发了也没啥大影响，平日也遇不上什么并发量，不考虑编程成本吗？

只要不会造成经济损失或者社会影响的，一概不用考虑，怎么开发快怎么来

点赞数你在redis不就是单线程的吗 你多线程不还都是走redis 意义在哪？还是你每点赞一次都要去操作数据库去给点赞数+1？

扯个其他的…秒杀系统现在挺烂大街的，筛选简历10个里能有两三个，一般当减分项…

所有地方都要考虑，而且处理起来也简单，给更新操作用version做个乐观锁就行了，mybatis-plus甚至有插件代码都不用写