zoukankan      html  css  js  c++  java
  • 行业动态 | Instagram: 从Redis到Cassandra成功节省75%的成本

    从Redis转到Cassandra,Instagram在欺诈检测、消息推送以及消息中心等功能上节省了75%的成本。
     
    Instagram是如何部署Cassandra的?随着业务规模的扩大,Instagram又遇到了哪些挑战,并且如何解决这些问题呢?本文将通过对Instagram的两位工程师的采访,为你揭晓答案。
     
    本篇文章的部分素材写于2014年,其中的提到的某些硬件配置可能略微过时,但对现在的应用场景仍有借鉴意义,故而仍决定翻译并分享。

     
    “使用Cassandra让我们的成本削减至之前花销的大约四分之一。不仅如此,Cassandra解放了我们——因为我们只需将数据丢入集群即可,它有很强的伸缩性,并且我们可以随时按需添加节点。”
    ——Instagram软件架构工程师Rick Branson
     
    Instagram是一个自由分享照片的APP,用户可以用它拍照、添加滤镜,并将照片分享至像是Facebook和Twitter一类的社交网络。上亿的Instagram用户用这款APP拍摄并编辑他们的照片和视频,并将这些创作与全世界分享。
     
     
    01 通过使用Cassandra削减成本
     
    最初我们的Cassandra集群部署是为了存储与安全和网站完整性(site integrity)相关的审计信息的。具体一些来说,包括了反垃圾信息、识别不良用户以及其他类似的事情。这些恰恰是Cassandra的强项。
     
    原来这些功能都是由Redis来提供的。但是随着数据量迅速增长,将数据存在内存不再是一个有效率的方法。我们有非常高的写入比例,而读取比例则相当低——这也正符合了Cassandra的那些非常突出闪耀的点。所以最终把这部分数据转移到Cassandra,这对我们来说几乎是不假思索的事情。
     
    我们从一个拥有三个节点的集群开始,用于这个用例的集群后来逐步扩大到十二个节点。这就是我们获取主要的应用程序后台信息的途径。
     
    02 欺诈检测、消息推送以及消息中心
     
    对于上面提到的第一个后端用例,我们移除了Redis的主从复制设置,因为它实在是耗资巨大。我们不再把所有的东西用一个非常之大的实例存在内存里,而是把这些都放到了硬盘里。
     
    使用Cassandra让我们的成本削减至之前花销的大约四分之一。不仅如此,Cassandra解放了我们——因为我们只需将数据丢入集群即可,它有很强的伸缩性,并且我们可以随时按需添加节点。
     
    当你从一个不分片的设置转向一个分片的设置时,你会感到很痛苦。但是转向Cassandra意味着你基本无需额外操心,因为你不用经历拆分数据这个痛苦的过程。
     
    最近我们决定将另一个更为关键的用例移植到Cassandra上来。我们花了时间让团队中的每个人了解Cassandra、阅读文档、学习如何有效率地运行和维护Cassandra。
     
    我们选择将Cassandra用在我们的App中被称为“消息中心(inboxes)”或消息推送(newsfeed)的部分。基本上来说,它负责推送所有和指定用户相关的动态——你可以看到有没有人给你的照片点赞、有没有人关注你、你有没有朋友也在使用Instagram,或者收取评论等等。
     
    我们决定将这部分数据也从之前用的Redis转移到Cassandra的原因,同样是因为我们遇到了内存限制的问题。
     
    对于这个“收件箱”的用例,这些推送信息其实已经被拆分了。之前使用Redis时,我们的集群有32个节点,其中16个是主节点,16个是用于failover的从节点——另外当然,我们必须得认真检查所有的分片。
     
    我们注意到我们的空间已经不够用了,虽然CPU没有被消耗多少(Redis在CPU层面来说非常有效率)——但是显然,当你的内存告急的时候,你根本无能为力。
     
    最终,在这个用例上使用Cassandra集群是一个更具有成本效益且运维更容易的方案,因为你其实并不需要内存数据库级别的性能。持久性(durability)是另一个Redis不能提供有效支持的主要因素,在此就不多做展开了。
     
    03 Instagram的部署方案
     
    我们已经对Cassandra的可靠性和可用性有相当的体会了。Cassandra的工作负载与之前非常不同:我们在一些SSD盘上运行Cassandra,这使我们能够利用所有的非常好的亮点功能,包括虚拟节点(vnode)、分级压实(leveled compaction)等等。Cassandra是一个非常成功的项目,我们只花了几天就完成了整个系统迁移。
     
    这里有一些关于我们的集群的详细信息:这个由亚马逊AWS EC2的hi1.4xlarge实例组成的集群拥有12个节点,我们在其中一共存储了大约1.2TB的数据。峰值时,我们每秒向着这个集群大约写入2万条数据,并且每秒大约读取1万5千条数据。
     
    Cassandra能够胜任这样的工作,这让我们印象非常深刻。这让我们无需再寻寻觅觅,无需再尝试别的解决方案,这对我们来说真的是一个非常棒的经历。我们从我们第一次的部署实施中学到了很多,这些知识也被我们应用于最近的部署实施中。
     
    每一次用户使用Instagram,他们都在从一个拥有12个节点的Cassandra集群中获取数据——这让人感到非常兴奋。
     
    时光倒流回2010年,Instagram现在存在Apache Cassandra上的所有数据,在那时还被存在一个位于美国的数据中心。随着公司的扩张,他们后来添加了第二个数据中心,同最先的数据中心一起支持服务。随后没过多久,他们又添加了第三个数据中心。每一次他们添加一个新的数据中心,他们都得增加数据复制。
     
    回到今天,如今的Instagram有十亿的日活用户,来自全世界各地。在为这些用户提供服务的同时还要保持高性能,Instagram需要一个合适的数据存储策略。
     
    “为了能够支持增长的工作负载,我们对于硬件资源的扩充需求变得越来越明确。说到底,这意味着在更多的国家要有更多的数据中心。”
    ——Facebook工程师Andrew Whang
     
    非常确定的是,Instagram在美国以外的其他国家添加了更多数据中心,但是我们意识到我们的数据复制策略(replication strategy)在大规模扩张时成了短板。
     
    当我们向多个国家扩张时,我们遇到了以下两个挑战:
    • 太多副本:有3个数据中心的时候Instagram有3个副本;有5个数据中心的时候Instagram就有5个副本。这个问题会随着时间的推移越来越严重。
    • 性能下降:QUORUM要求收到两个相近的副本节点的确认信息。随着时间的推移,QUORUM就会要求收到三个副本节点的确认信息。而当它们来自不同的洲,这些副本节点离彼此的距离相当遥远。故而这个次优的配置有损性能。
     
    为了解决这些问题,Instagram决定不再到处复制数据,而是在数据生成的地区就近储存。这样,我们可以构建一个更快且更有效率的网络,并能为本地数据的存取提供更好的性能。毕竟,大多数用户在大多数时间都在同一个地理区域使用Instagram。
    将美国的数据存储在美国的数据中心,将欧洲的数据存储在欧洲的数据中心——这样,公司就能够实现最佳性能。
     
    Instagram还用了一个Facebook开发的叫做Akkio的工具来管理大规模的本地数据,从而提供更强的用户体验。
     
    04 深入挖掘Cassandra文档
     
    如果有人问我,我会建议深入理解Cassandra这个系统并且阅读所有的Cassandra文档,尤其是那些在DataStax网站上的。这些文档最棒的是,我注意到其中会有很多额外的关于内核的信息,透彻地理解这些很重要。
     
    无论你用什么数据库或是数据存储,你都需要深入地理解文档,以便你能够按照合理的方式来使用这些系统。人们经常遇到这样的情况:他们没有做好前期功课,就很快地或者错误地决定采用某种解决方案,结果把自己逼到了死角。
     
    尤其对于数据存储来说,采用正确的解决方案真的非常重要,因为数据存储应该是你的应用栈中最稳定可靠的部分。
     
  • 相关阅读:
    打造基于CentOS7的xfce最简工作环境
    Linux下C程序的编辑,编译和运行以及调试
    修正 XE6 TListView 上方 SearchBok 右边的清除钮显示
    TabControl 显示彩色的图示 (XE6 Firemonkey)
    TSwitch 中文简繁显示支持(XE6 Android)
    改变 TMemo 的背景颜色 (Firemonkey)
    修正 XE5 Android 键盘三个问题
    Delphi 收藏
    展示 Popup 的使用方法
    ListView 下拉更新 (支持 Android)
  • 原文地址:https://www.cnblogs.com/datastax/p/14126911.html
Copyright © 2011-2022 走看看