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网站上的。这些文档最棒的是,我注意到其中会有很多额外的关于内核的信息,透彻地理解这些很重要。
     
    无论你用什么数据库或是数据存储,你都需要深入地理解文档,以便你能够按照合理的方式来使用这些系统。人们经常遇到这样的情况:他们没有做好前期功课,就很快地或者错误地决定采用某种解决方案,结果把自己逼到了死角。
     
    尤其对于数据存储来说,采用正确的解决方案真的非常重要,因为数据存储应该是你的应用栈中最稳定可靠的部分。
     
  • 相关阅读:
    kettle初探
    ECLIPSE 不能连接MYSQL 8 的现象
    easyreport 安装手记
    eclipse 下安装 lombok.jar
    mysql 8 安装及更改密码
    转:Python的这几个技巧,简直屌爆了
    转:通用缩写表
    检查webpack版本
    vue-cli脚手架项目按需引入elementUI
    webstorm “Unterminated statement”
  • 原文地址:https://www.cnblogs.com/datastax/p/14126911.html
Copyright © 2011-2022 走看看