qq_61839608的博客

2、查询：如果不是通过id具体的查询，那么在查询的时候不会走计算hash值，然后到相应的分片上去查。再把相应的数据传到coordinating node（协调节点），协调节点将所有的数据进行一个整合，把整合数据返回用户。如果新增一个分片，那么shard值没变，那么始终得到不到新增分片的id。单节点问题：单机的elasticsearch做数据存储，面临的两个问题：海量的数据存储问题、单节点故障。当节点恢复的时候，它会将一个分片和一个备份重新分配给node1节点，使得每一个节点都能均衡的有分片。

MySQL在进行增删改的时候会将操作记录到binlog上，然后在使用canal（通道）中间件，通知es发生改变，这样就会使得es数据得到更新。当服务对MySQL进行增删改的时候，这个时候使用fegin远程调用，将所更改的数据发送到es的服务上，使得es数据得到及时的更新。当MySQL进行增删改查的时候，数据库的数据有所改变，这个时候需要修改es中的索引库的值，这个时候就涉及到了数据同步的问题。使用消息中间件rabbitMQ，服务进行增删改的时候将信息放到MQ，es的服务去MQ中拿到信息，去更新自己的数据。

elasticssearch提供了CompletionSuggester查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回。完成一个hotel酒店的es库创建：（创建了两个自定义的分词器）+ 查询类型必须是：completion。+ 字段内容是多个补全词条形成的数组。

自定义分词器的配置：（只能是相应的索引库使用，创建了test索引库，那么自定义的只能在这个索引库中使用。默认的拼音分词器会将每个汉字单独分为拼音，而我们希望的是每个词条形成一组拼音，需要对拼音分词器做个性化定制，形成自定义分词器。为了避免搜索的时候使用拼音搜到同音词，所以在搜索的时候使用ik分词器"search_analyzer": "ik_smart"3、tokenizer filter：将tokenizer输出的词条做进一步处理。1、是直接将每个字的拼音返回和一段话的拼音首字母返回，不能很好的分词。

2、度量（Metric）聚合：用以计算一些值，AVG,MAX,MIN,SUM,STATS(都做前面的几个)+ Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组。3、管道聚合（Pipeline）：其他聚合的结果为基础做聚合（比如度量和桶的结果做基础）4、参与聚合的字段不能是可分词的（Text类型）：keyword，Date，数值，布尔。1、聚合：可以实现对文档数据的统计、分析、运算。1、桶（Bucket）聚合：用来对文档做分组。聚合嵌套和Metric聚合。

比如查询9990-10000的数据，es会首先查询出0-10000的数据，在对0-10000的数据截取，截取出9990-10000的文档数据。你查询9990-10000的数据就是从每个集群中查询0-10000的数据，然后将所有文档数据排序，然后将数据截取。如果是在分布式集群下面（es集群是为了尽可能多的存储数据，所以每个集群的数据不同）造成的问题，每个集群查需要时间，数据之间的排序需要时间，耗费的时间很大很大。复合查询：简单查询的组合，实现复杂的查询。数字排序sort：（双条件排序）

正排索引适合需要快速访问完整记录的情况，优于范围查询。倒排索引则适合文本检索，能够高效支持关键词搜索自己的理解正排索引：通过检索全部数据（例如mysql的每行，有很多行数据）将每一行的数据与关键字比对，如果匹配则添加到返回序列当中。倒排索引：两个字段：词条和文档id（）词条：包含一个文档中的一些关键字（文档按照语义分成的词语）文档id：包含这个关键字的文档（一行数据）

同步通讯的优缺点：优点：时效高，数据一致，过程简单缺点：耦合度高。性能下降。CPU等待资源的浪费。级联失败。2、异步通讯：异步调用常见的实现就是事件驱动模式异步的优缺点：优点：耦合度低 ，吞吐量提升 ，故障隔离（不在联机发生失败） ，流量削峰（Broker缓存事件，让其他服务慢慢来执行）缺点：依赖于Broker的可靠性、安全性、吞吐量架构复杂，没有明显的流程线，不好追踪管理一般的项目都是使用同步通讯，因为需要拿到其他服务的返回结果，而异步通讯只是通知他有事情要做，而不需要他返回结果。

容器内的数据可以到数据卷当中，数据卷中的数据也能到容器，这个交换是实时的）宿主机的目录挂载：这个挂载就是不在默认的数据卷存放路径了（/var/lib/docker/volumes/），这个路径可以是随意的，你想在哪里就在哪里。3、升级维护困难：当我们这个容器的版本过低要进行版本的更迭，那么旧版本上配置的数据在新的数据上不能复用（旧版本删除，配置的数据也随之删除了）。3、当你启动的时候，没有创建某个数据卷，但是你启动的时候又绑定了，那么这个数据卷在启动的时候就会自动创建。所有修改对新创建的容器是不可复用的。

（2）：开发、测试、生产环境有差异（比如centos开发和测试的，上线的时候需要部署到ubutu上，那么两个linux环境的不同就会造成项目出现错误）由此可知：当我们在每个应用的容器中顺带打包了某个系统的函数库，那么我们就可以部署到任意的一台机器上，而不用管这个机器是那个操作系统了（内核相同就行）（1）：系统应用：每个系统都有自己的系统，每个系统应该的命令（函数）不同（导致部署项目系统之间的不兼容）（2）：内核：内核接收到每个系统的命令之后，将这些命令转化为相应的指令，这些指令就去操作计算机硬件。

3、全局过滤器（GlobalFilter）：在已经有了一个default-filter全局的情况下为什么还需要这个全局的呢？两个的优缺点：zuul是基于servlet实现的阻塞式编程，而gateway是基于spring5提供的webflux实现的响应式的编程。（2）：服务路由（具体的业务路由到具体的服务），负载均衡（多台服务的话，服务之间进行负载均衡）4、过滤器的执行顺序，局部和默认过滤器的order值为1，如果下面有多个则依次增大。1、局部路由过滤器：（在相应路由的微服务生效）

service也需要api，controller也需要相同的api，将这个方法提出来写一个接口供他们两个使用。2、抽取：在controller层面将相应的请求的方法写好，然后打包。在其他的微服务只需要导包，然后调用相应的请求方法。）（在高版本的springboot中还需要加入一个负载均衡的依赖，有了这个依赖之后需要把ribbon排除）缺点：service和controller是紧耦合，并且service也需要写参数中的注解。2、Fegin是一个声明式的http客户端，其作用是优雅的帮我们发起http请求。

3、配置bootstrap.yml文件（配置的原因：因为项目一启动开始就去读nacos中的配置文件，而不是直接读取application.yml文件。这就导致在application.yml中配置的nacos中的路径和其他的都不能提前知道了。这就需要一个启动之后先获取nacos的配置的文件，之后去读nacos中的配置）1、配置的环境有很多，dev，test等等。因为这些环境的名称都相同，每个环境不同的只是后面的profiles。2、环境的优先级：不同的环境可以有相同的属性值，那么以哪个为准呢？

这个拉取是服务被动的拉取，当在一次拉取之后，还没有到下次拉取的时间的时候，如果有服务提供者挂了，则服务消费者不知道并主动的去请求服务提供者则会失败报错。一个程序更新完之后，首先将这个机器的服务启动，将其他机器的服务的权重设置为0。如果一个权重是1，一个是0.1，则第一个被访问的次数是第二个的十倍（当然这个前提是你在同一个集群当中，如果是不同的集群可能是不生效的）。当nacos中的服务列表发生变化，nacos会主动将服务的情况告诉服务消费者，而不是服务消费者等待到下次拉取的时候才知道。

过程：首先通过RestTemplate发起请求，负载均衡拦截器拦截请求，拿到名称user-server（"http://user-server/user/"）后，将名称发送到动态服务拦截器，动态服务拦截器通过与eureka服务注册中心交互，拿到名称为user-server的客户端ip和端口，返回的是一个列表。（1）：第一种bean：第一种bean是全局配置（就是一个微服务1里面，会请求其他的微服务，这个请求的数目很多，微服务1请求其他每种不同的微服务有不同的负载均衡方式，如：轮询，随机等等。

1、如下图：2、3、