点击上方 Java后端，选择 设为星标
优质文章，及时送达
国内现在有大量的公司都在使用 Elasticsearch，包括携程、滴滴、今日头条、饿了么、360安全、小米、vivo等诸多知名公司。
除了搜索之外，结合Kibana、Logstash、Beats，Elastic Stack还被广泛运用在大数据近实时分析领域，包括日志分析、指标监控、信息安全等多个领域。它可以帮助你探索海量结构化、非结构化数据，按需创建可视化报表，对监控数据设置报警阈值，甚至通过使用机器学习技术，自动识别异常状况。
一、京东到家订单中心 Elasticsearch 演进历程
京东到家订单中心系统业务中，无论是外部商家的订单生产，或是内部上下游系统的依赖，订单查询的调用量都非常大，造成了订单数据读多写少的情况。京东到家的订单数据存储在MySQL中，但显然只通过DB来支撑大量的查询是不可取的，同时对于一些复杂的查询，Mysql支持得不够友好，所以订单中心系统使用了Elasticsearch来承载订单查询的主要压力。
Elasticsearch 做为一款功能强大的分布式搜索引擎，支持近实时的存储、搜索数据，在京东到家订单系统中发挥着巨大作用，目前订单中心ES集群存储数据量达到10亿个文档，日均查询量达到5亿。随着京东到家近几年业务的快速发展，订单中心ES架设方案也不断演进，发展至今ES集群架设是一套实时互备方案，很好的保障了ES集群读写的稳定性。
如上图，订单中心ES集群架设示意图。整个架设方式通过VIP来负载均衡外部请求，第一层gateway节点实质为ES中client node，相当于一个智能负载均衡器，充当着分发请求的角色。第二层为data node，负责存储数据以及执行数据的相关操作。整个集群有一套主分片，二套副分片（一主二副），从网关节点转发过来的请求，会在打到数据节点之前通过轮询的方式进行均衡。集群增加一套副本并扩容机器的方式，增加了集群吞吐量，从而提升了整个集群查询性能。
当然分片数量和分片副本数量并不是越多越好，在此阶段中，对选择适当的分片数量做了近一步探索。分片数可以理解为Mysql中的分库分表，而当前订单中心ES查询主要分为两类：单ID查询以及分页查询。分片数越大，集群横向扩容规模也更大，根据分片路由的单ID查询吞吐量也能大大提升，但对于聚合的分页查询性能则将降低。分片数越小，集群横向扩容规模更小，单ID的查询性能也将下降，但对于分页查询，性能将会得到提升。所以如何均衡分片数量和现有查询业务，我们做了很多次调整压测，最终选择了集群性能较好的分片数。
由于大部分ES查询的流量都来源于近几天的订单，且订单中心数据库数据已有一套归档机制，将指定天数之前已经关闭的订单转移到历史订单库。
架构的快速迭代源于业务的快速发展，正是由于近几年到家业务的高速发展，订单中心的架构也不断优化升级。而架构方案没有最好的，只有最合适的。相信再过几年，订单中心的架构又将是另一个面貌，但吞吐量更大，性能更好，稳定性更强，将是订单中心系统永远的追求。
二、携程Elasticsearch应用案例
1. 携程酒店订单Elasticsearch实战
选择对分片后的数据库建立实时索引，把查询收口到一个独立的 Web Service，在保证性能的前提下，提升业务应用查询时的便捷性。
最终我们选择了 Elasticsearch，看中的是它的轻量级、易用和对分布式更好的支持，整个安装包也只有几十兆。
http://developer.51cto.com/art/201807/579354.htm
2. 携程机票ElasticSearch集群运维驯服记
这个是比较通用的数据的流程，一般会通过Kafka分离产生数据的应用程序和后面的平台，通过ETL落到不同的地方，按照优先级和冷热程度采取不同的存储方式。一般来说，冷数据存放到HDFS，如果温数据、或者热数据会采用Database以及Cache。
一旦数据落地，我们会做两方面的应用，第一个方面的应用是传统BI，比如会产生各种各样的报表，报表的受众是更高的决策层和管理层，他们看了之后，会有相应的业务调整和更高层面的规划或转变。这个使用路径比较传统的，在数据仓库时代就已经存在了。现在有一种新兴的场景就是利用大数据进行快速决策，数据不是喂给人的，数据分析结果由程序来消费，其实是再次的反馈到数据源头即应用程序中，让他们基于快速分析后的结果，调整已有策略，这样就形成了一个数据使用的循环。
这样我们从它的输入到输出会形成一种闭环，而且这个闭环全部是机器参与的，这也是为什么去研究这种大规模的，或者快速决策的原因所在。如果数据最终还会给人本身来看的话，就没有必要更新那么快，因为一秒钟刷新一次或者10秒钟刷新一次对人是没有意义的，因为我们脑子不可能一直转那么快，基于数据一直的做调整也是不现实的，但是对机器来讲，就完全没有问题。
http://www.sohu.com/a/199672012_411876
3. 携程：大规模 Elasticsearch 集群管理心得
目前，我们最大的日志单集群有120个data node，运行于70台物理服务器上。数据规模如下:
-
单日索引数据条数600亿，新增索引文件25TB (含一个复制片则为50TB)
-
业务高峰期峰值索引速率维持在百万条/秒
-
历史数据保留时长根据业务需求制定，从10天 - 90天不等
-
集群共3441个索引、17000个分片、数据总量约9300亿, 磁盘总消耗1PB
如果看到这里，说明你喜欢这篇文章，请转发、点赞
。同时标星（置顶）本公众号可以第一时间接受到博文推送。
本文分享自微信公众号 - Java后端（web_resource）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
相关文章
