京东到家订单查询服务演进

ES集群的分页查询支持from和size参数，查询的时候每个分片必须构造一个长度为from+size的优先队列，然后回传到网关节点，网关节点再对这些优先队列进行排序找到正确的size个文档。假设在一个有6个主分片的索引中，from为10000，size为10，每个分片必须产生10010个结果，在网关节点中汇聚合并60060个结果，最终找到符合要求的10个文档。由此可见，当from足够大的时候，就算不发生OOM，也会影响到CPU和带宽等，从而影响到整个集群的性能。所以应该避免深分页查询，尽量不去使用。

3. FieldData与Doc Values

Fielddata：线上查询出现偶尔超时的情况，通过调试查询语句，定位到是跟排序有关系。排序在es 1.x版本使用的是fielddata 结构，fielddata占用的是jvm heap内存，jvm内存是有限，对于fielddata cache会设定一个阈值。如果空间不足时，使用最久未使用(LRU)算法移除fielddata，同时加载新的fielddata cache，加载的过程需要消耗系统资源，且耗时很大。所以导致这个查询的响应时间暴涨，甚至影响整个集群的性能。针对于这种问题，解决的方式是采用doc values。

Doc Values：Doc Values是一种列式的数据存储结构，跟fieldata很类似，但其存储位置是在Lucene文件中，即不会占用JVM heap。随着ES版本的迭代，doc values比fielddata更加稳定，doc values在2.x起为默认设置。

总结

架构的快速迭代源于业务的快速发展，正是由于近几年到家业务的高速发展，订单中心的架构也不断优化升级。而架构方案没有最好的，只有最合适的，相信再过几年，订单中心的架构又将是另一个面貌，但吞吐量更大，性能更好，稳定性更强，将是订单中心系统永远的追求。

作者：张淦 京东到家研发工程师 主要负责订单中心，商家中心，计费等系统

【本文是51CTO专栏作者张开涛的原创文章，作者微信公众号：开涛的博客，id:kaitao-1234567】

戳这里，看该作者更多好文

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!