海量在线消息互动架构介绍

1、海量在线消息互动架构介绍如何设计海量在线的直播间消息互动平台，容灾和高可用议题包含淘宝是如何设计直播消息架构的，包括长连网关、群发网关在爆发式增长的场景下保持系统稳定，负载均匀、并实现可靠投递。摘要无互动、不直播发不出，看不到，消息延迟会影晌用户体验点播、直播对技术挑战视频与消息是强实时互动消息在直播场景中的重要性消息量N+1个生产者，N+1个消费者，交叉广播10万人 * 100互动=1000万QPS高并发消息高并发、爆炸式增长，服务器会瞬间打满666低时延如何无时差将消息发给海量的用户互动消息有哪些挑战先订个小目标100万在线10万 并发低时延 秒级容灾 秒级轮询：简单，实时性差、体验与负载

2、难平衡。comet：减少了请求次数，频繁建立连接。long-polling、stream长连接：次建连，双工，心跳开销小，实时。构建消息通道及选型直播 业务APPAPP进出、发消息长连 接长连 接APP过千简单：宅机有损、网关独占实时消息长连接入架构基础模型接入网关群发 广播直播 业务消息 路由H5消息 路由IOS长连接AndroidWebSocket进出、发消息Ali-Cloud-Channel-ServiceACCS亿级网关：支撑阿里所有移动业务双工：跨平台、流量少、耗电少低时延：1秒法则，流畅移动体验安全：全站HTTPS，防劫持开放ACCS移动网关的基石ACCS服务架构接入 服务器设备管

3、理分发网关Client在线状态管理队列服 务状态汇报 状态查询设备绑定 用户绑定设备上下线上下行数据双向链接ServiceAServiceB Service数据上行数据下行异步投递SEARCH多维直播消息和群聊的本质区别Servercache实时消息的三种广播形式群聊弹幕直播间互动参与人数几个几百几百几十万几百几百万互动需求成员间互动弱互动-表达成员-主播互动消息一致性强弱强即时要求般(上下文关联）弱强(视频同步)消息并发度低并发高并发超高并发人群突发性相对固定流量突发流量突发直播消息和群聊的本质区别ServerServerProxycachecache直播间要解决哪几个问题用户拆分 均匀路由

4、调度 即时高并发 消息爆炸消息一致 重复、丢失随机分配：宅机后、需要重新建立订阅关系，重复动态(按需)分桶：先进先出，容量不均，多次进入，消息重复固定分段(segment)：按用户取模，保证个用户在唯的段上用户拆分对比：固定分段能消除重复、流量均匀、便千容灾后数据迁移1u2numod(n)uu专注千segment与节点的关系，而不是用户尽量少的变化 致性Hash设置虚拟节点，解决负载平衡问题路由调度 节点负载如何做到不重复、不丢失用户进出房间，直接到节点本地Cache消息广播的同时调整段变更并发与消息一致性本地Cache订阅本地Cache本地Cache广播用户A退出用户BRedis群发服务seg(1-10)seg(a-g)seg(h-n)互动直播群发网关架构订阅群发网关 订阅关系、房间分片哏速、淘汰消息系统优先级、过滤、存 储H5发商品、红AndroidIOSDB主播创建 房间创建 房间业务系统订阅群发关系统计进入退出发消息小房间的过度设计：增加系统调用次数一致性Hash的不足：不完全均匀无效订阅：被动淘汰、主动淘汰消息带宽：基千时间片丢弃，大小包合并消息重投到达率：消息重投与推拉结合带来的一些问题及改进一致性Hash改进与收敛bind & sendt1.1-NT.1topicTOPICsegment1-Ntn.1-NT.nT.N均匀 Hash致HashClientCl