开发一个优秀的RTC系统需要具备哪些技术储备呢,一组负责实时通信服务数据统计的缓存机器发生故障

摘要即时通讯云服务商LeanCloud
2016年6月30日因一组负责实时通信服务数据统计的缓存机器发生故障,而导致雪崩致使即时通讯服务瘫痪43分钟之久!以下消息来自LeanCloud官方:6
月 30 日晚上 8
点左右,我们的实时通信服务发生了故障,导致大量应用的终端用户无法登录和发送消息,时间持续约
40 分钟,详细情况汇总如下。故障时间2016-06-30日 19:58 - 20:41(共计 43
分钟)影响范围LeanCloud
国内节点的实时通信服务受到影响(无法登录和发送消息),其它服务正常;美国节点一切服务正常。事故经过19:58
一组负责实时通信服务数据统计的缓存机器发生故障,导致用户登录或发送消息出现阻塞,类似操作开始消耗内部线程池资源;20:05
线程池资源耗尽,所有用户登录过程都会失败;20:22
确定了故障原因,开始重启缓存服务程序,但是服务程序所在机器因为压力过大失去响应,转而重启物理机器;20:33
缓存服务恢复正常,登录和发消息等请求开始恢复正常(为了加速我们新增了部分实时通信服务程序,以增加响应能力);20:41
实时通信服务恢复正常。下图中的黄线是故障时段前后的登录请求数量变化趋势曲线,与上述故障时间线吻合:后续改进措施聊天服务监控程序改由
Marathon
来自动部署并执行。该监控程序因前期的一次操作而被暂停,结果未能捕捉到此次服务异常,所以我们加入程序化的手段来保证其始终运行。(已完成)增加对统计数据缓存服务的监控。(已完成)增加对于登录请求数异常变化的监控。(已完成)进一步优化实时通信服务的架构,针对所有环节做好容错,防止类似的阻塞操作再次出现。(一周内解决)即时通讯云
LeanCloud 官方网站:

摘要在移动互联网飞速发展的今天,各种应用都渴望加入RTC的功能,实现用户与企业,用户与用户之间的实时音视频交流。于是问题出现了,开发一个RTC系统需要什么技术储备?概述  实时通讯系统,RTC(real
time
communication),是最近互联网应用的一个新领域。RTC系统的应用极其广泛,我们常见的视频电话,会议系统,远程桌面与控制都是RTC系统的一个应用。在移动互联网飞速发展的今天,各种应用都渴望加入RTC的功能,实现用户与企业,用户与用户之间的音视频交流。于是问题出现了,开发一个RTC系统需要什么技术储备?  有人说只需要懂javascript就可以了。WebRTC的出现极大的降低了RTC的开发门槛。只需要编写javascript代码就可以实现浏览器之间的音视频通话。且不论通话质量,浏览器的兼容性,网络穿透能力,那些不使用HTML的原生APP怎么办?  又有人提出WebRTC也支持Native开发,只要有懂C++和相关应用平台(Android,iOS,Windows,Mac)开发的软件工程师就可以了。WebRTC确实可以在这些平台上开发原生的应用。将WebRTC编译打包后嵌入APP可以实现RTC的功能,就是说能通了。但一个合格的RTC系统仅仅是能通就可以了吗?  以音视频通话为例,用户期望的RTC应用应该是:通话不卡不掉低延时,声音清晰真实无回声,画面流畅清晰无卡顿。如果直接采用上面WebRTC集成,我们很容易发现,在大多数情况下,通话并不像原来想象的那样完美。由于网络的原因,通话断断续续,延时很大。由于终端的适配不好,语音通话回声严重,噪声严重影响体验。视频不清楚,不流畅。  RTC系统的每一个部分都需要优化,需要打磨,才能打造出完美的用户体验。现在的问题是,开发一个优秀的RTC系统需要具备哪些技术储备呢?终端  解决语音通话的问题,首先需要有合适的语音编解码器,然后需要调整音频处理模块的算法。这里面内容比较广,有噪声消除,回声抑制,自动增益。比较前沿的还有多麦克风降噪,盲扩增强等等。总之这些都需要算法的储备,涉及语音信号处理、统计信号处理等方面的内容。  有了算法还不够,还需要有好的实现。各个平台(Android,iOS,Windows,Mac)底层音频系统也需要深入了解。有时候算法挺好的,但有些机器先天不足,比较特别,需要特殊处理。这需要投入许多人力物力对各种型号的硬件做适配。优秀的系统可能需要适配几百上千个不同的设备。  同样的,对于视频,我们需要对视频编解码器有深入的了解。这样才能用最低的码率展示清晰的视频画面。视频的前后处理,比如降噪,增强(包括流行的美颜)也少不了。这就需要图像与视频信号处理。视频数据量比较大,对底层视频设备也需要深入研究。适配也少不了。网络  说完了终端,再说说网络。网络抗丢包是必备选项。互联网不是一个可靠的实时音视频传输网络。在不可靠的网络中实现可靠的音视频传输考验系统设计的能力。这里既有信道编码的理论也有网络对抗的实际经验。  如果要实现可靠的云服务,遍布全球的服务器网络也必不可少。高可用性,负载均衡等等…  现在我们知道开发一个RTC系统需要什么技术了。这个系统涉及到几乎所有的网络与音视频处理的理论与实践。作者简介  郑仲侯,声网Agora.io音视频构架师。硕士毕业于上海交通大学电子工程系,信号处理专业。先后在National
Instruments,SRS,DTS工作十余年。专注信号处理算法与实践,加入Agora后从事音视频引擎的开发,持有双麦降噪专利。

摘要即时通讯云服务商LeanCloud
2016年7月13日因由于突发硬件故障,导致雪崩致使即时通讯服务瘫痪48分钟之久!以下消息来自LeanCloud官方:7
月 13 日早上 9
点左右,我们内部在使用中国节点的应用控制台时遇到报错,于是很快便定位到某一集群由于突发硬件故障而引起存储服务中断,经过抢修问题得以解决。大约一小时后正当我们在继续对该集群进行加固处理时,突然遇到流量高峰,该集群的性能逐渐下降并再次发生了故障。此次故障影响到中国节点上
20%
的应用无法使用存储及其依赖服务,如实时通信、云引擎等。美国节点不受影响。故障时间及范围08:49

  • 09:08:存储服务内部某一集群发生硬件故障,导致 20%
    的应用的存储服务中断(约 19 分钟)。09:53 –
    10:22:该集群受到流量冲击后性能降低并再次瘫痪(约 29
    分钟)。前后共持续约 48
    分钟。事故过程08:49:应用控制台出现报错,立即进行排查。08:56:发现某个集群硬件故障,导致集群性能不断降低,响应过于缓慢,到几乎不可用。09:08:隔离故障机器,重启相关服务后,集群慢慢恢复了正常。09:53:有大量连接涌入,堵塞了存储系统的读写队列,使得该集群性能再次下降。09:58:该集群响应过于缓慢,几乎不可用。开始阻断连接,扩充集群并重启集群上的相关服务。10:22:集群服务逐步恢复,并重新开放连接。后续改进措施加强对集群硬件失败的监控和报警。提高自动化故障处理能力,降低系统
    downtime
    时间。尽快升级底层存储系统的存储引擎,减少读写队列拥塞的可能性,进一步提升服务性能。LeanCloud官方地址:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

CopyRight © 2015-2020 新萄京娱乐3730-娱乐场官网app下载 All Rights Reserved.
网站地图xml地图