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的主要特点:

  1. 分布式架构:Elasticsearch采用分布式架构,可以将数据分片存储在多个节点上,从而提高数据的处理能力和可靠性。

  2. 实时搜索:Elasticsearch能够快速地搜索和分析数据,支持实时搜索,可以在毫秒级别内返回搜索结果。

  3. 多种查询方式:Elasticsearch支持多种查询方式,包括全文搜索、精确匹配、模糊匹配、范围查询等。

  4. 自动负载均衡:Elasticsearch可以自动将数据分配到集群中的不同节点上,并实现负载均衡,从而提高系统的可用性和性能。

  5. 可扩展性:Elasticsearch可以通过添加新节点来扩展集群的处理能力,同时也支持水平扩展和垂直扩展。

  6. 多种数据类型:Elasticsearch支持多种数据类型,包括文本、数字、日期、地理位置等。

  7. 多语言支持:Elasticsearch支持多种语言,包括Java、Python、PHP等。

  8. 数据安全性:Elasticsearch支持数据加密和访问控制,可以保障数据的安全性。

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

什么是倒排索引

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

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

  1. 分词:将文本内容按照一定的规则进行分词,形成一组词语。

  2. 建立索引:对每个词语建立一个索引,索引中包含了该词语出现的文档列表。

  3. 存储位置信息:对于每个文档,记录该词语出现的位置信息,以便后续的检索和排名。

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

  1. 输入查询词语:用户输入要查询的词语。

  2. 查找索引:根据查询词语,在倒排索引中查找对应的文档列表。

  3. 进一步筛选:根据查询词语在文档中出现的位置信息,进一步筛选出符合查询条件的文档。

  4. 返回结果:返回符合条件的文档列表,可以按照相关性进行排序。

倒排索引的优点包括:

  1. 快速查找:倒排索引可以快速地查找包含特定词语的文档,减少了搜索的时间和计算量。

  2. 精确匹配:倒排索引可以实现精确的词语匹配,避免了模糊匹配和错误匹配。

  3. 支持多种查询方式:倒排索引支持多种查询方式,包括全文搜索、短语搜索、通配符搜索、范围搜索等。

  4. 支持高效的排名:倒排索引可以根据词语在文档中出现的位置信息,计算出文档的相关性,从而实现高效的排名。

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

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 的关系:

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

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

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

Logo

基于 Vue 的企业级 UI 组件库和中后台系统解决方案,为数万开发者服务。

更多推荐