ElasticSearch

点击上方蓝色“ 冰河技术 ”，关注并 选择“设为星标” 持之以恒，贵在坚持，每天进步一点点！ 作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。 自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。 为使更多童鞋受益，现给出开源框架地址： https://github.com/sunshinelyz/mykit-delay PS: 欢迎各位Star源码，也可以pr你牛逼哄哄的代码 。 写在前面 在当今互联网行业，尤其是现在分布式、微服务开发环境下，为了提高搜索效率，以及搜索的精准度，会大量使用Redis、Memcached等NoSQL数据库，也会使用大量的Solr、Elasticsearch等全文检索服务。那么，这个时候，就会有一个问题需要我们来思考和解决：那就是数据同步的问题！如何将实时变化的数据库中的数据同步到Redis/Memcached或者Solr/Elasticsearch中呢？ 互联网背景下的数据同步需求 在当今互联网行业，尤其是现在分布式、微服务开发环境下，为了提高搜索效率，以及搜索的精准度，会大量使用Redis、Memcached等NoSQL数据库，也会使用大量的Solr、Elasticsearch等全文检索服务。那么，这个时候，就会有一个问题需要我们来思考和解决

做公号很久了，听到粉丝问的最多的问题就是：有没有新的完整的项目，因为现在很多流传的项目都太老了，实战意义不是很强。很多程序员每项技术单独拿出来有可能很厉害，例如：springcloud、springboot、redis、nginx、mysql、rabbitMq等，但是普遍缺乏将所有的这些技术整合到一起，从前端到后端，从开发到部署上线，从每个知识点到整体的设计。 本次分享不是分享项目而是教你如何开发一个项目细节流程。 课程简介 项目技术栈 基于springBoot2.x、springCloud采用前后端分离的架构；利用FastDFS作为分布式文件存储系统，Canal实现数据同步，监控数据变化；Elasticsearch+IK+Kibana实现商品搜索功能；Spring Security Oauth2 JWT实现微服务统一认证和资源授权；利用RabbitMq实现异步解耦；Seata实现分布式事务等，从而打造一个高可用的分布式电商系统。 技术架构 系统架构 功能教程 模块说明 项目截图 资料介绍 项目源码 视频教程 项目教程文档（500页） 工具清单 如何领取 识别并关注公众号「 程序员闪充宝 」； 在下面公众号后台回复关键字「 mall 」 长按上方二维码 2 秒 回复「 mall 」即可获取上面所有资料 本文分享自微信公众号 - java版web项目（java_project）。

做公号很久了，听到粉丝问的最多的问题就是：有没有新的完整的项目，因为现在很多流传的项目都太老了，实战意义不是很强。很多程序员每项技术单独拿出来有可能很厉害，例如：springcloud、springboot、redis、nginx、mysql、rabbitMq等，但是普遍缺乏将所有的这些技术整合到一起，从前端到后端，从开发到部署上线，从每个知识点到整体的设计。 本次分享不是分享项目而是教你如何开发一个项目细节流程。 项目介绍 项目技术栈 基于springBoot2.x、springCloud采用前后端分离的架构； 利用FastDFS作为分布式文件存储系统，Canal实现数据同步，监控数据变化； Elasticsearch+IK+Kibana实现商品搜索功能； Spring Security Oauth2 JWT实现微服务统一认证和资源授权； 利用RabbitMq实现异步解耦； Seata实现分布式事务等，从而打造一个高可用的分布式电商系统。 技术架构 系统架构 功能教程 模块说明 项目截图 资料介绍 项目源码 视频教程 项目教程文档（500页） 工具清单 如何领取？ 识别并关注公众号「 Java最全面试题库 」； 在下面公众号后台回复关键字「 mall 」 长按上方二维码 2 秒 回复「 mall 」即可获取上面所有资料 就在前两天，阿里发布了最新的 《阿里巴巴Java开发手册

https://www.jianshu.com/p/f4d322415d29 1.简介 ES为了避免深分页，不允许使用分页(from&size)查询10000条以后的数据，因此如果要查询第10000条以后的数据，要使用ES提供的 scroll(游标) 来查询 假设取的页数较大时(深分页)，如请求第20页，Elasticsearch不得不取出所有分片上的第1页到第20页的所有文档，并做排序，最终再取出from后的size条结果作爲最终的返回值 假设你有16个分片，则需要在coordinate node彙总到 shards* (from+size)条记录，即需要16*(20+10)记录后做一次全局排序 所以，当索引非常非常大(千万或亿)，是无法使用from + size 做深分页的，分页越深则越容易OOM，即便不OOM，也很消耗CPU和内存资源 因此ES使用index.max_result_window:10000作爲保护措施 ，即默认 from + size 不能超过10000，虽然这个参数可以动态修改，也可以在配置文件配置，但是最好不要这麽做，应该改用ES游标来取得数据 2.scroll游标原理 可以把 scroll 理解爲关系型数据库里的 cursor，因此，scroll 并不适合用来做实时搜索，而更适用于后台批处理任务，比如群发 scroll 具体分爲初始化和遍历两步

在Elasticsearch中，搜索单个单词是比较快的，当搜索短语的时候，效率会比较低。所以Elasticsearch提供了从新评分的方法来提高效率。他的原理主要是当在整个索引中搜索短语消耗的资源会比较多，但大多数时候，人们只关注最近发生一部分文档，所以可以先在最近的一段文档中先对短语进行从新评分，然后再查询，这个时候看起来效率会增加很多。 在返回搜索请求节点处理排序结果之前在每个分片上执行从新评分。通常情况下当我们用从新评分API来重新评分的过程只执行一次，在未来有可能会被调整。当search_type为 scan或者count的时候将不被执行。在用分页查询的时候，每一页查询的时候window_size尽量不要修改，如果修改了可能会引起排序的混乱，导致不可预知的结果。 查询评分时 在query或者post_filter 返回的top-k结果 ，在每个分片返回文档的数量有window_size控制，默认返回from到size的个数。 默认情况下对每个文档最终的得分(_score) 是原始的得分和从新评分后的得分进行线性组合后的结果。原始评分和从新评分的比例关系分布由query_weight 和rescore_query_weigh控制，默认都是1。例如从新评分查询： 请求：POST localhost:9200/_search 参数： { "query" : { "match" :

1、实战问题 球友提问：怎么搜索才能使得结果是最好的呢？ 我这边一个搜索功能，实现做法就是将用ik分词器配合multi查询实现的。 中途也追加了客户所在领域相关词汇字典。 但是客户一直反馈搜索体验不好。 如果想要提高搜索体验还能从那些方面入手呢？ 来自：死磕 Elasticsearch 知识星球 这个问题非常有代表性，我在实际产品开发中也遇到过。 2、从几个例子说搜索体验 示例一：“慕X网”输入“触发器”的搜索截图。 注意：我输入的是“触发器”，返回结果第一条没有问题，其他几条有关：“触”、“发”的，可以说和我的搜索没有关系。 站在用户体验的角度，我认为：体验很差，返回了很多不相关的数据。 示例二：某题库APP，不支持跳转翻页。 如下所示，题库共1703题，包含：判断题、选择题。 只支持：点击：上一题、下一题。 实际场景： 当做了100道、200道的时候，只有选择题；到底多少选择题？ 当退出后，需要点击几百下进入自己上次做到的最后一道题..... 这不是用户体验差，这是没有用户体验，开发者完全没有动脑子的设计，用户会"怀疑人生"。 示例三：电商搜索“秋天第一条秋裤”，该返回什么？ 放大 查看图片，亮点自现 这是个见仁见智的问题，究竟返回什么，各个电商公司都有自己的评判。 但，单纯站在用户的角度，高下立判。 铭毅一句话点评： 拼多多 “活该你发展快”，的确返回结果就是预期结果

点击上方“朱小厮的博客”，选择“设为星标” 后台回复"书"，获取 导语：本文的缘起是回答知乎圆桌会议「分布式系统之美」的问题「如何系统性地学习分布式系统?」，后面稍微整理了一下，形成了这一篇文章（知乎 ID：kylin）。 前 言 学习一个知识之前，我觉得比较好的方式是先理解它的来龙去脉：即这个知识产生的过程，它解决了什么问题，它是怎么样解决的，还有它引入了哪些新的问题（没有银弹），这样我们才能比较好的抓到它的脉络和关键点，不会一开始就迷失在细节中。 所以，在学习分布式系统之前，我们需要解决的第一个问题是：分布式系统解决了什么问题？ 分布式系统解决了什么问题？ 第一个是单机性能瓶颈导致的成本问题，由于摩尔定律失效，廉价 PC 机性能的瓶颈无法继续突破，小型机和大型机能提高更高的单机性能，但是成本太大高，一般的公司很难承受； 第二个是用户量和数据量爆炸性的增大导致的成本问题，进入互联网时代，用户量爆炸性的增大，用户产生的数据量也在爆炸性的增大，但是单个用户或者单条数据的价值其实比软件时代（比如银行用户）的价值是只低不高，所以必须寻找更经济的方案； 第三个是业务高可用的要求，对于互联网的产品来说，都要求 7 * 24 小时提供服务，无法容忍停止服务等故障，而要提供高可用的服务，唯一的方式就是增加冗余来完成，这样就算单机系统可以支撑的服务，因为高可用的要求，也会变成一个分布式系统。

目录 文章目录 目录 微服务架构的问题 如何拆分服务 服务间如何通信 微服务框架 API 网关 配置中心 Service Mesh 文档 微服务治理 监控 链路跟踪 日志分析 服务中心 熔断、服务降级、限流 微服务框架 Service Mesh 流量治理 微服务架构的问题 微服务架构中，服务之间会有错综复杂的依赖关系，例如：一个前端请求一般会依赖于多个后端服务，称为 “1=>N 扇出”。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源（线程，队列等）被耗尽，造成所谓的雪崩效应（Cascading Failure），严重时可致整个网站瘫痪。另外，微服务架构整个应用分散成多个服务，定位故障点非常困难。 服务组合 服务依赖： 微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。在解决了旧问题，也引入了新的问题： 微服务架构整个应用分散成多个服务，定位故障点非常困难。 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。 服务数量非常多，部署、管理的工作量很大。 开发方面

| 题记 | 网上当前（截止20170914）流传的各种配置文件普通存在以下问题： 1）版本低，不能和当前版本5.X匹配。 2）5.X的配置本身较1.X，2.X就有很大不同，原有配置已不适用。 3）ES英文、中文文档也没有及时更新。 现在，确保ES5.X的高性能到底需要哪些配置越发令人神往。 以下清单内容参考了ES官网文档，且都是在ES5.4.0的环境中验证过的，请放心使用。 清单1：了解ES集群拓扑结构 您需要确定您的部署拓扑，以便做出正确的Elasticsearch配置决策。 当我们启动Elasticsearch的实例，就会启动至少一个节点。相同集群名的多个节点的连接组成一个集群， 在默认情况下，集群中的每个节点都可以处理Http请求和集群节点的数据传输。 集群中的所有的节点都知道集群中其他所有的节点，可以将客户端请求转发到适当的节点。 了解节点的类别，如下 主节点(master)： node.master：true node.data:false 数据节点(data)： node.master：false node.data:true 客户端/路由节点(client)： node.master：false node.data:false 默认情况下，节点同时是主节点和数据节点，这适合小集群（3个节点）；大于3个节点后，分离主节点和数据节点变得非常重要。 清单2：配置线程池