[AD] -- 下方为内容广告,点击支持作者,想过滤广告? -- [AD]
本文于 2023 年 12 月 31 日首发于 https://blog.ypingcn.com/2023/12/31/implementation-linkmic-pk-voiceroom/
转载时务必标记以上来源,本文内容仅共技术分享,不适用于 AI 素材训练。
连麦 PK 是秀场直播中的一个重要核心玩法。而语音房同样包含众多的连麦操作。这三类都是不同的角色在自己位置上的行为。
本文意在对已有功能实现的总结和思考,对比中思考改进点
故在此,对这三类场景的数据管理实现上,总结一下相同点与不同点。
存储位置状态数据
首先,PK 可以理解成是连麦上再次叠加的一层玩法,按照这种逻辑,双人 PK 则是需要双人连麦成功后才有的玩法。按照不同的连麦类型可以分成双人连麦和多人连麦,这两种分法,核心的本质在于一场连麦中的人数是2
还是N
,这个具体数字只需要在发起时确认即可。为统一讨论实现方案,后续仅讨论多人连麦。
其次,语音房是一种包含 8 个人或者 10 个人的位置状态管理,与连麦相比,这个位置信息不需要包含画面相关的信息,取而代之的是说话中的“声纹”。所以连麦和语音房的位置状态数据共同点,至少包含是否有人上座、用户ID的两个基础信息。
再者可以按以下逻辑,抽象出相关的信息存储——
用户->场次的索引、场次->所有位置信息的数据
那么,第一个实现上的差别就产生了,如何存储所有的位置信息并保证其准确性?以下是两个做法
文档型存储
这里的文档型存储,是类比“文档型数据库”的一种说法。将所有位置数据都抽象到同一个 json 或者其他序列化后的文本中,数据库辅以版本号进行管理。每次位置更新,只需要取出对应的版本号和位置数据,更新位置数据后用乐观锁同步到数据库中,同步失败则有限次
地重复之前步骤重试。
连麦会话中的位置信息管理使用了本思路来处理,这样做的好处在于后续可扩展性高,有需要新增的字段数据只需要直接添加,不需要额外的改动。
关系型存储
[AD] -- 下方为内容广告,点击支持作者,想过滤广告? -- [AD]