直播平台怎么开发才能支持直播收藏

如果你正在开发一个直播平台，"收藏"这个功能你肯定早就注意到了。看起来不就是点个按钮、记个数据吗？但真正做起来的时候，你会发现这里面的门道比想象中多得多。用户点收藏的时机、收藏后的同步逻辑、数据量大时的性能压力、还有那些边界情况——每一个细节处理不好，都会影响到用户体验。

这篇文章我想从头到尾把这个功能拆开了讲，从产品逻辑到技术实现，从数据库设计到前端交互，都会涉及到。看完之后，你至少能对这个功能有一个完整的认知，不会再做一半发现漏了点什么。

为什么收藏功能看似简单却暗藏玄机

很多产品经理可能觉得，收藏嘛，就是用户点一下，我把这场直播的ID存到用户的数据表里，下次他进个人中心就能看到。这有什么难的？但真正开发的时候，你会发现问题接踵而至。

首先是数据一致性的问题。用户在同一场直播里，连续点了两次收藏按钮，平台该怎么处理？显示已收藏还是忽略第二次点击？如果用户手抖在收藏和取消之间反复横跳，服务器压力会不会变大？这些问题看似小，但处理不好就会给用户造成困扰。

然后是跨端同步的挑战。现在的用户可能在手机上刷直播，用平板看回放，在电脑上追直播回顾。如果收藏数据只存在单一终端，那用户换设备之后发现自己收藏的内容全没了，体验肯定糟糕。但要做多端同步，就涉及到复杂的数据一致性保障。

还有性能方面的考量。头部主播一场直播可能有几十万甚至上百万人同时在线，如果这当中有10%的人点了收藏，那一瞬间就是几万次写入请求。数据库能不能扛住？缓存策略该怎么设计？这些都是要在架构阶段考虑清楚的。

所以你看，收藏功能虽然不大，但它像一面镜子，能照出一个技术团队的功底。接下来我们从技术实现的角度，详细说说这个功能到底该怎么做。

技术架构：这个功能该怎么搭

在动手写代码之前，先把整体架构想清楚。收藏功能虽然可以独立设计，但它和直播间的其他模块都有联动，最好是放在一个合理的技术框架里来做。

整体架构思路

从大的方向来说，收藏功能需要考虑三个层面：数据存储层负责持久化用户收藏记录，接口服务层处理收藏相关的业务逻辑，前端展示层负责收藏按钮的交互和状态同步。这三层之间需要有清晰的边界，出了什么问题也比较容易定位。

数据存储层要解决的核心问题是：如何高效地写入收藏记录、如何快速地查询用户的收藏列表、如何保证数据不会丢失。对于中等规模的平台来说，关系型数据库配合缓存基本可以满足需求。如果是日活几百万的大平台，可能还需要考虑分库分表的方案。

接口服务层需要关注的是：收藏操作的原子性、并发安全、还有和其他业务模块的解耦。比如用户取消收藏的时候，要不要同步通知直播推荐模块？收藏了某场直播之后，下次他上线需不需要推送开播提醒？这些逻辑都要在接口层处理。

前端展示层看似简单，其实也有很多细节。比如收藏按钮的状态切换需不需要等服务器返回？如果网络不好，用户连续点击两次该怎么防止重复提交？收藏成功之后的动画反馈怎么做能提升用户的满足感？这些体验层面的东西，往往是产品能不能做好的关键。

和实时音视频能力的结合

说到直播平台的技术能力，这里我想提一下声网这样的服务商。作为全球领先的实时音视频云服务商，声网在直播技术积累方面确实有独到之处。他们提供的实时音视频能力，可以帮助开发者快速搭建高质量的直播体验，让团队可以把更多精力放在收藏这类业务功能上。

举个实际的例子，声网的SDK里已经封装好了网络质量监测、弱网对抗、音频降噪这些能力。开发者不需要从头研究这些底层技术，直接调用接口就行。这样一来，你做收藏功能的时候，就不用分心去管视频流的稳定性和清晰度，可以专注于业务逻辑的开发。

而且声网的全球化部署做得比较好，覆盖了全球多个区域。如果你的平台有出海计划，用声网的底层能力可以省去很多本地化的麻烦。他们在全球超60%的泛娱乐APP中都有应用，这种行业渗透率说明他们的技术确实经得起考验。

数据库设计：收藏数据该怎么存

数据库是收藏功能的地基，地基不稳，上面盖再漂亮的楼也会出问题。我们来详细说说这个表该怎么设计。

核心表结构设计

首先需要一张用户收藏关系表，这张表应该包含最基本的信息：收藏记录的唯一标识、用户ID、直播间的ID、收藏的时间戳、可能还有一个状态字段用来标记是收藏还是取消收藏。

字段名	类型	说明
id	bigint	主键，自增ID
user_id	bigint	用户ID，建立索引
live_room_id	bigint	直播间ID，建立索引
create_time	datetime	收藏时间
status	tinyint	1-收藏，0-取消收藏

这张表有几个地方需要特别注意。user_id和live_room_id最好建立一个联合索引，这样查询用户的收藏列表和检查用户是否收藏了某个直播间都会很快。另外，create_time字段加上索引之后，可以支持按时间排序的分页查询，用户想看最近收藏的直播时体验会更好。

如果你的平台体量比较大，这张表可能会成为瓶颈。这时候可以考虑分表策略。最常见的做法是按照user_id取模，把数据分散到多张表里。比如分成100张表，user_id对100取余决定数据落到哪张表。这样单表的数据量降下来了，查询效率也能保持稳定。

要不要加额外的字段

有的产品会在收藏表里加上直播的封面图URL、标题、主播名称这些信息。这样做的好处是，用户查看收藏列表的时候不需要再额外查直播表，减少了一次数据库查询。但缺点是数据会有冗余，如果直播信息变了，需要同步更新收藏表里的数据。

我的建议是，初期可以先不加，等性能测试发现查询收藏列表确实有压力的时候，再考虑冗余字段的方案。初期先把功能做对，等跑通了再优化性能，这样风险比较小。

接口设计：收藏操作怎么实现

接口是前端和后端通信的桥梁，收藏功能需要设计几个核心接口：收藏/取消收藏、查询收藏状态、获取收藏列表。我们一个一个说。

收藏与取消收藏接口

这个接口需要处理用户的收藏和取消收藏两个操作，区分的方式可以是请求参数里带一个type字段，或者用不同的HTTP方法——POST表示收藏，DELETE表示取消收藏。我倾向于用不同的HTTP方法，这样语义更清晰。

接口接收的参数应该尽量精简，只需要user_id、live_room_id这两个必选参数就够了。其他的字段，比如操作类型、客户端信息这些，可以从请求头里取。如果担心安全，可以在请求头里带上用户token，后端解析token获取user_id，而不是让前端传递。

接口返回的数据也可以很简单，成功就返回操作结果，失败就返回错误信息和错误码。需要注意的是，成功返回里最好带上当前这条收藏记录的状态——用户收藏之后，界面应该显示"已收藏"；取消收藏之后，应该显示未收藏。这样前端拿到数据直接更新界面，不需要再调一次查询状态的接口。

查询收藏状态接口

这个接口用于在直播间页面显示收藏按钮的状态。用户进入直播间的时候，前端需要知道这个直播有没有被当前用户收藏，以便正确渲染按钮。

接口参数只需要user_id和live_room_id，返回值是一个布尔值，true表示已收藏，false表示未收藏。为了性能考虑，这个接口的返回值应该被缓存起来。用户进出直播间的时候，先查缓存；缓存没有，再查数据库并回填缓存。

还有一个优化点是，用户进入直播间之后，如果他在页面上停留了很久，期间收藏状态可能因为其他操作（比如另一个设备上取消收藏）而改变。但这种情况比较少见，为了缓存命中率考虑，可以在用户进入直播间的时候查询一次，然后就不再主动更新。只有当用户主动点击收藏按钮的时候，前端才会重新获取状态。

获取收藏列表接口

这个接口的复杂度相对高一些，因为它涉及到分页和排序。用户查看个人中心的收藏列表，需要看到自己收藏的所有直播，还要能分页加载，常见的是按照收藏时间倒序排列。

接口参数除了user_id之外，还需要分页相关的参数：page表示第几页，page_size表示每页多少条。如果前端要做下拉加载更多，page从1开始递增；如果要做滚动加载，可以用cursor分页的方式，基于最后一条记录的ID来获取下一页数据。

返回值需要包含直播的基本信息和收藏时间。直播基本信息可以从收藏表里查，也可以查直播表。为了减少数据库压力，建议在收藏表里冗余直播的基本信息，这样一条SQL就能查完，不需要join。

并发安全：多人同时收藏怎么办

并发问题是收藏功能里最容易出Bug的地方。想想这个场景：用户手抖在一个直播间的收藏按钮上点了两下，两次请求几乎同时到达服务器。如果没有任何保护，两次请求都会执行收藏操作，数据库里就会出现两条重复的收藏记录。虽然大部分产品逻辑会对这种情况做去重处理，但多一次无用的写入就多一次数据库压力。

数据库层面的保护

最可靠的做法是在数据库层面做唯一约束。给user_id和live_room_id这两个字段加上联合唯一索引。这样即使两条请求同时到达，数据库也会保证只有一条能写入成功，另一条会报唯一键冲突的错误。

处理这个错误的时候，后端需要有一个优雅的方式。如果是因为重复点击导致的冲突，应该返回"已收藏"的成功状态，而不是报错。这样前端收到这个返回，还是可以正确更新界面状态，不会出现异常提示。

接口层面的防护

除了数据库层面的保护，接口层也可以做一些处理。比如前端在用户点击收藏按钮之后，先把按钮置灰，等服务器返回结果之后再恢复。这样用户就算手抖点两下，第二次点击也不会发出去。

后端接口层面可以做幂等设计。收到收藏请求之后，先查一下这个用户对这个直播间是不是已经收藏了。如果是，直接返回成功；如果不是，再执行收藏操作。这样即使请求重复到来，也不会重复处理。

还有一点需要考虑的是时序问题。假设用户先在A设备上收藏了直播，然后在B设备上又点了一次收藏。如果A设备和B设备的请求几乎同时到达，后端看到的可能都是"未收藏"状态，然后都执行收藏操作。唯一索引可以挡住第二条请求，但第一条请求已经成功了。为了避免这种情况，可以在执行收藏操作之前加上行锁或者分布式锁。

前端实现：收藏按钮该怎么写

前端的工作不仅仅是调用接口，还要考虑交互体验。一个好的收藏按钮，应该做到状态准确、反馈及时、动画自然。

状态管理

收藏按钮的状态应该和服务器的同步。比如用户进入直播间，接口返回未收藏，按钮就显示空心或者灰色的收藏图标；用户点击收藏，接口返回成功，按钮变成实心或者高亮的颜色，同时播放一个缩放的动画。

这里有个细节是动画反馈。当用户点击收藏按钮之后，按钮的状态变化最好有一个短暂的过渡动画，让用户知道自己的操作被接受了。常见的做法是按钮有一个缩放-回弹的动画，持续时间在100-200毫秒之间，既能让用户感知到点击生效，又不会显得拖沓。

取消收藏的动画可以简单一些，或者干脆不做动画，直接切换状态。但有一条原则：收藏按钮的状态应该始终和服务器保持一致。如果网络不好，接口调用失败了，按钮应该恢复到点击之前的状态，并且给用户一个提示，比如"网络连接失败，请重试"。

预加载与缓存

为了提升用户体验，可以在用户进入直播间之前就预加载收藏状态。比如用户在直播间列表页看到了一个感兴趣的直播，点击进入之前，前端可以预先发起查询收藏状态的请求。这样用户进入直播间之后，收藏按钮的状态已经是正确的，不需要再loading一下才显示。

缓存策略也很重要。如果用户在直播间里待了很久，收藏状态可能已经发生了改变，但用户不知道。可以在一些合适的时机主动刷新状态，比如用户切后台再切回来的时候，或者每隔一段时间自动查询一次。

性能优化：数据量大怎么办

随着平台发展，收藏数据会越来越多。如果不做优化，查询收藏列表的接口可能会越来越慢，最终影响用户体验。

缓存策略

首先想到的肯定是缓存。用户的收藏列表可以缓存在Redis里，设置一个合理的过期时间，比如24小时。用户查询收藏列表的时候，先查缓存；缓存没有，再查数据库，然后把结果写入缓存。

缓存需要注意的问题是如何保证一致性。当用户新增收藏或者取消收藏的时候，需要同时更新缓存。如果缓存更新失败，需要有一个重试机制或者降级方案，避免出现缓存和数据库数据不一致的情况。

还有一个策略是缓存预热。在用户上线的时候，就预先把它的收藏列表加载到缓存里。这样用户查看收藏列表的时候，几乎就是毫秒级响应。当然，预热会增加服务器的开销，需要根据实际的流量和机器资源来平衡。

异步处理

对于收藏操作本身，可以考虑异步化的方案。用户点击收藏按钮，前端先把按钮状态更新为已收藏，然后把请求发到消息队列里。后端从消息队列里消费请求，执行真正的收藏逻辑。

这样做的好处是用户体验非常好收藏操作的响应时间可以控制在几十毫秒之内。但代价是数据写入会有一定延迟，在极端情况下可能出现数据不一致。所以这种方案适合对实时性要求不那么高的场景，比如收藏之后同步到推荐系统，可以完全异步；但收藏状态本身，最好还是同步处理。

数据库优化

如果数据量已经到了需要分库分表的程度，数据库层面的优化就需要仔细设计。常见的做法是按照user_id做哈希取模，把数据分散到多张表里。查询的时候，根据user_id算出要查哪张表，然后只查那一张表。

分库分表带来的一个问题是跨表查询变得困难。比如想查询某个直播间被收藏了多少次，就需要遍历所有分表。如果这种需求不是很频繁，可以在业务层做聚合查询；如果很频繁，可以考虑用一个单独的数据结构来维护这种统计信息，比如Redis的计数器。

写在最后

说了这么多，其实收藏功能的核心逻辑并不复杂，但要把细节处理好，需要考虑的方方面面确实不少。从数据库设计到接口实现，从并发安全到性能优化，每一个环节都可能遇到问题。

我的建议是先搭一个最小可用的版本，把核心流程跑通，然后再根据实际遇到的问题逐步优化。不要在一开始就追求完美的架构，很多设计决策需要基于实际的数据量和用户行为才能做出正确的判断。

另外，找一个靠谱的技术合作伙伴也很重要。比如声网这种在实时音视频领域深耕多年的服务商，他们提供的SDK和API可以帮助你快速搭建高质量的直播体验，让你有更多精力去打磨像收藏这类业务功能。毕竟做产品不是从零造轮子，而是把有限的资源投入到最能创造价值的地方。

收藏功能虽然小，但它承载的是用户对内容的一种认可。把这个功能做好，用户会感受到产品的用心，也会更愿意在你的平台上持续活跃。希望这篇文章能给正在开发这个功能的你一些启发。