使用ElasticSearch踩过的坑 - 简书
使用ElasticSearch踩过的坑
版权申明：此文章首发于公众号程序员在深圳，搜索 studycode 即可关注本文无需授权即可转载，转载时请务必注明作者
使用ElasticSearch将近3个月了，在使用过程中，陆陆续续踩了不少坑，每次觉得无法逾越时，心里都想放弃，一是因为这东西要完全掌握不是那么容易，需要花很多时间；二是如果继续使用曾经用过的zabbix，说不定可以很快满足眼前的需求，从而可以抽身做其他事情。但坚持下来，就一定能从坑里爬起来，从而对这个系统更加了解，并利用这头”猛兽”帮助我做更多事情。原因很简单，ElasticSearch除了是一个分布式数据库，还是一个扩展性和可用性都很强的近实时搜索引擎。
目前为止，踩过以下几个坑：
集群搭建不成功
未使用内网IP，导致恢复缓慢
未使用队列及logstash，导致数据丢失
Master和DataNode未分离，导致集群不稳定
Logstash吞吐量问题
Logstash如何创建Mapping
head插件安装错误
犯了这么多错误基本上都是使用不当、以偏概全的原因，以为看了一点文档，就凭直觉可以猜测到系统的所有内容，造成了后续问题的不断涌现，下面就逐一说一下淌坑过程
集群搭建不成功
一开始是在单机上玩ElasticSearch的，上生产环境肯定要使用它的集群功能，但文档说只需要在elasticsearch.yml中设置cluster.name和node.name即可，ElasticSearch节点启动时会自动发现集群并加入到集群，但全部设置完毕后，竟无法使各个节点组成集群，最后发现这种方法只在一台机器上有效，而要组成集群，需要在每台节点做以下配置：
discovery.zen.ping.unicast.hosts: ["Node1_IP:9300", "Node2_IP:9300", "Node3_IP:9300"]
ElasticSearch一般会开两个端口，一个是集群维护端口，如上面的9300; 一个是对外提供的端口，默认是9200。
未使用内网IP，导致恢复缓慢
在部署集群时，我挑选了几台配置相近的同网段机器，但当时其中一台机器操作系统没有加载内网网卡，为了偷一下懒，便直接使用了外网IP，集群是跑起来了，运行了一段时间也没有什么问题，但随着流量越来也大，终于有一天Master突然down掉了，我当时心想，ElasticSearch集群本身具有故障转移功能，马上会分配一个Master节点，然后我只需要把原先的Master节点重启即可，然而重启了之后，通过页面查看恢复情况，发现集群长时间处于黄色状态（有replica shard丢失），而丢失的shard一直处于未分配状态，并没有如我预期的：启动后，该节点可以重用在磁盘上的shard数据，上报给Master，不需要数据拷贝，立马恢复为绿色状态。过了几分钟后，我发现恢复的shard数正以缓慢的速度增加，便推导出这样的错误结论：ElasticSearch在某一台机器挂掉后，只会从primary shard复制数据，即便节点迅速恢复，也不会复用该节点上的数据，如果是这种实现方式，我认为这种恢复速度是无法接受的，顿时产生了无法继续使用下去的念头，当时的心情是无比失落的。
而ElasticSearch的使用是相当广泛的，我们熟知的也是使用它来实现搜索功能的，所以可以断定是我的使用方法有问题，要么是我选的版本不稳定，要么是其他的原因，而稳定版一般出问题的几率不大，因此在换版本之前，需要找其他方面的原因，很久之前看过一篇google的slide，上面有一页介绍了不同介质数据的传输速度：外网的传输速度在10ms级别，而内网却在20微秒级，这种速度的差异便会造成以下几个方面的影响
集群无法提供正常服务：因为每个请求，ElasticSearch节点都会经过转发和收集两个过程，如果使用外网网卡，便会造成延迟大，访问量上不去，而流量到达一定程度后，集群很快便无法提供正常服务
由于ES集群已经无法正常服务，所以down机、恢复困难一系列综合症的情况便会陆续发生
后续我将集群切到了内网中，再测试重启某一个节点，便不会再出现恢复一个节点需要半天的情况了。
未使用队列或logstash，导致数据丢失
最初用到的架构非常简单: 使用ES（ElasticSearch缩写）集群作为存储，beats和rsyslog作为shipper向ES集群发送数据，使用这种架构的主要原因是配置简单，ES本身是一个高可用集群，直接把数据发过去就好。而自己心里还产生了为什么会有ELK架构，感觉Logstash是多余的想法，在发生了几次down机之后，才发现之前的想法很傻很天真，之前的架构也有明显的问题
在某一个节点down掉后，如果不马上恢复，在不了解beats负载均衡机制的前提之下，很难判断数据还会不会发送给down掉的节点，而新增一个节点，需要修改所有beat的配置，即这里至少要使用一个负载均衡器给所有ES节点做负载均衡
ES是一个高可用集群，但目前还没有足够的使用经验，所以可能今后还会出现集群故障的问题，而出故障，很可能造成数据的丢失，为了避免这种情况发生，需要在beats和ES集群之间构建一套可持久化的队列，最简单的队列是redis，而logstash放在redis两边分别作为生产者和消费者。想到的方案便是beats-&logstash-&redis-&logstash-&ES，这样便解决了丢数据的问题，当然最新版的logstash可以将数据持久化到磁盘上，也许可以对此模型进行简化
Logstash和Redis的使用都非常简单，这里就不一一介绍，值得注意的是，如果要使用redis做持久化，需要使用Redis的List的方式，而不是Sub-Pub的方式，以下是具体的架构图，箭头的方向是数据流动的方向。
Master和DataNode未分离，导致集群不稳定
在ES集群中，节点分为Master、DataNode、Client等几种角色，任何一个节点都可以同时具备以上所有角色，其中比较重要的角色为Master和DataNode:
Master主要管理集群信息、primary分片和replica分片信息、维护index信息。
DataNode用来存储数据，维护倒排索引，提供数据检索等。
可以看到元信息都在Master上面，如果Master挂掉了，该Master含有的所有Index都无法访问，文档中说，为了保证Master稳定，需要将Master和Node分离。而构建master集群可能会产生一种叫做脑裂的问题，为了防止脑裂，需要设置最小master的节点数为eligible_master_number/2 + 1
脑裂的概念：如果你有2个Master候选节点，并设置最小Master节点数为1，则当网络抖动或偶然断开时，2个Master都会认为另一个Master挂掉了，他们都被选举为主Master，则此时集群中存在两个主Master，即物理上1个集群变成了逻辑上的2个集群，而当其中一个Master再次挂掉时，即便它恢复后回到了原有的集群，在它作为主Master期间写入的数据都会丢失，因为它上面维护了Index信息。
根据以上理论，我对集群做了如下更改，额外选取3个独立的机器作为Master节点，修改elasticsearch.yml配置
node.master = true
node.data = false
discovery.zen.minimum_master_nodes = 2
修改其他节点配置，将其设置为DataNode，最后挨个重启
node.master = false
node.data = true
Logstash吞吐量问题
在使用了新的架构后，我发现了当流量上来后，Redis的队列会持续增长，消费速度跟不上生产速度，造成的问题是数据在Redis中堆积，图表展示有大量的延迟。解决这个问题有以下几个思路
可能是ES插入速度太慢，需要调整参数提升插入性能
可能是Logstash吞吐量低，需要增加每次向Redis拿数据的缓存、增加向ES输出的缓存、增加线程数、增加每次批量操作的content length等
对于ES调优中，我调整了线程数，增加线程队列，增大shard数，但都没有解决问题。
而Logstash调优，我首先调整了LS_HEAP_SIZE参数，让Logstash可以同时处理大量的数据，然后主要专注在调整Logstash的Input和Output插件参数上，插件中可以设置线程数、batch_count数值等，而当我将Redis插件参数改为batch_count=&10000后，发现队列不再一直增长了，它会涨到一定程度后，瞬间减少到2-3位数，即队列的长度在一定范围内浮动，当时欣喜若狂，以为自己解决了，但跑了大概5个小时候，发现队列又开始不断增长了，问题并没有得到解决。而产生解决了的假象应该是我增加了Logstash内存的原因，数据只是先把Logstash内存填满，再开始填队列，而填满Logstash内存花了几个小时，关键的Logstash到ES的吞吐量还是没有上去，在access日志中，无论如何也无法让bulk API的content length增加，如下图中的长度一直维持在2K左右。
最后，我采用了替换Logstash版本的策略，更新了时下最新的5.1.1版本，由于新版的配置和旧版配置不一样，所以认真研究了一下配置，在这个过程中，我发现了一个-b参数可以修改批量插入的大小，也许就是我需要的。果然，将这个参数由默认的125改为了1000，顺利的解决了这个难题，同时也证明了并不是版本问题，还是使用问题，而这个参数也正是修改content length的方法，顺便说一下，如果你使用nginx作为负载均衡器，你需要同时增加client_max_body_size参数，避免产生content length过大而返回413错误码。
Logstash如何创建Mapping
当使用Logstash进行转发时，有可能你的数据都在一个Index中，当然你也可以设置不同的Index，中就有根据type来划分Index的方法，不管划不划分Index，都会默认生成一个或多个mapping结构，mapping结和不同的type即对应MySQL中的数据库和表结构信息，当然我这里不是为了说明它们的区别，而是我们无法自定义字段的类型。
这会产生各种各样的问题，比如它会默认产生analyzed类型的string字段，会自动将带有连接符的字符串分为两个字符串输出，即"idc-1"这样的字符串会输出为"idc"和"1"，这并不是我想要的，让我相当困扰，而Mapping在生成后是无法修改字段的，除非你换一个新的字段。
解决这个问题的方法并不在mapping上，而我却花了很多时间在这个上面，最终答案却是使用template，在template中可以定义你需要的mapping，这样便解决以上问题。到此，我还是不能完全理解里面的机制，以后抽空了解后再补上。
head插件安装失败
上文有介绍插件，它是一个可以显示集群状态及操作ES集群的UI，可以取代官方的X-Pack，后者只有30天的试用期，因为创业公司，能用免费的尽量采用免费的。在集群中，有几个节点安装该插件会失败，提示：Unable to veryfy checksum for download plugin ...，google上查了一圈仍然没有找到解决办法，最后试着手动将该插件下载然后解压到/usr/share/elasticsearch/plugins/目录下，并将目录改为head即可解决该问题。
以上问题是我这段时间来碰到的坑，每个都花了不少时间去解决，自己也比较幸运，花在上面的时间没有白费。因为个人觉得这个技术栈实在是比较好，而资料主要以英文的为主，把自己的经历写下来，希望今后不再犯同样的错误，也希望可以帮助其他使用该技术的同学。
本文参与了掘金技术征文活动：
欢迎您扫一扫上面的微信公众号，订阅我的博客！
欢迎关注我的公众号：studycode
10年程序员，终身学习者
曾在迅雷担任技术经理
曾开过一家热干面馆(很正宗)
爱折腾，热爱开源
目前在一家创业公司担任技术总监
github地址: /jieniu利用ElasticSearch和Redis检索和存储十亿信息
发表于 17:28|
来源High Scalability|
作者Tod Hoff
摘要：每隔几个月，发送、存储和索引的信息就会翻一番，在过去几个月HipChat进入了一个指数增长周期。如此多流量的暴增对哪个初创来说都不轻松，这里我们看HipChat的解决之道。
本文来自Zuhaib Siddique的一次专访，Zuhaib是群聊IM制造商HipChat的生产工程师，下面我们一起看Tod Hoff的整理。
以下为译文：
如果从企业应用的生存率来看，选择企业团队信息作为主要业务，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个前端代理服务器，是后端应用服务器的一倍
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才是最薄弱的环节。
原文链接：How HipChat Stores And Indexes Billions Of Messages Using ElasticSearch
And Redis（翻译/任云 责编/仲浩）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章