[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]