http://www.ox-holdings.com

一组负责实时通信服务数据统计的缓存机器发生故障,交易历史 &gt

摘要2016 年 2 月 26 日下午五点左右,即时通讯云 LeanCloud 的聊天服务出现故障,故障导致部分终端用户在获取指定聊天记录时,可能会得到整个应用的聊天记录。2016 年 2 月 26 日下午约五点,即时通讯云 LeanCloud 的聊天服务出现故障,故障导致部分终端用户在获取指定聊天记录时,可能会得到整个应用的聊天记录。据官方声称故障持续时间约为十多分钟。以下是LeanCloud官方关于此次故障的说明:故障时间16:45 至 16:58(持续约 13 分钟)影响范围使用了聊天服务,且在服务异常期间发生了聊天记录查询请求的所有应用故障处理16:45我们对生产 Web 服务器应用了新的配置以优化性能。16:56内部监测系统发现聊天服务流量异常并发出报警。经查确认新配置中的部分规则没有产生预期效果,在处理聊天记录 REST API 请求(/1.1/rtm/messages)时会忽略掉所有查询条件(query string)而返回应用下的所有聊天记录。16:58立刻恢复原有配置,问题得到解决。改进措施随后我们进一步调查得知,我们的预备系统与生产系统存在一些微小差异,新配置在预备系统上通过而在生产系统中部分失效。我们会重新对所有业务系统的预备和生产环境进行一致性检查,避免类似的情况再次发生。

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

摘要即时通讯云服务商LeanCloud 2016年8月5日因由于缓存集群超负载崩溃,导致即时通讯服务瘫痪30分钟之久!以下消息来自LeanCloud官方:8 月 5 日晚上 7 点 10 分开始,LeanCloud 中国节点上的某一缓存集群因为流量过大,CPU 资源被占满而停止了服务,从而导致数据存储及依赖它的服务(云引擎、推送、实时聊天)出现约半小时的中断,在此期间有部分应用可能会遇到请求无法完成的情况。详细报告如下。故障节点和影响范围只有中国节点出现了问题,受影响的服务与时间段列举如下,其他服务未受到影响。服务名区域受影响时段范围数据存储中国19:10 – 19:41全部不可用云引擎中国19:10 – 19:41全部不可用实时通信中国19:10 – 19:41部分不可用(消息 hook 功能不可用、离线推送延迟)消息推送中国19:10 – 20:02推送大面积延迟统计服务中国19:10 – 20:23全部不可用(数据收集接口关闭)故障时间线19:10:内部监控报警,确认 redis 异常(CPU 资源占满,失去响应)。19:13:redis 机器无法直接重启,开始尝试逐步关停其他服务(依次是推送、聊天推送、云引擎、统计),以降低请求压力。19:41:redis 集群恢复可用,同时数据存储、云引擎和实时通信三个服务开始恢复。20:02:消息推送服务开始恢复,redis 集群运行正常。20:23:成功为统计服务单独搭建 redis 集群,统计服务的数据收集接口开放,新老 redis 集群运行正常。至此所有服务全部恢复。后续措施将该 redis 集群从业务层面进行拆分,小集群化。将 redis 集群进行高可用架构升级,避免单点故障。对集群加强容灾演练,确保异常条件下服务稳定。对于本次故障,我们诚恳地向您道歉。我们将免掉您账户中全部应用在 8 月 5 日当天的所有费用,以表诚意。

摘要4月22日即时通讯云 LeanCloud 发生了因存储集群故障而致服务瘫痪,从事故原因中可以想够用的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战。前言4月22日即时通讯云 LeanCloud 发生了因存储集群故障而致服务瘫痪,从事故原因中可以想象的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战:当用户量持续增大,所面临的各种因大并发、高服务需求问题,时常导致整体服务品质的下降,这也侧面反映出,要做出可靠的云即时通讯服务,在没有现成方案可用的情况下,各厂商要走的路显然还很长。以下是官方事故通报情况2016 年 4 月 22 日 13:04 开始,LeanCloud 中国节点的后端存储集群出现问题,导致该节点上所有应用都出现了存储 API 访问故障,将近半小时后得到恢复。故障的详细经过通报如下。故障时间13:09-13:28 所有应用的数据存储服务都出现访问异常(持续 19 分钟)13:28-13:40 大部分应用已经恢复,但还有 20% 的应用依然无法正常访问(持续 12 分钟)影响范围中国节点上所有应用的存储服务都受到影响,同时依赖于数据存储的实时通信、云引擎服务也可能出现内部错误。美国节点不受影响,所有服务均工作正常。事故经过13:04 我们监控系统陆续发出报警,后端存储集群访问超时慢慢增多,工程师介入调查,并向用户发出了短信和邮件通知。13:10 整个集群的存储 API Server 不再响应外部请求。调查后确认是后端存储系统在做大量耗时的关系数据写入操作,导致系统失去响应。于是我们马上重启集群,并分批开放流量。13:28 部分存储分片(shard)得到恢复,80% 的应用访问恢复正常;发送第二次故障进度通知。13:40 所有应用恢复正常;发送故障解决通知。后续改进措施这一次故障的根本原因在于 AVRelation 模型的底层实现存在缺陷,某些特殊条件下会导致后端存储系统因忙于处理而失去响应。我们已完成替代方案的开发,正在测试中,下周会发布更合理的解决方案。(4 月 27 日周三完成)改进并发限制的算法,以便在异常条件下更好地限制故障的影响范围。(4 月 25 日周一完成)排查所有危险/耗时操作,在上层进行写入控制,避免对后端存储系统造成太大影响。(4 月 25 日周一完成)LeanCloud官网访问以下地址即可:leancloud.cn

摘要2016 月 2 月 19 下午 3 点左右,即时通讯云 LeanCloud 因技术故障致所有服务中断半小时以上。2016 月 2 月 19 下午 3 点左右,即时通讯云 LeanCloud 因技术故障致所有服务中断半小时以上。以下是LeanCloud官方关于此次故障的说明:故障时间15:17 至 15:50(持续约 33 分钟)影响范围除了单纯的静态网站托管服务未受影响之外,其他所有服务,包括结构化数据存储、文件存储、云引擎、聊天、短信、推送、统计等功能都暂时无法使用。故障处理时间线15:17:我们在部署新服务时无意触发了一项误操作,但并未意识到由此会导致上述服务停止。15:17:我们在同一时间接到系统监控报警,经检查发现 LeanCloud 网站无法登录,API 服务日志也已中断,同时有部分用户也向我们反馈,确认了服务已不可用。15:19:我们随即启动回滚操作,所有服务陆续开始重启。15:25:API 等服务逐步启动,但是流量还没对外开放。15:30:开放 API 流量, 数据存储服务以及依赖于它的云引擎服务开始逐步恢复。继而聊天、统计、推送服务也逐步恢复。15:50:所有服务恢复正常。后续改进措施贯彻执行故障通报流程:由于本次故障事发突然,影响面广,我们一直专注在恢复服务上,却疏忽了与用户及时沟通问题和进展这一已有流程。我们深知在故障期间这一流程对用户来说至关重要,所以我们今后会切实执行这一流程,明确故障通报的负责人和替补人、通报时机、通报内容、通报渠道(如邮件或短信)等。对部署服务进行权限和功能上的细分:限制其操作的影响范围,杜绝一条指令导致所有服务停止运转的情况。完善后台管理系统:确保管理系统的所有操作都增加了确认环节,确保操作者知道操作的后果,并手动进行确认。这次由于我们的工作失误而引发了大范围的服务中断,我们在此向大家深切地道歉。同时为了表达我们的歉意,我们会免掉所有应用在 2 月 19 日除短信服务之外产生的全部费用。我们将在后续几日进行退费操作,退费完成时,您将收到账户余额变动的邮件通知,请耐心等待。具体金额届时也可以通过控制台 > 交易历史 > 充值历史查询。

郑重声明:本文版权归新匍京a奥门-最全网站手机版app官方下载所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。