于是很快便定位到某一集群由于突发硬件故障而引起存储服务中断,5年前的感慨今天谷歌开源了WebRTC技术

by admin on 2020年3月16日

摘要融云即时通讯云SDK新版发布,本次发布的版本为: Android 2.6.11
Stable、iOS 2.6.11 Stable。发布的版本Android 2.6.11 Stable、iOS 2.6.11
Stable,更新时间为:2016年8月15日。iOS 2.6.11
Stable更新内容1、这个版本我们完整的适配了 iOS
10。苹果的各项策略总是在不断变更,我们会根据其变化第一时间对 SDK
进行升级。对于近期要发布 App
的客户,我们建议您升级到这个版本。2、实时地理位置共享功能,从收费使用变为免费,默认功能打开,请您参考我们的源码来实现。未在源代码里实现该功能的用户不受此次升级影响。Android
2.6.11
Stable更新内容1、实时地理位置共享功能,从收费使用变为免费,默认功能打开,请您参考我们的源码来实现。未在源代码里实现该功能的用户不受此次升级影响。下载地址请从以下官网地址下载:

摘要2016年6月9日是开源实时音视频工程WebRTC开源5周年的日子,Google
WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。前言2016年6月9日是WebRTC开源5周年的日子,Google
WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。为了便于大家更好理解过去5年在WebRTC上都发生了什么,我将这两篇给翻译过来了。友情提醒:整个翻译并不是逐字逐句进行的,而是在理解了作者的意思后用自己的语言表达出来的,因为如果逐字逐句可能很多意思我们都无法正确理解。这就是为什么有些英文资料被翻译成中文后晦涩难懂。当然如果英语够好建议直接看原文。5年前的感慨今天谷歌开源了WebRTC技术,一个用于实时语音和视频通话的软件包,她即将被整合到Chrome。这是我们的第一波贡献,一切都是为了一个伟大的使命——在统一的标准的API下实现所有浏览器间的音视频通话。这个初始版本将提供我们设想的一些功能,具体详见:
Harald)今天的总结今天,回首往事,我们可以很自豪地说:“我们实现了我们所有的目标。”现在音视频交互变得越来越重要,许多产品和服务都支持Web和Native之间的无缝交换,而他们之中绝大部分都是基于我们现在开放出的标准API——这些API的底层实现基本上都是基于WebRTC
。一套通用标准促进了整个行业的发展,Firefox、Opera和微软都已经在支持WebRTC技术了。这已经导致超过20多亿浏览器用户使用了WebRTC技术,仅仅Chrome上每周就有超过10亿分钟的音视频通话,以及超过500T的数据传输(通过WebRTC的数据通道)。WebRTC从一开始就秉持一种很开放的态度,向视频编解码免版税方向迈进。在WebRTC中80%音频通信采用Opus,而最近推出的VP9比VP8节省70%的带宽。由于VP9的努力发展,媒体开放联盟在视频编解码免版税道路上又多了一种选择,以及增加了更多的合作空间。今天,WebRTC技术在音视频领域已经证明了自己的强大,在接下来的几年里,我们期望看到一个更加强大的WebRTC。接下来我们会持续改进音视频质量。我们在WebRTC中愿意采用一些通用的编解码来实现交互通讯,但有一些互操作的问题要去解决。另外作为未来编解码的VP9,他后面在压缩率方面会持续改进,以便更好支持低带宽下的通讯。今天的通信都发生在许多不同网络条件下,从EDGE到LTE。WebRTC面临多样化的网络条件,所以必须能够做出相应的调整。所以我们一直在努力改善拥塞控制算法和优化媒体传输配置来适应各种状况,这里面也有很多机会和方法来改善和简化媒体协议以适应当今网络需求。五年前,大多数通信发生在桌面上。但现在一切都变了,WebRTC技术已经发展到要满足各种移动通信应用的需求。展望未来,还有很多机会,如VR。WebRTC这个平台只会随着时间推移而价值愈加明显,现在仅仅是开始。我们要做的就是:努力做好WebRTC这个平台。(作者:Google
Harald)(原文链接:

摘要即时通讯云服务商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官方地址:

相关文章

发表评论

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

网站地图xml地图