作者归档:Junwen Feng

2016 年 10 月 17 日:骨干网网络故障引发 LeanCloud 服务超时的说明

根据底层 IaaS 服务提供商报告,10 月 17 日 14:58 开始,中国南北骨干网线路外网电信线路出现网络异常,南北电信互访可能有 50% 以上的丢包现象,这导致终端用户访问 LeanCloud 服务时可能出现超时错误。

我们紧急联系并督促 IaaS 服务商于 15:12 切换出口线路到联通网络,此后丢包率下降到 3% 左右,但延迟会稍有上升(至 20ms)。电信运营商确认这一事故为深圳至北京部分链路省外光缆可能出现了中断,正在全力抢修中。我们会持续关注这一问题,并督促上游服务商尽快解决故障。

如果有任何疑问,请发邮件至 support@leancloud.rocks 来咨询。

2016 年 8 月 5 日:中国节点存储系统中断约半小时的故障说明

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全部不可用(数据收集接口关闭)

继续阅读

国内短信价格下调 17%,2016 年 7 月 5 日零时生效

sms-discount

自 2016 年 7 月 5 日周二零时起,通过 LeanCloud 发送国内文本短信的价格将从每条 0.06 元下调至 0.05 元,降幅达到 17%。

这是在我们与渠道服务商的共同努力下进一步优化了通道成本的结果,我们愿意让 LeanCloud 用户享受由此带来的价格优惠。

短信发送记录可以在 应用控制台 > 消息 > 短信 中查询,短信费用会在邮件账单中列出。如果有任何疑问,请联系 support@leancloud.cn

2016 年 6 月 30 日:实时通信服务故障报告

6 月 30 日晚上 8 点左右,我们的实时通信服务发生了故障,导致大量应用的终端用户无法登录和发送消息,时间持续约 40 分钟,详细情况汇总如下。

故障时间

19:58 - 20:41(共计 43 分钟)

影响范围

LeanCloud 国内节点的实时通信服务受到影响(无法登录和发送消息),其它服务正常;美国节点一切服务正常。

事故经过

  • 19:58 一组负责实时通信服务数据统计的缓存机器发生故障,导致用户登录或发送消息出现阻塞,类似操作开始消耗内部线程池资源;
  • 20:05 线程池资源耗尽,所有用户登录过程都会失败;
  • 20:22 确定了故障原因,开始重启缓存服务程序,但是服务程序所在机器因为压力过大失去响应,转而重启物理机器;
  • 20:33 缓存服务恢复正常,登录和发消息等请求开始恢复正常(为了加速我们新增了部分实时通信服务程序,以增加响应能力);
  • 20:41 实时通信服务恢复正常。
    下图中的黄线是故障时段前后的登录请求数量变化趋势曲线,与上述故障时间线吻合:
    scrot

后续改进措施

  • 聊天服务监控程序改由 Marathon 来自动部署并执行。该监控程序因前期的一次操作而被暂停,结果未能捕捉到此次服务异常,所以我们加入程序化的手段来保证其始终运行。(已完成)
  • 增加对统计数据缓存服务的监控。(已完成)
  • 增加对于登录请求数异常变化的监控。(已完成)
  • 进一步优化实时通信服务的架构,针对所有环节做好容错,防止类似的阻塞操作再次出现。(一周内解决)

最后我们诚恳地向受到本次故障影响的用户道歉。我们会让后续改进措施快速落实到位,努力为大家提供稳定而快速的云服务。如果您有任何疑问,请发送邮件至 support@leancloud.cn 进行确认。

2016 年 4 月 22 日:中国节点存储服务故障说明

2016 年 4 月 22 日 13:04 开始,LeanCloud 中国节点的后端存储集群出现问题,导致该节点上所有应用都出现了存储 API 访问故障,将近半小时后得到恢复。故障的详细经过通报如下。

故障时间

  • 13:09-13:28 所有应用的数据存储服务都出现访问异常(持续 19 分钟)
  • 13:28-13:40 大部分应用已经恢复,但还有 20% 的应用依然无法正常访问(持续 12 分钟)

影响范围

中国节点上所有应用的存储服务都受到影响,同时依赖于数据存储的实时通信、云引擎服务也可能出现内部错误。
美国节点不受影响,所有服务均工作正常。

继续阅读

2016 年 4 月 5 日:中国节点受到 DDoS 恶意攻击的故障说明

2016 年 4 月 5 日 20:19 开始,api.leancloud.cn 域名受到混合型 DDoS 攻击,致使用户无法从外网访问中国节点 API 服务,造成数据存储、统计、推送、短信等服务全部访问中断,历时约一小时。此次服务中断给大量应用造成了严重影响,在此,我们以最诚恳的态度向大家道歉,并附上具体的故障报告。

故障时间

20:19 ~ 21:25(持续约 66 分钟)

影响范围

  • 中国节点的数据存储、统计、推送、短信等服务不可访问,云引擎和实时通信(不包括调用 API 查询「对话」等操作)服务不受影响。
  • 美国节点的所有服务未受任何影响。

继续阅读

云引擎:网站托管需要进行实名认证,截至日期 4 月 30 日

为了响应相关国家法律法规的要求,我们需要对所有使用了 LeanCloud 云引擎的网站托管的用户进行实名认证。 从 2016 年 5 月 1 日起,没有完成实名认证的用户,将无法继续使用网站托管服务 。只有完成了实名认证后,该服务才能恢复。

为了不影响用户体验,请使用了网站托管的开发者尽快登录自己的应用控制台完成这一手续。具体的认证入口请到这里: 实名认证

继续阅读

2016 年 3 月 29 日:数据存储服务响应缓慢的故障说明

2016 年 3 月 29 日晚间,LeanCloud 平台上的多个应用进行了推广活动,激增的访问量给我们的数据存储和实时通信服务带来了较大压力。从 20:50 至 22:15 有多次流量高峰出现,我们多台 Web 服务器的网络吞吐包超过虚拟机的能力极限,内外网通信中断,从而导致 HTTP 服务多次出现间歇性故障(数据存储 API 以及依赖于它的服务也都间歇性不可用)。具体情况汇报如下:

故障时间

  • 20:53 - 21:03(持续约 10 分钟)数据存储 API 服务约 50% 的请求超时。
  • 21:17 - 21:40(持续约 23 分钟)数据存储 API 服务约 50% 的请求超时。
  • 22:00 - 22:15(持续约 15 分钟)数据存储 API 服务约 12.5% 的请求超时。

故障总共持续约 48 分钟。

影响范围

本次故障只影响中国节点,美国节点的所有服务均工作正常。在故障期间凡是向 LeanCloud 平台发送过请求,并使用了数据存储服务的活跃应用都受到了影响;我们的统计服务也在短时间内无法正常接收来自应用的事件上报。

继续阅读

2016 年 1 月 9 日:云引擎故障说明

昨日(周六)下午 4 时左右,有部分应用的云引擎服务出现间歇性错误「502 Application Not Responding」。我们收到报警后紧急上线调查原因,最终在下午 4 点 40 分左右修复了故障,让云引擎服务恢复正常。

本次故障从问题大面积爆发到恢复大约持续了 50 分钟,受影响的服务仅涉及云引擎,其他云端服务均运行正常。使用了云引擎服务且该时间段内云引擎有流量的应用会受到牵连。本次故障给部分用户带来了影响和损失,我们感到万分惭愧,并郑重向这些用户道歉。

故障修复之后,我们立即召集所有相关工程师进行了问题总结和技术讨论,评估可行措施来防止类似问题再次发生。以下是本次故障的详细报告。

继续阅读

高效内存存储服务 LeanCache 正式发布

LeanCache 是为云引擎用户提供的高性能、高可用的内存存储服务。与我们以往的数据存储服务相比,它不仅能够处理更多的并发连接和请求数,极大地提高应用性能,而且还能降低数据存储的使用成本。像秒杀、抢红包、数据量少但读写比例很高等场景都适合使用 LeanCache。

leancache_flowchart

在云引擎中访问一个容量为 2GB 的 LeanCache 实例,每秒可以处理将近 70,000 次的请求,而一般情况下访问存储服务的请求峰值为每秒 800 次,相差将近 90 倍。除了更高的性能,LeanCache 还可以帮助用户节省费用。因为交由 LeanCache 处理的请求不计入存储 API 调用次数,所以用户可以把一些高频率的查询从按 API 调用次数收费的存储服务分流至 LeanCache 上,通过降低总的 API 调用次数来减少费用。

LeanCache 基于 Redis 技术,同时支持缓存数据存储和持久化存储,可以在不中断服务的情况下在线扩容。同时,LeanCache 支持在多个应用之间共享数据,所以如果多个云引擎节点需要协同工作和通信,LeanCache 也是正确的选择。

继续阅读