解析如何利用ElasticSearch和Redis检索和存储十亿信息

若是从企业应用的生存率来看，选择企业团队信息做为主要业务，HipChat的起点绝非主流；可是若是从赚钱的角度上看，企业市场的高收益确实值得任何公司追逐，这也正是像JIRA和Confluence这样的智能工具制造商Atlassian于2012年收购HipChat的缘由。

同时，或许你不知道的是，在Atlassian资源和人脉的帮助下，HipChat已经进入了一个指数增加周期。12亿的信息存储意味着他们如今每隔几个月的信息发送、存储和索引量都会翻一番。

如此快速的增加给曾经充足的基础设施带来了很大的压力，HipChat给咱们展现了一个通用的扩展思路。从简单开始，经历流量高峰，而后思考如今怎么办？使用更大的计算机一般是第一个和最好的答案，他们也是这样作的。这给了他们一些喘息空间去考虑下一步怎么作。在AWS上，在某一个拐点以后，你开始走向云特性，也就是横向扩展，这就是HipChat所作的事情。

然而HipChat的发展也并未是顺风顺水，安全性的担心推进了HipChat的云（SaaS）版本以外内部部署版本的发展。

即便HipChat没有谷歌那么大规模，咱们仍能从中学到好东西，好比他们如何及时索引和搜索十亿信息，这也是IRC之类和HipChat之间的关键区别。在负载下索引和存储信息，丢失信息是一个艰巨的挑战。

这是HipChat选择的路，咱们一块儿展开……

统计

• 每秒60条消息
• 12亿文档存储
• 4TB的EBS RAID
• 在AWS上8个ElasticSearch服务器
• 26个前端代理服务器，是后端应用服务器的一倍
• 18我的
• 0.5TB的搜索数据

平台

• 主机：AWS EC2 East上的75个实例所有使用Ubuntu 12.04 LTS 
• 数据库：目前用于聊天记录的CouchDB，过渡到ElasticSearch。MySQL-RDS用于其它的一切
• 缓存：Redis
• 搜索：ElasticSearch
• 队列/Worker 服务器：Gearman（队列），Curler（Worker）
• 语言：Twisted Python（XMPP Server）和PHP（Web前端）
• 系统配置：开源Chef+Fabric
• 代码部署：Capistrano
• 监控：Sensu和monit将警告抽送至Pagerduty
• 图：statsd + Graphite

产品

• 流量突发。在周末和假期将是安静的。在高峰负荷期间每秒有几百个请求。实际上占用大部分流量的并非聊天信息，而是状态信息（away、idle、available），人们链接/断开等。所以每秒60条消息彷佛不多，可是它只是一个平均水平。
• 通知中心HipChat，在这里与团队合做，并获得来自工具和其余系统的全部信息。有助于使每一个人都在消息圈内，特别是远程办公。
• 使用HipChat而不是IRC之类，很大的缘由是HipChat存储和索引每一次对话，以便你之后搜索它们。强调搜索，这个特性的好处是你能够在任什么时候候作回溯，了解发生了什么和赞成了什么。若是在发送一条信息时，你的设备没法访问，它也会将消息路由到同一个用户的多台设备中，并作临时消息缓存/重试。
• 更多的用户带来更快的增加，他们在各个方面使用产品而带来的更多预约，也能够从他们的API集成中看到增加。
• 存储和搜索信息是系统中主要的可扩展性瓶颈。
• HipChat使用XMPP协议，所以任何XMPP客户端均可以链接到系统中，这点很是有利于采用。他们已经创建了本身的本地客户端（Window、Linux、Mac、iOS、Android），并带有相似PDF浏览、自定义表情符号、自动用户注册等扩展。
• 在之前，将Wiki这样的工具引入到企业文化是几乎不可能的。如今，企业级的工具多已在企业落脚，这是为何？

• 基于文本通讯已被普遍接受。咱们有短信、IM和Skype的形式，因此如今使用聊天工具是天然的事情。
• 异地工做模式的崛起。团队愈来愈分散，咱们不能只是坐在一块儿进行一个讲座，一切文档化的须要意味着组织通讯将有一笔巨大的财富。
• 加强的功能。把像内嵌图片、GIF动画等功能作得生动有趣，会吸引更普遍的群体。

• HipChat有一个API，这使得它能够编写相似IRC bots这样的工具。例如使用Bitbucket提交——在10:08开发者X提交一些代码来修复一个漏洞。代码发送经过HipChat直接链接到代码提交和提交日志，彻底的自动化。Bitbucket提交会击中一个web hook，并使用一个addons来张贴信息。Addons帮助编写bots，转入你的Bitbucket帐户。好比我有个人API令牌，我想在每次提交发生时张贴到这个API上，工做原理相似GitHub。
• 在客户端Adobe Air启动时，内存泄露会致使宕机，所以将其移动到本地应用上。这是个麻烦，也是机遇。同一个公司中都存在许多跨平台跨部门的用户，你须要站在用户的角度思考。但愿用户在全部的系统中都有很好的体验，用户不只仅是技术人员。

XMPP服务器架构

• HipChat是基于XMPP协议的，XMPP节里的内容就是消息，多是一行文本或者日志输出的长段等等。他们不想谈论本身的XMPP架构，因此没有不少的细节。
• 他们没有使用第三方的XMPP服务器，而是利用Twisted Python和XMPP库创建了本身的服务器。这使得能够建立一个可扩展的后端、用户管理，并轻松的添加功能而不用在其它代码库上修改。
• AWS上的RDS用于用户身份验证和其它使用事务及SQL的地方。这是一个稳定、成熟的技术。对于内部部署的产品，则使用MariaDB。
• Redis用于缓存。信息，如哪些用户在哪些房间，状态信息，谁在线等都是信息。因此，你链接的是哪一个XMPP服务器并不重要，XMPP服务器自己并非一个限制。

• 痛点是Redis（还）没有集群，所以使用了高可用性的hot/cold模式，因此，一个从属节点已经准备就绪。故障转移从主节点到从属节点大概须要7分钟，从属节点的发布是手动的，不是自动的。

• 提升负载能够发现代理服务器中的弱点所在，也能够清楚能支撑多少个客户端。

• 这是一个真正的问题，正如不丢失信息是一个很大的优点。显而易见，不丢失信息比低延迟更重要——用户更愿意晚点接收信息，而不是根本没有信息。
• 使用6个XMPP服务器系统运做良好，然而随着链接点的增长，他们开始看到不可接受的延迟。链接不只来自客户端，还来自bots支持他们的程序设计界面。
• 在第一遍的时候，他们分离出前端服务器和应用服务器。代理服务器处理链接，后端应用程序处理的stanza。前端服务器数量由有效收听客户数量驱动，而不是由信息发送数量驱动。保持那么多的链接打开，同时提供及时的服务是一个挑战。
• 修复数据存储问题以后的计划是调查如何优化链接管理。Twisted的效果很好，可是他们有不少的链接，因此必须弄清楚如何更好地处理这些链接。

存储架构

• 向HipChat发送的消息已达10亿条，同时还在不停增加，他们将CouchDB和Lucene对存储和搜索信息的解决方案推向极限。

• 认为Redis将会是故障点，而Couch/Lucene会足够好。没有作合适的容量计划和查看信息增加率。增加速度比他们想象的更快，不该该集中那么多精力在Redis上，而应该专一于数据存储。
• 当时他们相信经过增长容量来扩展，向上移动到愈来愈大的亚马逊实例。他们发现一点，随着不断地增加，他们利用这种方法只能再工做两个月。因此，他们不得不采用其余的办法。
• Couch/Lucene超过一年没有更新，它不能作分类。这是采用其余办法的另外一个缘由。

• 在亚马逊上大约10亿消息的一半是一个临界点。用一个专用的服务器和200G的RAM，他们以前的架构可能仍能工做，但在有限资源的云上就不能工做了。
• 他们想留在亚马逊。

• 喜欢AWS的灵活性，性能的添加只须要经过租用实例完成。
• 亚马逊的片状。不要把你全部的鸡蛋都放到一个篮子里，若是一个节点出现故障，你必需要处理它，不然一些用户将会失去流量。
• 使用动态模型。能够快速关闭一个实例，并带来新的实例。云原生类型的东西。能够随时关闭节点。关闭一个Redis主节点，能够在5分钟内恢复。目前美国东岸分割4个可用地区，可是尚未多区域。
• EBS只让你拥有1TB的数据。在遇到以前，他们并不知道这个限制。使用Couch时他们遇到了EBS磁盘大小限制。HipChat的数据是0.5TB。为了压缩，Couch必须将数据复制到有双倍容量的压缩文件中。2TB的RAID在周末压缩过程当中遇到了限制，不想使用RAID解决方案。

• 不选择亚马逊的DynamoDB，由于他们建立了一个HipChat服务器，在防火墙后面的托管服务。

• HipChat服务器驱动技术堆栈的决定。私人版是创建在本身主机上的解决方案。某些客户不能使用云/SaaS解决方案，好比银行和金融机构，国家安全局已经吓坏了国际客户，所以聘请了两名工程师建立产品的安装版本。
• Redis集群能够自托管，也能够像ElasticSearch那样工做在AWS上。在内部部署版本中他们使用MariaDB，而不是RDS。
• 不能考虑一个完整的SaaS解决方案，由于那会是一个锁定。

• 如今过渡到ElasticSearch

• 移动到ElasticSearch做为他们的存储和搜索后端，由于它能够储存他们的全部数据，它是高度可用的，它能够经过简单增长更多的节进行扩展，它是多用户的，它能够经过分区和复制透明的处理节点损失，而且它创建在Lucene之上。
• 并不真的须要一个MapReduce功能。看着BigCouch和Riak的搜索（表现通常），但ES在GET上的表现是至关不错的。喜欢坏了就扔，省去了故障检测。 ES HA已令他们在系统的坚固性上感到很是有信心。
• Lucene的兼容是一个巨大的胜利，由于全部的查询都已经兼容Lucene，所以它是一个天然的迁移路径。
• 客户数据是至关多样的，从聊天记录到图像响应类型的差异也随处可见，他们须要可以快速地直接从12亿文档中查询数据。
• 此举正变得愈来愈广泛，HipChat也使用ElasticSearch做为他们的key-value存储，减小须要数据库系统的数量，从而下降总体的复杂性。既然性能和响应时间都不错，那彻底没有不用的理由。 10ms到100ms的响应时间。在没有任何缓存的状况下，某些领域仍然超过Couch。那为何还要用多个工具？
• 使用ES，一个节点故障不会引发任何人的注意。在它再平衡时你会获得CPU使用率太高的警报，可是系统仍然运行。
• 用8个ES去处理流量的增加。
• 基于Java的产品JVM调整可能很是棘手。

• 要使用ES，必须有堆空间容量计划。
• 测试缓存。ES能够缓存过滤结果，这是很是快速的，可是你须要很大的堆空间。虽然8个主机拥有22G的内存，但还会随着缓存的打开被耗尽。因此若是不须要就关闭缓存。
• 缓存有问题，由于它会遇到内存不足的错误而后失败。集群会在几分钟内恢复，只有少数用户会注意到这个问题。

• 由于网络的不可靠，Amazon的故障转移也可能存在问题。在集群中可能会引发错误的选举发生。

• 使用ElasticSearch会遇到这些问题。本来有6个ES节点做为主节点选举运行，一个节点可能会耗尽内存或者遇到一个GC暂停并在网络中丢失。那么其余人就不会看到这个主节点，进行选举，并宣布本身是主节点。他们选举架构中的缺陷是他们不须要法定人数。所以就会出现Split Brain问题，从而引发不少问题。
• 解决方案是在专用的节点上运行ElasticSearch主节点，那么须要作的事情就是成为主节点，从而避免了后续问题。主节点处理分片的分配是完成，谁是主要的，而且完成复制分片分布图。实现再平衡要容易的多，由于主节点能够性能优良的处理全部的再平衡。能够查询任何节点，并会作内部路由。

• 使用月索引，每月是一个单独的索引。每一个初级索引有8个分片，而后有两个副本。若是一个节点丢失，系统仍能工做。
• 不要把RDS移动到ES中。须要使用SQL的数据通常储存在RDS/MariaDB中，典型的是用户管理数据。
• 在Redis集群被释放以前，Redis中大量的缓存是主/从设置。有一个Redis统计服务器，处于离线状态。Redis历史缓存的最后75条消息，用于防止在第一次加载对话时不间断的访问数据库。也有内部状态或快速数据的状态，好比登入用户数量。

常规

• Gearman用于异步工做，好比iOS的推送和传递电子邮件。
• AWS West用于灾难恢复，一切都会备份到AWS West。
• Chef用于全部配置。ElasticSearch有一个很好的Chef手册，轻松上手。像Chef，由于你能够开始写Ruby代码而不是使用Puppet风格的DSL，它也有一个很好的活跃的社群。
• 收购经验。他们如今已经进入公司的核心资产和人才，但Atlassian不干扰工做，之因此相信，是有缘由的。能够在内部要求，例如，如何扩大ElasticSearch ，当别人在Atlassian须要帮助时，他们能够加入帮忙的队伍。良好的总体体验。
• 扁平的团队结构。仍然是一个小团队，目前大约有18人。两我的在DEVOPS，少数平台，IOS、Android的开发人员在服务器端，一个Web开发工程师（在法国）。
• Capistrano用于部署全部的主机。
• Sensu用于监控应用程序。让你无需监视堆空间ElasticSearch节点，而后在没有任何通知的状况下解决OOM问题。目前堆的使用率为75％，这正是他们想要的状态。
• Bamboo用于持续集成。
• 客户端版本还不正规，开发者驱动，有一个临时区域进行测试。
• 集团标志。能够控制哪些群体获得了一个功能、测试特性能及缓慢释放特性，除此以外还能帮助控制主机的负载。
• 功能标志。有利于ElasticSearch部署过程当中的保护。例如，若是他们发现一个漏洞，他们能够关闭一个功能，并回去找Couch。用户不会注意到差异。在Couch和ElasticSearch之间的过渡阶段，他们都有应用复制到两个存储。
• 新的API版本将使用Oauth，所以，开发人员可使用HipChat API在本身的服务器上部署。有客户使用本身的服务器是一个更具扩展性的模式。

将来

• 将来几个月将会达到20亿条消息，估计ElasticSearch能够处理大约20亿条消息。不肯定如何处理负载的预期增加。预计要到Amazon West以得到数据心更多的的可用性和可能在不一样的数据中心投入更多的用户。
• AWS自动扩展能力
• 移动到语音，私人一对一视频、音频聊天、基本的会议
• 未来可能使用RabbitMQ来传递消息
• 与Confluence更大的集成。使用HipChat聊天，而后使用Confluence页面来捕捉细节。

经验教训

1. 企业应用程序是摇钱树。卖入一个企业是很痛苦的，销售周期长意味着太多的不肯定性。可是若是你成功卖出，那就会得到丰厚的利润，因此你应该考虑企业市场。时代在变，企业却多是滞后的，可是他们仍然采用新工具和新的作事方式，这其中就有机会。

2. 隐私在产品给企业推销时变得愈来愈重要，它会直接影响到产品的选择与否。HipChat正在作他们产品的备用版本，以使那些不相信公共网络的客户满意。对于一个程序员来讲，云做为一个平台很是有意义。对于一个企业来讲，云能够是魔鬼。这意味着你必须作出灵活的技术堆栈选择。若是你在服务上100%依靠AWS，那你的系统移动到另外一个数据中心将变得几乎不可能。这对Netfix也许并不重要，可是若是你想卖入企业市场，它就很重要了。

3. 纵向扩展以得到喘息的空间。当你等待弄清楚架构中下一步要作什么的时候，能够花不多的钱去纵向扩展，给本身几个月的喘息之机。

4. 选择不会失败的。HipChat作出了不会丢失用户聊天记录优先级，因此他们的架构将这个优先级反映给保存聊天记录到磁盘，在宕掉后系统恢复时会从新加载。

5. 进入本地。你的客户在许多不一样的平台上，一个本地的应用将会提供最好的体验。对于一个初创公司，那是不少的资源，太多了。因此，卖给拥有更多资源的公司在某种程度上是说得通的，这样你能够创建更好的产品。

6. 功能和群组标志作出更好地发布惯例。若是你能够选择哪些组看到一个功能，若是你能在生产和测试中关闭功能，那么你就不用担忧发布新的构建项目了。

7. 选择你真正自信的技术。ElasticSearch应对增加的横向扩展能力让HipChat很放心，一样也会有一个很好的用户体验，这才是最重要的。

8. 成为该流程的一部分，你变得更有价值，难以消除。HipChat做为人和工具之间的自然契合点，也是来编写实现各类有用工做流bots的自然点。这使得HipChat在企业中有发挥的平台，它使原本不可建造的功能得以实现。若是你能作到一样的事情，那么你们都会很须要你。

9. AWS须要在总线上存在一个单独的节点，这个要求看起来有点荒谬，可是在云环境下却很是重要，由于机器可用信息在第三方目的源中并不可见。若是着眼机架就会发现它常常有一个单独存在的总线插槽，若是其余插槽可用，他就会知道。这样，你就没必要去猜想。在云中，软件采用基于原始TCP的链接技术和心跳，去猜想另外一个节点是否发生故障，从而致使Split Brain问题及启用备库时产生数据丢失。这须要时间去演变，到达彻底可靠还须要迈一大步。

10. 产品决策驱动堆栈的决定，HipChat服务器驱动技术堆栈的决定：Redis集群能够自托管；不选择亚马逊的DynamoDB，是由于HipChat在防火墙的后面建立一个托管服务。

11. 你须要打开视野。你须要容量规划，即便是在云中。除非你的架构从一开始就彻底是原生云，不然任何架构都会有负荷的拐点，在拐点他们的架构将再也不可以处理负载。看看增加速度，项目出来了。会打破什么？你将会作什么？并且不要再犯一样的错误。HipChat将如何处理40亿条消息？当下还没法知晓。

12. 了解系统的限制。EBS有1TB的存储限制，这是很大的限制，但若是你的存储已接近那个限制，就须要有一个计划了。一样，若是你的数据库，例如Couch，在压缩阶段要使用双倍的磁盘空间，那将会影响你的系统限制。

13. 这个世界会令你大吃一惊。六个月前HipChat认为Redis将会是最弱的环节，但如今它依旧很强壮，而Couch和EBS才是最薄弱的环节。