从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网站上的。这些文档最棒的是，我注意到其中会有很多额外的关于内核的信息，透彻地理解这些很重要。
无论你用什么数据库或是数据存储，你都需要深入地理解文档，以便你能够按照合理的方式来使用这些系统。人们经常遇到这样的情况：他们没有做好前期功课，就很快地或者错误地决定采用某种解决方案，结果把自己逼到了死角。
尤其对于数据存储来说，采用正确的解决方案真的非常重要，因为数据存储应该是你的应用栈中最稳定可靠的部分。