如何快速构建社交APP中的语音房

📃 文章须自出机杼，成一家风骨。 —— 魏收

一、需求背景

近年来，在线语音聊天的用户数量不断增加。语音的信息密度比文字图片更丰富，同时比视频更简单；是新时代捕捉用户、实现流量变现的有效途径。在陌生人社交领域，为了满足用户的情感需求和娱乐需求，小鱼公司还在自己的应用中推出了语音室功能。

二、什么是语音房

• *什么是社交语音房？

语音室是基于一对一语音通话和语音聊天的多人聊天交流场景。支持同一房间内多人同时语音交互。这里的语音交互不同于发送语音消息。它类似于多人语音通话，可以相互实时通信。

• *社交语音房能做什么？

社交中的语音房最核心的目的一定是促进用户之间的交流，快速提升用户间的关系；语音房能够通过多人同时通话的方式；要比文字，语音消息的方式更富有情感，更直接的让用户之间进行情感交流。可以实现：纯语音聊天、游戏互动、情感电台、线上 KTV 等场景。

三、功能描述

• *场景化

语音房功能可以比较契合生活中的 KTV 场景，在实际应用中也确实可以实现线上歌房。

1. KTV 的房间是相互隔绝的（不要钻牛角尖），不同的房间是听不到声音的；语音房也一样，每个房间相互隔离，没有联系。
2. KTV 的房间中麦克风数量是有限的，语音房中同样提供的上麦数量是有限的。
3. KTV 的房间中可以容纳的人数是远大于能够拿到麦克风唱歌的人数的；语音房中能够容纳的人数同样是远大于能够上麦说话唱歌的数量。
4. KTV 的房间中拿着麦克风的时候，可以选择性唱歌；语音房中上麦的用户可以选择不说话，可以进行控制。

5. KTV 中有限的麦克风是流动性的，不是仅仅某几个人能够唱歌；语音房的上下麦就是对有限的麦位进行流动，麦位数量不变，但是拿着麦的人是可以变化的。

6. 功能描述

7. *创建语音房

首先，我们需要播放声音室。我们需要创建一个房间。创建房间需要设置房间的一些基本信息，如下图所示：

在创建房间时，您可以自定义房间名称，也可以根据系统提供的名称随机获取。

• *创建语音房流程图

完成房间信息后，需要最后一步才能成功创建房间。点击Create，客户端请求服务器接口完成房间创建。服务器的主要内部进程如下：

初始化房间流程中，服务端只是进行存储用户设置的数据及初始化房间麦位信息；以及生成对应房间的靓号及对应的 rtc 频道 id 返回给客户端，客户端进行创建频道信息等操作。

• *房间基础信息

SQL
 -- ----------------------------
 -- Table structure for room
 -- ----------------------------
 DROP TABLE IF EXISTS room;
 CREATE TABLE room (
  room_id bigint(20) NOT NULL,
  app_id bigint(20) NOT NULL,
  create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '更新时间',
  administrators varchar(1000) DEFAULT NULL COMMENT '房间管理员信息',
  last_close_time bigint(20) DEFAULT NULL COMMENT 'unix时间戳, 上次打烊时间',
  last_open_time bigint(20) DEFAULT NULL COMMENT 'unix时间戳, 上次营业时间',
  mic_mode varchar(255) NOT NULL COMMENT '上麦模式 （自由上麦/申请上麦模式）',
  roomIcon varchar(255) DEFAULT NULL COMMENT '房间外部展示图片',
  room_desc varchar(1000) DEFAULT NULL COMMENT '房间公告',
  room_layout int(11) DEFAULT 8 COMMENT '房间麦位数量',
  room_name varchar(255) DEFAULT NULL COMMENT '房间名字',
  room_number int(11) NOT NULL COMMENT '房间号（过滤靓号）',
  room_source varchar(255) NOT NULL COMMENT '房间创建的渠道, 也可以认为是房间的归属主体',
  room_type varchar(255) NOT NULL COMMENT '文字房: ROOM_TYPE_TEXT, 语音房: ROOM_TYPE_VOICE',
  room_status varchar(255) NOT NULL COMMENT '开启: ROOM_STATUS_OPEN, 关闭: ROOM_STATUS_CLOSE, 被禁: ROOM_STATUS_BANNED',
  room_tag varchar(255) DEFAULT NULL COMMENT '房间标识',
  room_owner_user_id bigint(20) DEFAULT NULL COMMENT '房主id',
  room_owner_organization_id bigint(20) DEFAULT NULL COMMENT '组织id',
  channel_id bigint(20) DEFAULT NULL COMMENT '房间对应第三方的唯一频道信息',
  PRIMARY KEY (room_id)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC;

• 房间和管理员的基本信息也会放在表中，导致表中的字段更多，当管理员修改时，房间的基本信息也会发生变化。事实上，可以删除与管理员相关的信息。

  [En]

  the basic information of the room and the administrator are also placed in the table, resulting in more fields in the table, and the basic information of the room will also be changed when the administrator is modified. In fact, the administrator-related information can be removed.*

• mic_mode：控制房间用户的上麦模式，例如：申请上麦模式，需要由用户进行申请上麦，管理员/房主同意。

• room_layout：用于控制房间能够进行连麦的数量，能够在指定范围内修改房间麦位的数量。
• room_source：房间创建的渠道，每个用户可以在不同的渠道创建一个房间；这样子的好处是可以在一个应用支持不同的场景使用聊天室。
• room_number：房间编号，过滤掉靓号，可以后续进行靓号的运营。
• room_owner_organization_id：创建渠道（room_source）如果是组织类型的，需要存储用户对应的组织id。

• room_game：在房间基础之上可以增加新的游戏玩法，例如：拍卖，婚礼等。

• 创建语音房接口
  *

Java

api: /api/room/room-message  //优先根据房间id获取房间信息 （无房间信息，返回默认参数值）
 /* 传入参数
 （根据调用者id以及房间类型获取是否创建过房间以及房间信息，如果没有创建过该类型房间返回默认参数（图片为创建者头像、房间展示类型为普通房、标签默认为相亲交友房））
  房间没有头像默认使用房主在应用中头像
  默认展示方式位普通房
  默认房间类型为相亲交友 */
Long roomId

api: /api/room/operation-room   //操作房间（创建/编辑）
/* 传入参数
房间id（不传为创建，传参为打开）*/
Long roomId
/* （RoomTag 房间标签 ROOM_TAG_FRIEND 相亲交友 ROOM_TAG_TALK 闲聊唠嗑 ROOM_TAG_AUCTION 心动拍卖）*/
String tag
/* 房间名称 */
String name
/* 房间公告 */
String announcement
/* 房间背景图 */
String coverUrl
/* 排麦模式  MIC_MODE_FREEDOM 自由麦    MIC_MODE_QUEUE 排麦 */
String mode
/* 房间展示类型  SECRET_ROOM 私密房    GENERAL_ROOM 普通房间 */
String subType
/* 卡座位置数量 默认8位 范围[4，12] */
Integer boothSize

• *上麦

首先，如下图所示，上麦模式分为自由模式和排队模式。顾名思义，只要房间里没有用户，点击后即可连麦。排队模式为普通用户(管理员/房主除外)，不能直接上麦。点击加入按钮后，您将进入排队队列，等待管理员/房主(只有管理员/房主才有权限)的同意，才能按照上麦规则进行上麦。

其次，加播的类型分为主动加播和被动加播，从发展的角度进行区分；用户主动点击加播操作称为主动加播；管理员/房主邀请用户加播，用户点击确认为被动加播。被动广播的数字如下：

• *上麦流程图

上麦流程中需要针对用户的权限进行校验，及根据当前房间的模式及业务方选择的策略方式（根据角色位置上麦/根据位置倒序上麦等）进行上麦或者排队操作；最后需要发送房间麦位上的数据发送 rtm 到客户端进行渲染。

• *麦位信息

 -- ----------------------------
 -- Table structure for room_booth
 -- ----------------------------
 DROP TABLE IF EXISTS room_booth;
 CREATE TABLE room_booth (
   room_booth_id bigint(20) NOT NULL,
   create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
   update_time timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '更新时间',
   booth_abilities varchar(255) NOT NULL COMMENT '主持麦位: BOOTH_ABILITIES_HOST, 普通麦位: BOOTH_ABILITIES_NORMAL',
   booth_index int(11) NOT NULL COMMENT '卡座位置',
   room_id bigint(20) NOT NULL,
   user_id bigint(20) DEFAULT NULL COMMENT '当前在卡座的用户',
   booth_status varchar(50) DEFAULT NULL COMMENT '卡座声音状态',
   status varchar(50) DEFAULT NULL COMMENT '数据状态',
   PRIMARY KEY (room_booth_id)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC;

小麦钻头的信息是基于房间尺寸，而不是用户的尺寸。当业务方呼叫初始化房间时，房间初始化的小麦数据数量一般由业务方控制。

1. booth_index：当前位置的下标位置。
2. booth_abilities：当前麦位的类型，由业务方来控制麦位的数据以及对应麦位的类型；与上麦的策略相关。

api: /api/room/set-seat //上麦/排麦（上麦相关的都调用该接口，根据当前房间上麦模式，进行对应逻辑操作）
/* 传入参数
 语音房id */
Long roomId
/* 所上的麦位 如果不传 默认按照倒叙上麦，序号从0开始，0表示第一个位置 */
Integer seatNum

api: /api/room/invite-set-seat   将用户抱上麦（该接口由房主/管理员调用用户邀请用户上麦，被邀请的用户将弹出是否同意上麦的弹框）
/* 传入参数
  被抱上麦用户id*/
Long userId
/* 语音房id */
Long roomId

• 相关概念
• *语音房

允许单人/多人在一个房间频道内进行语音聊天或者进行一些娱乐活动的语音交流玩法。

• *RTM 消息

通过类似于房间内打字交互的方式，服务器和客户端使用约定的格式来实现相应指令的互通，从而实现客户端根据具体指令进行相应的动作。

• *RTC

可以理解为一个语音房对应一个 RTC 频道，在语音房内需要听到声音、发出声音，首先都需要加入到该频道中；类似于双方互相打电话

• *上/下麦

根据语音室提供的麦比特数量加入聊天和退出聊天；未加入直播的用户无法将语音传输到频道中，让语音室中的其他用户能够听到。

• *开/闭麦

上麦后的用户提供了开启/关闭自己的麦克风，选择是否将声音传入频道内。

• *主动行为/被动行为

主动行为可以理解为，触发某个动作，用户自己进行处罚即可完成；例如：自由上下麦模式下的上麦/下麦、开麦/闭麦、加入/离开频道等。

被动行为可以理解为，该动作用户无法自己完成，需要通知到相应用户，由另一用户自己去触发才可以完成的动作；例如：抱上麦/抱下麦、禁麦/解除禁麦等。

四、技术方案

• *目的

此次语音室功能的建设，不仅仅是对这一能力的简单实现，更需要将语音室功能打造成新的中间平台模块，方便后续新品快速接入，零服务器工作量，降低新品功能上线成本，提升功能接入效率。

• 设计

• *用户角色

• 房主：该语音房的创建者，即房间的拥有者，拥有最高的权限；房间跟用户绑定，一个用户在一种类型下只能创建一个直播间。

• 管理员：房间的管理员由房主来控制，一个房间可以有多个管理员，一个用户也可以是多个房间的管理员。
• 麦上用户：加入了 rtc 频道，并且在房间内能够说话交流的用户。

• 观众：加入了 rtc 频道，只能听到房间的声音但是不能说话的用户。

• 交互

• *交互流程图

架构流程客户端需要先调用到业务方，由业务方再调用到语音房服务，语音房服务返回相关的结果以及发送指定模版化的 rtm 通知给客户端；图中涉及到送礼相关功能由金币送礼相关的服务处理。

• 问题及方案
• *幽灵麦问题

原因：由于整套逻辑涉及到，客户端、服务端、声网三方，会涉及到服务端的数据与声网的数据不同步问题；幽灵麦问题出现的几个原因主要有：

1. 服务端将用户 a 的上麦操作更新成功，但是客户端调用声网的 SDK 操作中出现了问题，导致该麦上有用户 a 头像，但其实是一个无法说话的麦位；
2. 麦上的用户 a 正常上麦了，将 app 进程直接杀掉，通过声网的回调，服务端由于服务异常或者其他原因导致没有收到该回调信息，导致用户 a 在麦上，但是实际已经离开了 app，是一个幽灵麦。

方案：整体下来，由于麦位上有假用户数据；当房间管理员或者房主发现用户为幽灵麦位的时候，会进行抱下麦，抱下麦会有频率相关的策略，服务端根据策略与声网校验用户与当前频道的关系，不在当前频道进行清理。

五、总结

目前市面上很多种社交软件都具备多人语音聊天功能，这反映出在陌生人社交领域，这一功能可以让陌生人更深入地交流，快速升温。在基本能力完成这一功能的基础上，我们可以继续完善丰富的语音房间的发挥，可以是游戏，也可以是各种程序性的互动。相信在未来一段时间内，多人发声室的玩法会得到更多用户的认可。后续，我们还将继续推出语音房游戏，丰富用户体验。

Original: https://blog.csdn.net/yizhoucp/article/details/122189827
Author: 晓宇科技技术团队
Title: 如何快速构建社交APP中的语音房