利用ElasticSearch与Redis检索与存储十亿信息.docVIP

利用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启动时，内存泄露会导致宕机，因此将其移动到本地应用上