尽力而为！

记录当前所有可用的segment，每个commit point都会维护一个.del文件，即每个.del文件都有一个commit point文件（es删除数据本质是不属于物理删除），当es做删改操作时首先会在.del文件中声明某个document已经被删除，文件内记录了在某个segment内某个文档已经被删除，当查询请求过来时在segment中被删除的文件是能够查出来的，但是当返回结果时会根据commit point维护的那个.del文件把已经删除的文档过滤掉。

关系型数据库范式化（Normalize）设计的主要目标是减少不必要的更新，往往会带来一些副作用：一个完全范式化设计的数据库会经常面临“查询缓慢”的问题。搜不到的原因：存储时，内部对象的边界并没有考虑在内,JSON格式被处理成扁平式键值对的结构。自Elasticsearch 5.x后引入，专门为Elasticsearch 设计，扩展了Java的语法。反范式化(Denormalize)的设计不使用关联关系，而是在文档中保存冗余的数据拷贝。一条数据的改动，可能会引起很多数据的更新。

Terms，需要字段支持filedata，如果是keyword 默认支持fielddata，如果是text需要在Mapping 中开启fielddata，会按照分词后的结果进行分桶。不精准的原因： 数据分散到多个分片，聚合是每个分片的取 Top X，导致结果不精准。聚合函数：指定要执行的聚合操作，如 sum、avg、min、max、terms、date_histogram 等等。查询条件：指定需要聚合的文档，可以使用标准的 Elasticsearch 查询语法，如 term、match、range 等等。

搜索的相关性算分，描述了一个文档和查询语句匹配的程度。ES 会对每个匹配查询条件的结果进行算分_score。打分的本质是排序，需要把最符合用户需求的文档排在前面。如何衡量相关性：1. Precision(查准率)―尽可能返回较少的无关文档。2. Recall(查全率)–尽量返回较多的相关文档。3. Ranking -是否能够按照相关度进行排序。

查询第一页5条数据"query": {},"from": 0,"size": 5但是如果我们查询的数据页数特别大，当from + size大于10000的时候，就会出现问题，如下图报错信息所示：ES通过参数index.max_result_window用来限制单次查询满足查询条件的结果窗口的大小，其默认值为10000。分页方式性能优点缺点适用场景低灵活性好，实现简单，支持随机翻页受制于max_result_window设置，不能无限制翻页；存在深度翻译问题，越往后翻译越慢。

全文检索查询旨在基于相关性搜索和匹配文本数据。这些查询会对输入的文本进行分析，将其拆分为词项（单个单词），并执行诸如分词、词干处理和标准化等操作。Elasticsearch 中的一些全文检索查询示例包括 match、match_phrase 和 multi_match 查询。

常见的编辑距离值包括0、1、2，其中0表示精确匹配，1表示允许一个字符的差异，2表示允许两个字符的差异，以此类推。术语级别查询（Term-Level Queries）指的是搜索内容不经过文本分析直接用于文本匹配，这个过程类似于数据库的SQL查询，搜索的对象大多是索引的非text类型字段。术语查询直接返回包含搜索内容的文档，常用来查询索引中某个类型为keyword的文本字段，类似于SQL的“=”查询，使用十分普遍。参数，你可以指定要忽略的前缀长度，以便更精确地匹配剩余的部分。

ElasticsearchRestTemplate模板类，封装了便捷操作Elasticsearch的模板方法，包括 索引 / 映射 / CRUD 等底层操作和高级操作。该接口是框架封装的用于操作Elastsearch的高级接口。

正排索引（Forward Index）和倒排索引（Inverted Index）是全文检索中常用的两种索引结构，它们在索引和搜索的过程中扮演不同的角色。正排索引（正向索引）正排索引是将文档按顺序排列并进行编号的索引结构。每个文档都包含了完整的文本内容，以及其他相关的属性或元数据，如标题、作者、发布日期等。在正排索引中，可以根据文档编号或其他属性快速定位和访问文档的内容。正排索引适合用于需要对文档进行整体检索和展示的场景，但对于包含大量文本内容的数据集来说，正排索引的存储和查询效率可能会受到限制。

1. 生产者使用事务消息机制。2. Broker配置同步刷盘+Dledger主从架构。3. 消费者不要使用异步消费。4. 整个MQ挂了之后准备降级方案。

对于事务消息机制，最关键的事务监听器需要通过@RocketMQTransactionListener注解注入到Spring容器当中。在这个注解当中可以通过rocketMQTemplateBeanName属性，指向具体的RocketMQTemplate子类。一个RocketMQTemplate实例只能包含一个生产者，也就只能往一个Topic下发送消息。如果需要往另外一个Topic下发送消息，就需要通过@ExtRocketMQTemplateConfiguration()注解另外声明一个子类实例。

由于RocketMQ与消费者端有失败重试机制，所以，只要消息成功发送到RocketMQ了，那么可以认为Branch2.1，Branch2.2，Branch2.3这几个分支步骤，是可以保证最终的数据一致性的。在此基础上，RocketMQ提出了事务消息机制，采用两阶段提交的思路，保证Main Branch1和Branch2之间的事务一致性。他的基础诉求是通过RocketMQ的事务机制，来保证上下游的数据一致性。​ 3、其实，了解了事务消息的机制后，在具体执行时，可以对事务流程进行适当的调整。

异步发送的机制能够比较好的兼容消息的安全性以及生产者的高吞吐需求，是很多MQ产品都支持的方式。但是异步发送机制也并不是万能的，毕竟异步发送机制对消息生产者的主线业务是有侵入的。但是，这里还是会造成一种分裂，消息最终是由Consumer来处理，但是消息却是由Broker推送过来的，也就是说，Consumer无法确定自己将要处理的是哪些消息。使用同步发送的机制，我们就可以在消息生产者发送完消息后，对发送失败的消息进行补救。

RocketMQ是阿⾥巴巴开源的⼀个消息中间件，在阿⾥内部历经了双⼗⼀等很多⾼并发场景的考验，能够处理亿万级别的消息。2016年开源后捐赠给Apache，现在是Apache的⼀个顶级项⽬。早期阿⾥使⽤ActiveMQ，但是，当消息开始逐渐增多后，ActiveMQ的IO性能很快达到了瓶颈。于是，阿⾥开始关注Kafka。但是Kafka是针对⽇志收集场景设计的，他的⾼级功能并不是很贴合阿⾥的业务场景。尤其当他的 Topic过多时，由于Partition⽂件也会过多，这就会加⼤⽂件索引的耗时，会严重影响IO性能。

Netty中使用MessagePack序列化对象。

每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节，以及如何将其和目标应用程序的数据格式做相互转换。这种转换逻辑由编解码器处理，编解码器由编码器和解码器组成，它们每种都可以将字节流从一种格式转换为另一种格式。如果将消息看作是对于特定的应用程序具有具体含义的结构化的字节序列—它的数据。那么编码器是将消息转换为适合于传输的格式（最有可能的就是字节流）。而对应的解码器则是将网络字节流转换回应用程序的消息格式。因此，编码器操作出站数据，而解码器处理入站数据。

假设客户端分别发送了两个数据包 D1 和 D2 给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下 4 种情况。1. 服务端分两次读取到了两个独立的数据包，分别是 D1 和 D2，没有粘包和拆包。2. 服务端一次接收到了两个数据包，D1 和 D2 粘合在一起，被称为 TCP 粘包。3. 服务端分两次读取到了两个数据包，第一次读取到了完整的 D1 包和 D2 包的部分内容，第二次读取到了 D2 包的剩余内容，这被称为 TCP 拆包。

从开发人员的角度来看，Netty 的主要组件是 ChannelHandler，它充当了所有处理入站和出站数据的应用程序逻辑的容器。ChannelHandler 的方法是由网络事件触发的。事实上，ChannelHandler 可专门用于几乎任何类型的动作，例如将数据从一种格式转换为另外一种格式，例如各种编解码，或者处理转换过程中所抛出的异常。

如果一个消息或者任何其他的入站事件被读取，那么它会从 ChannelPipeline 的头部开始流动，但是只被处理入站事件的 Handler 处理，也就是解压（入）Handler、解密（入）Handler、 授权（入） Handler，最终，数据将会到达 ChannelPipeline 的尾端，届时，所有处理就都结束了。在这种情况下，数据将从链的尾端开始流动，但是只被处理出站事件的 Handler 处理，也就是加密（出） Handler、 压缩（出）handler，直到它到达链的头部为止。

Bootstrap 是 Netty 框架的启动类和主入口类，分为客户端类Bootstrap和服务器类ServerBootstrap两种。Channel 是 Java NIO 的一个基本构造。它代表一个到实体（如一个硬件设备、一个文件、一个网络套接字或者一个能够执行一个或者多个不同的 I/O 操作的程序组件）的开放连接，如读操作和写操作，目前，可以把 Channel 看作是传入（入站）或者传出（出站）数据的载体。因此，它可以被打开或者被关闭，连接或者断开连接。

阻塞的原理是：操作系统为了支持多任务，实现了进程调度的功能，会把进程分为“运行”和“等待”等几种状态。为了更好的理解epoll，我们先看select是如何做的，服务端需要管理多个客户端连接，而 recv 只能监视单个 socket，假如能够预先传入一个 socket 列表，如果列表中的 socket 都没有数据，挂起进程，直到有一个 socket 收到数据，唤醒进程。首先，我们需要知道，数据是通过网线传输到网卡上的，网卡收到网线传来的数据，经过硬件电路的传输，最终将数据写入到内存中的某个地址上。

在选择 select，poll，epoll 时要根据具体的使用场合以及这三种方式的自身特点。1、表面上看 epoll 的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和 poll 的性能可能比 epoll 好，毕竟 epoll 的通知机制需要很多函数回调。2、select 低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善。

零拷贝(英语: Zero-copy) 技术是指计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省 CPU 周期和内存带宽。零拷贝技术可以减少数据拷贝和共享总线操作的次数，消除传输数据在存储器之间不必要的中间拷贝次数，从而有效地提高数据传输效率。零拷贝技术减少了用户进程地址空间和内核地址空间之间因为上下文切换而带来的开销可以看出没有说不需要拷贝，只是说减少不必要的拷贝。

NIO中Reactor模式的基本组成部分Selector（选择器）：Selector是 Reactor 模式的核心，负责监听各个通道上的事件，如连接、接收、读取和写入事件。通过 Selector，一个单独的线程可以有效地管理多个通道，使得系统可以在一个线程内同时处理多个连接。Channel（通道）：Channel 是数据的载体，可以是文件、套接字等。通道向 Selector 注册，告诉 Selector 哪些事件它关心，然后 Selector 将根据事件的发生情况通知对应的通道。

计算机网络的标准定义是：利用通信线路将地理上分散的、具有独立功能的计算机系统 和通信设备按不同的形式连接起来，以功能完善的网络软件及协议实现资源共享和信息传递 的系统。计算机网络从覆盖范围上划分可以分为三类：局域网、城域网、广域网。局域网 LAN（作 用范围一般为几米到几十公里）、城域网 MAN（界于 WAN 与 LAN 之间）、广域网 WAN（作用 范围一般为几十到几千公里）。

比如，在原有Topic下，可以调整Producer的分区策略，让Producer将后续的消息更多的发送到新增的Partition里，这样可以让各个Partition上的消息能够趋于平衡。思路是可行的，但是重试的次数，发送消息的数量等都是需要考虑的问题。PageCache缓存中的消息是断电即丢失的。因为如果业务逻辑异步进行，而消费者已经同步提交了Offset，那么如果业务逻辑执行过程中出现了异常，失败了，那么Broker端已经接收到了消费者的应答，后续就不会再重新推送消息，这样就造成了业务层面的消息丢失。

在RecordAccumulator中，会针对每一个Partition，维护一个Deque双端队列，这些Dequeue队列基本上是和Kafka服务端的Topic下的Partition对应的。​然后，Sender对读取出来的消息，会以Broker为key，缓存到一个对应的队列当中。但是如果消费者没有提交Offset，Broker就会认为这个消息还没有被处理过，就会重新往对应的消费者组进行推送，不过这次，一般会尽量推送给同一个消费者组当中的其他消费者实例。这是一个从0开始单调递增的数字。

构建Producer分为三个步骤：1. 设置Producer核心属性：Producer可选的属性都可以由ProducerConfig类管理。比如ProducerConfig.BOOTSTRAP_SERVERS_CONFIG属性，显然就是指发送者要将消息发到哪个Kafka集群上（目前用的非集群）。这是每个Producer必选的属性。2. 构建消息：Kafka的消息是一个Key-Value结构的消息。其中，key和value都可以是任意对象类型。

Apache Kafka是一个分布式流处理平台，最初由LinkedIn开发并于2011年开源。它主要用于解决大规模数据的实时流式处理和数据管道问题。Kafka是一个分布式的发布-订阅消息系统，可以快速地处理高吞吐量的数据流，并将数据实时地分发到多个消费者中。Kafka消息系统由多个broker（服务器）组成，这些broker可以在多个数据中心之间分布式部署，以提供高可用性和容错性。Kafka的基本架构由生产者、消费者和主题（topic）组成。

Zookeeper注册中心的优点：1. 高可用性：ZooKeeper是一个高可用的分布式系统，可以通过配置多个服务器实例来提供容错能力。如果其中一个实例出现故障，其他实例仍然可以继续提供服务。2. 强一致性：ZooKeeper保证了数据的强一致性。当一个更新操作完成时，所有的服务器都将具有相同的数据视图。这使得ZooKeeper非常适合作为服务注册中心，因为可以确保所有客户端看到的服务状态是一致的。3. 实时性：ZooKeeper的监视器（Watcher）机制允许客户端监听节点的变化。

在单体的应用开发场景中涉及并发同步的时候，大家往往采用Synchronized（同步）或者其他同一个JVM内Lock机制来解决多线程间的同步问题。在分布式集群工作的开发场景中，就需要一种更加高级的锁机制来处理跨机器的进程之间的数据同步问题，这种跨机器的锁就是分布式锁。目前分布式锁，比较成熟、主流的方案：1. 基于数据库的分布式锁。这种方案使用数据库的事务和锁机制来实现分布式锁。虽然在某些场景下可以实现简单的分布式锁，但由于数据库操作的性能相对较低，并且可能面临锁表的风险，所以一般不是首选方案。

ZooKeeper实现队列步骤1.创建队列根节点：在Zookeeper中创建一个持久节点，用作队列的根节点。所有队列元素的节点将放在这个根节点下。2.实现入队操作：当需要将一个元素添加到队列时，可以在队列的根节点下创建一个临时有序节点。节点的数据可以包含队列元素的信息。3.实现出队操作：当需要从队列中取出一个元素时，先获取根节点下的所有子节点。再找到具有最小序号的子节点，获取该节点的数据，删除该节点，然后返回节点的数据。

命名服务是为系统中的资源提供标识能力。ZooKeeper的命名服务主要是利用ZooKeeper节点的树形分层结构和子节点的顺序维护能力，来为分布式系统中的资源命名。需要用到分布式命名服务的应用场景典型的有：分布式API目录、分布式节点命名、分布式ID生成器。

Curator是Netflix公司开源的一套ZooKeeper客户端框架，和ZkClient一样它解决了非常底层的细节开发工作，包括连接、重连、反复注册Watcher的问题以及NodeExistsException异常等。Curator是Apache基金会的顶级项目之一，Curator具有更加完善的文档，另外还提供了一套易用性和可读性更强的Fluent风格的客户端API框架。Curator还为ZooKeeper客户端框架提供了一些比较普遍的、开箱即用的、分布式开发用的解决方案，例如Recipe、共享锁服务等

ZooKeeper是一个开源的分布式协调框架，是Apache Hadoop的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。

RabbitMQ的生产者确认机制分为同步确认和异步确认。同步确认主要是通过在生产者端使用Channel.waitForConfirmsOrDie()指定一个等待确认的完成时间。异步确认机制则是通过channel.addConfirmListener(ConfirmCallback var1, ConfirmCallback var2)在生产者端注入两个回调确认函数。第一个函数是在生产者消息发送成功时调用，第二个函数则是生产者消息发送失败时调用。两个函数需要通过sequenceNumber自行完成前后对应。

TTL+死信队列实现逻辑，创建一个普通交换机跟队列，给队列设置TTL超时时间，但是不给这个队列绑定消费者，给这个普通队列绑定死信交换机，等到消息超时就会发送到死信交换机，给死信交换机配一个消费者来消费。为了更方便、更灵活地实现延迟队列功能，可以使用RabbitMQ提供的插件rabbitmq_delayed_message_exchange，这个插件为RabbitMQ提供了原生的延迟队列支持，允许在不使用死信队列的情况下直接实现延迟消息的发送和消费。

整体上来说，RabbitMQ的Stream队列，其实有很多地方借鉴了其他MQ产品的优点，在保证消息可靠性的基础上，着力提高队列的消息吞吐量以及消息转发性能。Stream队列的核心是以append-only只添加的日志来记录消息，整体来说，就是消息将以append-only的方式持久化到日志文件中，然后通过调整每个消费者的消费进度offset，来实现消息的多次分发。​ RabbitMQ已有的这些队列类型，在消费者处理完消息后，消息都会从队列中删除，因此，无法重新读取已经消费过的消息。

所有的基础运行环境都在application.properties中进行配置。所有配置以spring.rabbitmq开头。通常按照示例进行一些基础的必要配置就可以跑了。不同版本下的配置方式会有变化。

首先，Consumer端的autoAck字段设置的是false,这表示consumer在接收到消息后不会自动反馈服务器已消费了message，而要改在对message处理完成了之后（也就是consumer中的处理逻辑中），再调用channel.basicAck来通知服务器已经消费了该message.这样即使Consumer在执行message过程中出问题了，也不会造成message被忽略，因为没有ack的message会被服务器重新进行投递。这个是一个唯一的序列号，代表一个唯一的消息。