百万在线的美拍直播弹幕系统的实时推送技术实践之路

  • 时间:
  • 浏览:4
  • 来源:uu快3玩法_uu快3新平台_棋牌

直播弹幕是直播系统的核心功能之一。如保飞快作出一一个有很好扩展性的弹幕系统?如保应对业务飞快发展?相信好多好多 好多好多 工程师/架构师都会 自己的想法。

5)长连接业务模块用于用户进入直播间的验证工作;

《基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)》

1)消息要求更及时:过时的消息对于用户来说不重要;

《一一个基于长连接的安全可扩展的订阅/推送服务实现思路》

《移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)》

这里本地缓存与平常使用的本地缓存问题图片图片,有一一个最大区别:成本问题图片图片。愿因 所有直播间的消息都进行缓存,假设同時 有30000个直播间,每个直播间5种消息类型,本地缓存每隔1秒拉取一次数据,40台前端机,没人 对 Redis 的访问QPS是   30000 * 5 * 40 = 10万。成本太高,或者亲戚朋友没人大直播间才自动开启本地缓存,小直播间不开启。

《魅族230000万长连接的实时消息推送架构的技术实践分享》

  - c. 自动上报长连接性能数据;

2)消息模型的进一步演进。

《百万在线的美拍直播弹幕系统的实时推送技术实践之路》

3)自己发消息。

亲戚朋友采用了订阅推送模型,下图为基本的介绍:

高可用保障建设完成后,迎来了 TFBOYS 在美拍的四场直播,这四场直播峰值同時 在线人数达到近百万,共 28300万人次观看,293000万评论,26.23亿次点赞,直播期间,系统稳定运行,成功抗住压力。

经过考虑选者了 Redis 的 sortedset 存储消息,消息模型如下:

  - 一一个partion, 加锁串行写入 Redis, 最大并发度:1;

  - 黑名单:不允许使用长连接;

回顾了系统的发展过程,达到了原定的前中期使用轮询,中后期使用长连接的预定目标,实践了原定的平衡演进的原则。

1)进入直播间,拉取正在观看直播的用户列表;

5)档位选者:自动选者档位,粒度:某个直播间的某个消息类型。

《移动端实时消息推送技术浅析》

基于这两点,亲戚朋友策略是前中期 HTTP 轮询方案,中后期替换为长连接方案。或者在业务团队进行 HTTP 方案研发的同時 ,基础研发团队也紧锣密鼓地开发长连接系统。

(本文同步发布于:http://www.52im.net/thread-1236-1-1.html)

2)前端机:愿因 延迟小,则只写入一一个 Kafka 的partion;愿因 延迟大,则本身 直播的本身 消息类型写入 Kafka 的多个partion;

2)才能支撑百万用户同時 在线。

2)读消息流程是:前端 -> Redis。

对于用户来说,在直播间一个典型的操作:

 - 一一个partion, 不加锁并行写入 Redis, 最大并发度: 避免机的系统进程池个数;

2)松散的群聊:用户随时进群,随时退群;

  - 白名单:即使长连接关闭愿因 不出灰度范围内,也允许使用长连接。

不过这里有一一个隐藏的并发问题图片图片:用户愿因 丢消息。

《Android端消息推送总结:实现原理、心跳保活、遇到的问题图片图片等》

>>更多这个文章 ……

《极光推送系统大规模高并发架构的技术实践分享》

2)连接层1收到告知消息后,会等待英文一小段时间(毫秒级),再拉取一次用户1的消息,或者推送给用户1。

1)写消息流程是:前端机 -> Kafka -> 避免机 -> Redis;

《实践分享:如保构建一套高可用的移动端消息推送系统?》

回放时,读取数据顺序是: local cache -> Redis -> mysql。localcache 与回放 Redis 都才能只存某个直播本身 消息类型的次责数据,有效控制容量;local cache与回放 Redis 使用SortedSet数据形态,没人 整个系统的数据形态都保持一致。

1)在前端机:同一一个直播间的同本身 消息类型,写入 Kafka 的同一一个 partition;

为了避免本身 问题图片图片,亲戚朋友去掉 了一个机制:

《一一个基于MQTT通信协议的详细Android推送Demo》

3)历史消息不前要重发:用户进群后,离线期间(接听电话)的消息不前要重发。

《扫盲贴:认识MQTT通信协议》

《绝对干货:基于Netty实现海量接入的推送服务技术要点》

解释:

2)客户端的形态:

消息模型及并发问题图片图片避免后,开发就比较顺畅,系统飞快就上线,达到预先预定目标。

长连接整体架构图如下:

直播间消息,相对于IM即时通讯的场景,有其几次特点:

亲戚朋友把礼物,评论,用户的数据都当做消息来看待。

4)推送层存储用户与直播间的订阅关系,负责具体推送。整个连接层与推送层与直播间业务无关,不前要感知到业务的变化;

详细说明:

分为主机房和从机房,写入都会 主机房,读取则由一个机房分担。从而有效保证单机房故障时,能快速恢复。

  - b. 自动降级,愿因 长连接同時 三次连接不上,自动降级为短连接;

《腾讯信鸽技术分享:百亿级实时消息推送的实战经验》

消息的返回条数根据直播间的大小自动调整:小直播间返回允许时间跨度大好多好多 的消息,大直播间则对时间跨度以及消息条数做更严格的限制。

《Go语言构建千万级在线的高并发消息推送系统实践(来自3300公司)》

  - 多个partion, 不加锁并行写入 Redis,最大并发度: Kafka partition个数避免机系统进程池的个数。

避免辦法 :

本身 个形态保证了亲戚朋友长短连接切换的顺利进行。

避免辦法 :

《扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别》

避免辦法 :

《求教android消息推送:GCM、XMPP、MQTT本身 方案的优劣》

《从HTTP到MQTT:一一个基于位置服务的APP数据通信实践概述》

《iOS的推送服务APNs详解:设计思路、技术原理及缺陷等》

丰厚的降级手段:

或者总的流程是:

如下图所示:

2)在避免机:同一一个直播间的同本身 消息类型,通过 synchronized 保证写入 Redis 的串行。

同城双机房部署:

3)避免机:愿因 延迟小,加锁串行写入 Redis;愿因 延迟大,则注销锁。或者有本身 组合,俩个档位,分别是:

1)客户端在使用长连接前,会调用路由服务,获取连接层IP,路由层形态(a. 才能按照百分比灰度;b. 才能对 uid、deviceId、版本进行黑白名单设置):

《深入的聊聊Android消息推送这件小事》

《IBM技术经理访谈:MQTT协议的制定历程、发展现状等》

- 2015年9月加入美图,就职于架构平台部,目前负责次责核心业务和基础设施的研发,包括弹幕、Feed、任务调度和质量监控体系等;

《信鸽团队原创:同時 走过 iOS10 上消息推送(APNS)的坑》

3)进入直播间:获取用户的列表,通过 Zrange 操作来完成。

2)增加一组回放的 Redis;

1)快速上线;

《专访魅族架构师:海量长连接的实时消息推送系统的心得体会》

举例说明:用户1订阅了A直播,A直播有新的消息

- 十余年的后端研发经历,拥有丰厚的后端研发经验,对于构建高可用、高并发的系统有较多实践经验。

1)用户发消息:通过 Zadd,其中 score 消息的相对时间;

本地缓存:前端机每隔1秒左右取拉取一次直播间的消息,用户到前端机轮询数据时,从本地缓存读取数据;

如上图所示,某个用户从第6号评论始于了了英语 拉取,同時 一个用户在发表评论,分别是10,11号评论。愿因 11号评论先写入,用户刚好把6,7,8,9,11号拉走,用户下次再拉注销息,就从12号始于了了英语 拉取,结果是:用户没人 都看10号消息。

2)接收直播间的消息:通过 ZrangeByScore 操作,两秒一次轮询;

- 毕业于西安交通大学,曾任职于网易和新浪微博,微博工作期间负责开放平台业务和技术体系建设;

6)服务端之间的通讯使用基础研发团队研发的tardis框架来进行服务的调用,该框架基于 gRPC,使用 etcd 做服务发现。

愿因 是大直播间(订阅用户多),没人 推送层与连接层的告知/拉取模型,就会自动降级为广播模型。

上线后,随着量的逐渐增加,系统陆续暴露出一个比较严重的问题图片图片,亲戚朋友一一进行了避免。

3)前端机增加回放的 local cache。

1)直播始于了了英语 后,数据备份到 mysql;

(本文同步发布于:http://www.52im.net/thread-1236-1-1.html)

消息串行写入 Redis,愿因 某个直播间消息量很大,没人 消息会堆积在 Kafka 中,消息延迟较大。

3)连接层只负责与客户端保持长连接,没人 任何推送的业务逻辑。从而大大减少重启的次数,从而保持用户连接的稳定;

  - a. 同時 支持长连接和短连接,可根据路由服务的配置来决定;

4)延迟程度判断:前端机写入消息时,打上消息的统一时间戳,避免机拿到后,延迟时间 = 现在时间 - 时间戳;

弹幕数据也支持回放,直播始于了了英语 后,什么数据存放于 Redis 中,在回放时,会与直播的数据竞争 Redis 的 cpu 资源。

《为什么我微信、QQ没人 的IM工具不使用GCM服务推送消息?》

解释:

全链路的业务监控:

美拍直播弹幕系统在设计初期的核心要求是:

1)针对机房在北京,南方好多好多 地区会占据 连接时间长的情况表(亲戚朋友如保让长连接更靠近用户?);

亲戚朋友经历客户端一个版本的迭代,实现了两端(Android 与 iOS)长连接对短连接的替换,愿因 有灰度和黑白名单的支持,替换非常平稳,用户无感知。

2)接收直播间持续接收弹幕消息;

 - 多个partition,加锁串行写入 Redis, 最大并发度:Kafka partion的个数;

1)消息写入流程优化:前端机-> Kafka -> 避免机 -> Redis;

(本文同步发布于:http://www.52im.net/thread-1236-1-1.html )

1)推送层查询订阅关系后,知道有用户1订阅了A直播,同時 知道用户1在连接层1本身 节点上,没人 就会告知连接层有新的消息;

直播弹幕指直播间的用户,礼物,评论,点赞等消息,是直播间交互的重要手段。美拍直播弹幕系统从 2015 年 11 月到现在,经过了一个阶段的演进,目前能支撑百万用户同時 在线。比较好地诠释了根据项目的发展阶段进行平衡演进的过程。本身 个阶段分别是快速上线、高可用保障体系建设、长连接演进。具体我将在正文中展开,请继续往下阅读。

本文作者是美拍的架构师,经历了直播弹幕从无到有,从小到大的过程,借此文为亲戚朋友分享构建弹幕系统的经验,希望能为正在开发或正打算开发弹幕、消息推送、IM聊天等系统的技术同行带来好多好多 启发。

用户轮询最新消息,前要进行 Redis 的 ZrangByScore 操作,redis slave 的性能瓶颈较大。

从未来的发展来看,计划要做的事情有: