百度直播消息服务架构实践

1. 同时参与人数不同：群聊的参与人数上千人就是很大的群了；但对于高热度的大型直播场景，例如国庆、阅兵、春晚等，单直播间累计用户是百万甚至千万量级的集合，同时在线人数可达数百万人。
2. 用户与群和直播间的关系不同：用户进群退群，是相对低频的操作，用户集合相对固定，用户进出的变更频度不会特别高；而用户进出直播间，是非常频繁的，高热度直播的单直播间每秒面临上万用户的进出变更。
3. 持续时间不同：群聊建立后，聊天持续时间可能比较长，几天到数月都有；而直播间大部分持续不超过几个小时。

1. 单直播间每秒上万用户的进出变更；实际进入直播间峰值不超过2万QPS，退出也不超过2万QPS。
2. 单直播间同时数百万用户在线
3. 单直播间累计用户达千万量级

1. 实时性：如果消息服务端做简单消峰处理，峰值消息的堆积，会造成整体消息延时增大，且延时可能产生很大的累积效应，消息与直播视频流在时间线上产生很大的偏差，影响用户观看直播时互动的实时性。
2. 端体验和性能：端展示各类用户聊天和系统消息，一般一屏不超过10-20条；如果每秒有超过20条的消息下发，端上展示的消息基本会持续刷屏；再考虑到有礼物消息的特效等；大量的消息，对端的处理和展示，带来持续高负荷。所以，对于一个长时间观看直播的用户端来说，如果出现持续的大量消息，端的消息消费会有显著的性能压力，且过多消息会有累积效应。

1. 实时性方面，端和端的消息要达到秒级；
2. 性能方面，消息服务能支持同一直播间内百万以上用户同时在线下发；
3. 而对于峰值的过多消息，丢弃是合理适当的处理方式；
4. 基于合理的端用户体验，单直播间内每秒消息数假设不超过N条。

1. 对于群group-1，分配一个群公共消息信箱group-mbox-1；
2. 群group-1内的用户user-1，由手机端APP-1上发出消息msg-1；
3. 服务端接收到消息msg-1，检查user-1是否有权限，如有权限，将msg-1存储到群信箱group-mbox-1，生成相应msgID-1；
4. 服务端查询group-1对应的用户列表groupUserList-1；
5. 基于groupUserList-1拆分出所有独立群用户：user-1、user-2。。。user-n；
6. 对于每一个用户user-i来说，需要查询用户user-i的所在设备device-i-1、device-i-2、device-i-m（因为一个账号可能登录多个设备）；
7. 对于每个设备device-i-j来说，长连接通道都会建立一个独立的长连接connect-j以服务于该设备；但由于connect-j是由端上APP-1连接到长连接服务的，具有动态性，所以，查询device-i-j与connect-j的对应关系时，需要依赖一个路由服务route来完成查询；
8. 在查得connect-j后，可以通过connect-j下发msg-1的通知groupmsg-notify-1；
9. 如果用户user-i正在使用device-i-j的手机端APP-1，用户user-i就可以立即从长连接connect-j上收到msg-1的通知groupmsg-notify-1；
10. 在接收到groupmsg-notify-1后，手机端APP-1中的消息SDK根据端本地历史消息记录的最后一条消息latestMsg对应的消息ID即latestMsgID，来向服务端发起拉消息请求fetchMsg，拉取group-1中从latestMsgID+1到最新的所有消息；
11. 服务端收到拉消息请求fetchMsg后，从group-mbox-1中取出latestMsgID+1到最新的所有消息，返回给端；如果消息过多，可能需要端分页拉取；
12. 端APP-1拉取到group-1中从latestMsgID+1到最新的所有消息，可以做展示；在用户在会话中阅读后，需要设置所有新消息的已读状态或者会话已读状态。

1. 对于①拆分用户列表和②查询用户对应设备，如果存储上将二者合并集中起来，也就是优化直播间内用户列表的存储，扩展设备信息，可以减少一次user->device的百万QPS查询，可以优化。
   
   
2. 对于④下行通知和⑤端拉取fetchMsg的可靠消息拉取模式，考虑到直播消息允许部分折损丢弃，可以只做单向消息下发，而不做拉取，对于大部分连接保持在线的用户，也是可以接受的。所以可以优化，只保留下行通知（包含消息体），而舍弃端拉取。
   
   
3. 对于⑥消息设置已读，直播场景下可以考虑简化舍弃。
   
   

1. 每个长连接组播mcast有全局唯一的标识mcastID。
2. 长连接组播mcast支持创建、删除、修改、查询等管理操作。
3. 长连接组播mcast是若干长连接在线用户的连接connect的集合。
4. 一个用户user-i在设备device-i-j上，对于特定应用APP-k来说，建立唯一的一个长连接connect-j-k；（此处暂时不区别登录用户和非登录用户）。
5. 长连接组播mcast与组内长连接connect-j-k的关系维护，不需要额外的独立存储，是维护在每个长连接服务的实例上。

1. 客户端调用消息sdk加入mcast-m。
2. 消息sdk通过长连接，发出上行请求mcastJoin（mcast-m）。
3. 业务层收到来自长连接实例lcs-i上的连接connect-i的mcastJoin请求，校验mcast-m的合法性。
4. 业务层请求路由层建立基于组播mcast-m的组播路由mcastRoute-m，将长连接实例lcs-i加入组播路由mcastRoute-m中。
5. 业务层请求长连接服务层，请求mcastJoin所在长连接实例lcs-i，将请求所在连接connect-i加入到mcastConnectList-m中。

1. 一条消息msg-1推送，目的地是ID为mcast-m组播；
2. 后端业务模块根据目的mcast-m，做一致性hash选择出mcast路由分发模块实例mcastRouter- i，发送msg-1到mcastRouter-i；
3. mcast分发路由模块实例mcastRouter-i，根据mcast-m的组播路由mcastRoute-m，查找所对应的接入实例路由记录列表mcastLcsList-m，拆分出mcast-m所有的长连接接入实例lcs-1..lcs-M，分别并发发送msg-1到长连接实例上；
4. 一个长连接服务实例lcs-j，收到消息msg-1推送后，根据组播mcast-m查找组播连接列表mcastConnectList-m，查出mcast-m内所有的连接connect-m-1..connect-m-N，并发推送msg-1到消息客户端sdk-m-1..sdk-m-N；
5. 消息客户端sdk-m-o收到msg-1后，递交给上层业务（例如直播sdk）。

1. 组播mcast的路由维护，主要压力在于mcastJoin和mcastLeave，而Join的量级峰值请求很难超过2万qps；访问压力比百万低两个数量级。
2. 组播mcast的消息推送流程，在一级路由mcastRoute拆分到长连接实例时，一般在几十到百量级，成本很低。
3. 组播mcast在长连接单实例内的消息推送，是单进程内的多连接并发发送，经优化后线上实测，在单实例保持25W长连接的情况下，单实例压测可达8Wqps的mcast稳定下发，保守按5Wqps容量评估；多个长连接实例间，是完全的并发，可以较容易的水平扩容。
4. 综上可知，对于100Wqps的下发，20个长连接实例就可以完全负荷(20*5W=100W)，且有一定裕量。如果500Wqps的下发，也不超过100实例；1000W的下发，如果以8W单实例较大的负荷承载，125实例就可以支持。
   
   

2.4.7.1 延时聚合

• 压缩

• 限速

• 优先级

• 访问点

• HTTPDNS

• 心跳优化

• 断链恢复

1. 消息服务和路由层压力较轻，整体压力只由长连接层承载，易于水平扩容。
2. 基于延时聚合下发，辅以压缩限速，可以很好的解决下行QPS与带宽的性能问题。
3. 系统整体下行的QPS和带宽是完全可控的。100W在线用户的下行最大QPS是100W，500W在线用户的下行最大QPS是500W。单实例的下发能力5-8万QPS是稳定的。因此，可以很容易判断整体的系统容量，特殊场景是否需要扩容。
4. mcast机制虽然是针对直播场景提出的，但本身设计具有通用性，可以应用于其他需要实时在线大量用户分组的消息推送场景。

1. 对于用户消息和其他有持久化需要的消息，全部写入这个消息信箱。
2. 用户可以指定组播mcastID，按时间区间和要拉取得消息条数，来获取组播mcast的历史消息。

1. 消息信箱内的一条消息msg，有唯一的消息标识符msgID。
2. 一条消息msg，还包括有发送方信息、接收方信息、消息类型、消息内容等字段，此处可以暂时忽略。
3. 每条消息可以设置过期时间，消息过期后不能访问到。
4. 每条消息可以设置已读状态。
5. 一个消息信箱mbox，有唯一的信箱标识符mboxID。
6. 一个消息信箱mbox是一个容器，存储有序的消息列表msgList；消息列表msgList按msgID排序的。
7. 消息信箱服务，对指定信箱mbox支持单条消息或批量消息的写入。
8. 消息信箱服务，对指定信箱mbox支持基于msgID的单条消息或批量消息的查找。
9. 消息信箱服务，对指定信息mbox支持从msgID-begin到msgID-end的范围查找。

1. 用户送礼给主播，主播侧需要尽快、可靠地收到礼物消息通知，才能及时的给予用户反馈。
2. 送出礼物的用户，本地就可及时展示礼物效果，无消息通知强诉求。
3. 直播间内其他用户，需要收到礼物消息，以展示礼物效果，提升直播间互动氛围，激发其他用户送礼。
4. 礼物消息涉及用户订单和购买行为，需要由服务端确认发出。
5. 礼物消息优先级明显高于其他聊天消息、系统消息。

1. 增加一个独立的可靠消息组播mcast通道（如图4中组播mcast-2），专供高优可靠消息的收发；与其他普通消息、系统消息在数据流层面隔离，减少相互干扰；
2. 对于普通用户侧的端消息SDK，礼物消息组播mcast通道虽然是新增独立通道，消息收发逻辑与普通消息组播mcast通道保持一致；
3. 对于主播侧，端消息SDK对于礼物消息组播mcast通道，需要支持推拉结合模式，以保障礼物消息的全部到达；即使有短暂的掉线，也需要取到全部礼物消息；
4. 对于主播侧，在极端情况下，如果长连接建连有异常，消息SDK可以通过短连接接口轮询，来拉取礼物组播mcast信箱消息来兜底。

1. 如何支持多种客户端场景，安卓、iOS、H5、小程序、PC。
2. 如何支持同一场直播的消息在百度APP和好看、全民、贴吧等矩阵APP的打通。
3. 如何支持非登录用户。IM一般是支持登录用户，而直播场景也需要支持非登录用户。
4. 长连接服务如果出了严重问题，是否有端获取消息的降级通道。
5. 直播消息审核的机审人审如何做，如何支持先发后审和先审后发。
6. 如何支持跨多个直播间的消息。
7. 直播消息服务是如何支持创新业务的，如答题直播、直播带货、直播连麦等。

小度熊

手机支架