Redis和MySQL一起用，点赞系统其实可以这样做，不只是简单存数据那么简单

这篇文章的灵感主要来自于一位资深后端开发者在技术社区分享的实战经验,并结合了其他一些关于高并发系统设计的常见思路。

Redis和MySQL一起用，点赞系统其实可以这样做，不只是简单存数据那么简单

我们平时刷手机，点个赞看似简单，就是一下的事情，但背后系统要处理的事情可没那么简单，尤其是像微博热门帖子、抖音爆款视频这种，一秒之内可能有成千上万人点赞，如果每点一次赞，系统都直接去操作MySQL数据库，给那个“点赞数”字段加1，那数据库很可能就扛不住了，会变得非常慢,甚至崩溃。

那怎么办呢？这时候，Redis就派上用场了，Redis是一种速度极快的内存数据库，它的读写速度比MySQL这种存在硬盘上的数据库快太多了，Redis的数据是放在内存里的，如果服务器重启或者断电，数据可能会丢，而MySQL的数据是持久化在硬盘上的，更可靠，一个聪明的做法就是让它们俩“搭档”,各自干自己最擅长的事。

具体怎么“搭档”呢？这个点赞系统可以设计成两层结构：Redis负责应对高并发的“前线战斗”，MySQL负责持久化存储的“后方大本营”。

第一步：用户点赞时，先写Redis

当用户点击点赞按钮时，你的程序不应该直接去更新MySQL,而是做两件事：

1. 记录点赞行为：在Redis里用一个集合（Set）或者哈希（Hash）结构，来存“谁给谁点了赞”，给帖子123点赞，就在Redis里记录一条：“user:456 点赞了 post:123”，这样做的好处是，可以非常快地判断出当前用户是否已经点过赞了,避免重复点赞。
2. 更新点赞计数：在Redis里用一个简单的键值对（String）来存储这个帖子当前的点赞总数。post:123:like_count，每次有人点赞，就给这个数字加1，这个操作在Redis里是原子性的，非常快,完全能承受高并发。

这样一来，用户的感觉就是点赞响应非常迅速，体验很好，所有的压力都由Redis这个“快家伙”顶住了。

第二步：定时把Redis的数据同步到MySQL

Redis虽然快，但不能永远把数据放在内存里，毕竟内存比硬盘贵，而且有丢失的风险，所以我们需要一个“后勤部队”,定时把Redis里的数据搬运到MySQL里。

这个同步过程是定时执行的，比如每隔5分钟，或者每隔一小时，由程序自动完成,它会做两件事：

1. 同步点赞关系：把Redis里记录的“谁点赞了谁”这条记录，写入到MySQL的一张关系表中，这张表可能就叫user_like_post，里面就两列：用户ID和帖子ID，这主要是为了以后做数据分析，比如找出某个用户的点赞习惯,或者判断两个人是否兴趣相投。
2. 同步点赞总数：把Redis里那个post:123:like_count的最终数值，更新到MySQL的帖子主表（比如posts表）的like_count字段里，这样，我们就有了一个持久化的、准确的点赞总数。

这种设计带来的巨大好处

1. 性能飞起：用户的点赞操作几乎感觉不到延迟，系统可以轻松应对百万甚至千万级的并发点赞,不会因为一个热门话题就把服务器搞垮。
2. 数据可靠：所有重要的数据（点赞关系和总点赞数）都稳稳地保存在了MySQL里,不会丢失。
3. 扩展性强：如果点赞量越来越大，我们可以很方便地增加Redis服务器的数量（搭建Redis集群），把不同的数据分布到不同的Redis服务器上,继续分担压力。

不只是点赞

这种“Redis扛实时流量，MySQL做持久化”的思路,可以用在很多类似的场景里。

• 文章的阅读数统计：每次阅读都先在Redis里给计数加1,再定时同步到MySQL。
• 电商商品的库存扣减：秒杀开始时，先在Redis里预扣库存，快速响应用户，然后再慢慢同步到数据库,避免超卖。
• 粉丝关注关系：关注和取关操作先记录在Redis，保证速度,再同步到MySQL。

你看，一个简单的点赞功能，背后藏着这样的设计巧思，它没有简单地“存数据”，而是充分考虑了不同工具的特性，让它们协同工作，最终既保证了用户体验，又确保了系统的稳定和数据的安全，这就像一场精心安排的战役，前方有冲锋陷阵的轻骑兵（Redis），后方有稳守大本营的重步兵（MySQL），各司其职,才能打赢高并发这场硬仗。