杂七杂八111

MQ

用处

一、异步。可提高性能和吞吐量

二、解耦

三、削峰

四、可靠。常用消息队列可以保证消息不丢失、不重复消费、消息顺序、消息幂等

选型

一Kafak:吞吐量最大，性能最好，集群高可用。缺点：会丢数据，功能较单一。

二RabbitMQ：可靠性高，功能全面。缺点：吞吐量低，可能消息积累影响性能。

三RocketMQ:高吞吐、高性能、高可用、事务性消息。缺点：生态相对不成熟。

如何保证消息不丢失

可能会丢失消息的环节

生产者->MQ MQ主从复制 MQ存磁盘 MQ->消费者

依次解决

一、生产者发送消息到MQ：

Kafak:回调。RocketMQ:回调、事务性消息。RobbitMQ：回调、手动事务、事务性消息(不细腻)

回调：生产者发送消息之后会注册一个回调函数，MQ收到消息返回ack，表示已收到。

二、消息同步不丢失：

RocketMQ:

普通集群中，异步同步性能高，可能丢消息。同步同步相反。

同步同步是指master结点拿到消息后从节点发送消息，从节点存盘后返回生产者ack。

异步同步是指master结点收到消息后往从节点同步消息，并直接返回生产者ask。

Dledger集群-两阶段提交。类似于ZAB协议同步数据。

RabbitMQ:

普通集群中，消息分散存储，结点不主动进行消息同步，可能丢消息。

镜像集群中，会在集群之间主动进行消息同步，安全性较高。

Kafak:

通常用在允许消息少量丢失的场景。

三、MQ消息内存到磁盘消息不丢失：

RocketMQ：使用同步刷盘安全性高，性能低。异步刷盘相反。

broker收到消息后，消息在内存中，需要其他线程将消息刷新到磁盘。

RabbitMQ：将消息配置为持久化队列，新增的Quorum类型的队列，用Raft协议进行消息同步。

四、MQ消费者消费消息不丢失：

分析：消息队列中有消息的偏移量，一般是在本地事务执行完成后移动。异步可能会丢失消息

RocketMQ：使用默认方式消费即可，不要采用异步的方式。

RabbitMQ:autoCommit->手动提交offset。

Kakfa:手动提交offset

原则：采用同步的方式，在消息被消费完成，也就是本地事务执行完后提交消息，移动偏移量。

如何保证消息幂等

MQ产品并没有主动提供解决幂等的机制，需要由消费者自行控制。

RocketMQ中可以给每条消息分配一个ID，作为判断依据，但不保证全局唯一，不推荐。

建议使用带业务标识的ID，来进行幂等判断，如OrderID，统一ID分配。

如何保证消息有序

MQ只需保证局部有序，不需要保证全局有序。例如一个聊天窗口和整个QQ消息。

关键在于，单机下，队列可以先进先出保证有序，但在分布式状态下，有多个队列。

所以要保证生产者把一组消息放到同一个队列中，而消费者依次消费该消息组的所有消息

RockeMQ:

有完整设计，生产者中MessageSelevtor可保证，消费者需要注册一个registerMessageListener

RabbitMQ:要保证一组消息只对应一个队列，并且一个队列只对应一个消费者

Kafak:生产者可以将消息分配到同一个partition。Topic下只由同一个消费者消费

什么是？

Elasticsearch是一个开源的分布式全文搜索和分析引擎，它能够快速地处理大量的数据，并具有高度可扩展性和可靠性。Elasticsearch最初是在Lucene搜索引擎的基础上开发的，它提供了一个RESTful API，可以通过HTTP来访问。

以下是Elasticsearch的主要特点：

分布式架构：Elasticsearch采用分布式架构，可以将数据分片存储在多个节点上，从而提高数据的处理能力和可靠性。
实时搜索：Elasticsearch能够快速地搜索和分析数据，支持实时搜索，可以在毫秒级别内返回搜索结果。
多种查询方式：Elasticsearch支持多种查询方式，包括全文搜索、精确匹配、模糊匹配、范围查询等。
自动负载均衡：Elasticsearch可以自动将数据分配到集群中的不同节点上，并实现负载均衡，从而提高系统的可用性和性能。
可扩展性：Elasticsearch可以通过添加新节点来扩展集群的处理能力，同时也支持水平扩展和垂直扩展。
多种数据类型：Elasticsearch支持多种数据类型，包括文本、数字、日期、地理位置等。
多语言支持：Elasticsearch支持多种语言，包括Java、Python、PHP等。
数据安全性：Elasticsearch支持数据加密和访问控制，可以保障数据的安全性。

总的来说，Elasticsearch是一个功能强大、可靠性高、可扩展性好、易于使用的搜索引擎和分析工具，被广泛应用于各种大规模的数据处理和搜索分析场景。

什么是倒排索引

倒排索引（Inverted Index）是一种常用的文本索引技术，用于快速地查找包含特定词语的文档。在倒排索引中，每个词语都对应着一组文档，这些文档包含了该词语出现的位置信息。

倒排索引的构建过程包括以下几个步骤：

分词：将文本内容按照一定的规则进行分词，形成一组词语。
建立索引：对每个词语建立一个索引，索引中包含了该词语出现的文档列表。
存储位置信息：对于每个文档，记录该词语出现的位置信息，以便后续的检索和排名。

倒排索引的查询过程包括以下几个步骤：

输入查询词语：用户输入要查询的词语。
查找索引：根据查询词语，在倒排索引中查找对应的文档列表。
进一步筛选：根据查询词语在文档中出现的位置信息，进一步筛选出符合查询条件的文档。
返回结果：返回符合条件的文档列表，可以按照相关性进行排序。

倒排索引的优点包括：

快速查找：倒排索引可以快速地查找包含特定词语的文档，减少了搜索的时间和计算量。
精确匹配：倒排索引可以实现精确的词语匹配，避免了模糊匹配和错误匹配。
支持多种查询方式：倒排索引支持多种查询方式，包括全文搜索、短语搜索、通配符搜索、范围搜索等。
支持高效的排名：倒排索引可以根据词语在文档中出现的位置信息，计算出文档的相关性，从而实现高效的排名。

总的来说，倒排索引是一种高效、精确、灵活的文本索引技术，被广泛应用于各种搜索引擎和文本处理系统中。

BoolQueryBuilder

BoolQueryBuilder是Elasticsearch Java API中的一个类，用于构建布尔查询，即使用多个查询条件进行组合查询的操作。除了must、should和must_not三种查询之外，BoolQueryBuilder还提供了一个filter方法，用于添加过滤条件。

与查询条件不同的是，过滤条件不会影响搜索结果的相关性得分，它只是根据条件过滤掉不符合要求的文档，从而提高搜索效率。因此，过滤条件通常用于一些不需要考虑相关性得分的场景，例如范围查询、精确匹配等。

使用filter方法时，需要先创建一个实例对象，然后通过方法链式调用来添加过滤条件。例如：

BoolQueryBuilder boolQuery = QueryBuilders.boolQuery().must(QueryBuilders.termQuery("field1", "value1")).should(QueryBuilders.termQuery("field2", "value2")).mustNot(QueryBuilders.termQuery("field3", "value3")).filter(QueryBuilders.rangeQuery("field4").gte(10).lte(20));

以上代码构建了一个bool查询，包含了三个查询条件和一个过滤条件：field1=value1（必须满足）、field2=value2（可以满足）、field3=value3（不能满足）、field4的值必须在10到20之间（过滤条件）。

构建完bool查询后，可以将其作为参数传递给SearchRequestBuilder的setQuery方法，用于进行搜索操作。例如：

SearchResponse response = client.prepareSearch("index").setQuery(boolQuery).execute().actionGet();

以上代码将bool查询作为参数传递给SearchRequestBuilder的setQuery方法，执行搜索操作，并返回搜索结果。

总之，BoolQueryBuilder是Elasticsearch Java API中一个非常常用的类，可以方便地构建复杂的布尔查询和过滤条件，提高搜索的精确度和效率。

filter和must有什么区别？

过滤条件和must条件都是BoolQueryBuilder类中的方法，用于构建布尔查询。两者的区别在于，过滤条件不会影响搜索结果的相关性得分，而must条件会影响搜索结果的相关性得分。

过滤条件主要用于过滤掉不符合条件的文档，从而提高搜索效率。过滤条件通常用于一些不需要考虑相关性得分的场景，例如范围查询、精确匹配等。在搜索时，过滤条件会被应用到搜索结果上，从而过滤掉不符合条件的文档。

must条件主要用于筛选符合条件的文档，并影响搜索结果的相关性得分。must条件可以包含多个子条件，表示所有子条件都必须满足，相当于“AND”操作。在搜索时，must条件会被应用到搜索结果上，从而筛选出符合条件的文档，并对搜索结果的相关性得分进行加权。

例如，假设我们要搜索商品名称包含“手机”且价格在1000到2000之间的商品，可以使用以下bool查询：

BoolQueryBuilder boolQuery = QueryBuilders.boolQuery().must(QueryBuilders.matchQuery("name", "手机")).filter(QueryBuilders.rangeQuery("price").gte(1000).lte(2000));

以上代码使用must条件筛选出商品名称包含“手机”的文档，并使用filter条件过滤掉价格不在1000到2000之间的文档。在搜索时，must条件会影响搜索结果的相关性得分，而filter条件不会影响搜索结果的相关性得分，从而提高搜索效率。

总之，过滤条件和must条件都是BoolQueryBuilder类中的方法，用于构建复杂的布尔查询。两者的区别在于，过滤条件不会影响搜索结果的相关性得分，而must条件会影响搜索结果的相关性得分。在实际应用中，我们需要根据具体场景选择合适的条件，以获得更好的搜索效果。

在这里插入图片描述

代理模式

在这里插入图片描述

工厂模式

在这里插入图片描述

CAP

在这里插入图片描述

BASE理论

在这里插入图片描述

Raft算法

在这里插入图片描述

Stomp协议

STOMP(Simple Text-Orientated Messaging Protocol) 面向消息的简单文本协议

WebSocket是一个消息架构，不强制使用任何特定的消息协议，它依赖于应用层解释消息的含义；

与处在应用层的HTTP不同，WebSocket处在TCP上非常薄的一层，会将字节流转换为文本/二进制消息，因此，对于实际应用来说，WebSocket的通信形式层级过低，因此，可以在 WebSocket 之上使用 STOMP协议，来为浏览器和 server间的通信增加适当的消息语义。

如何理解 STOMP 与 WebSocket 的关系：

HTTP协议解决了 web 浏览器发起请求以及 web 服务器响应请求的细节，假设 HTTP 协议并不存在，只能使用 TCP 套接字来编写 web 应用，你可能认为这是一件疯狂的事情；
直接使用 WebSocket（SockJS）就很类似于使用 TCP 套接字来编写 web 应用，因为没有高层协议，就需要我们定义应用间所发送消息的语义，还需要确保连接的两端都能遵循这些语义；
同 HTTP 在 TCP 套接字上添加请求-响应模型层一样，STOMP 在 WebSocket 之上提供了一个基于帧的线路格式层，用来定义消息语义；
WebSocket协议定义了两种消息类型（文本类型和二进制类型），但是消息内容却是未定义的，下面我们介绍一下STOMP协议。

STOMP (Simple Text Oriented Messaging Protocol) 起源于脚本语言，比如Ruby、Python和Perl，用于连接企业消息代理，它可以用于任何可靠的双向网络协议中，如TCP和WebSocket。尽管STOMP是一个面向文本的协议，但消息负载可以是文本或者二进制。

STOMP基于WebSocket在客户端和服务端之间定义了一种机制，协商通过子协议（更高级的消息协议）来定义可以发送何种消息，每条消息的内容是什么，等等。