2023年7月9日发(作者：)

解析如何利⽤ElasticSearch和Redis检索和存储⼗亿信息如果从企业应⽤的⽣存率来看，选择企业团队信息作为主要业务，HipChat的起点绝⾮主流；但是如果从赚钱的⾓度上看，企业市场的⾼收益确实值得任何公司追逐，这也正是像JIRA和Confluence这样的智能⼯具制造商Atlassian于2012年收购HipChat的原因。同时，或许你不知道的是，在Atlassian资源和⼈脉的帮助下，。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，这使得它可以编写类似这样的⼯具。例如使⽤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才是最薄弱的环节。