利用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 条消息似乎很少，但是它只是一...
