Java中高级问题整理-中间件_高级java开发中间件相关知识-CSDN博客

本文链接：https://blog.csdn.net/qwqw3333333/article/details/121093806

本系列目录

文章目录

1. Redis
2. RabbitMQ
- AMQP messaging 中的基本概念
- RabbitMQ如何实现延时队列
3. Kafka
- kafka中的 zookeeper 起到什么作用
- kafka启动了一个broker，可以设置多个partition吗？可以设置多个副本吗？为什么
3. Elasticsearch

1. Redis

Redis集群模式

主从模式：master可读写，slave只读，master宕机后无法提供写服务
哨兵模式：master宕机无需切换数据源，数据量过大之后，达到瓶颈，无法使用，需要分片
集群模式：支持分片，每个分片都是一个主从集群，分片互联，每个分片都可以提供读写服务，分片之间按照规则存储不同数据，相当于以上两种模式的综合体，支持存储大量数据

Redis集群模式

你知道redis哪些高级功能？使用场景？

高级功能：消息队列、过期删除、事务、数据持久化、分布式锁、附近的人、慢查询分析、Sentinel、集群等
使用场景：缓存、排行榜、计数器、分布式会话、分布式锁、社交网络、最新消息、消息系统

Redis如何清理过期key

1. 怎么判断过期？

Redis过期字典保存了所有键的过期时间，通过过期时间和当前时间对比判断是否过期

2. 过期键清理策略

定时删除：设置过期时间的同时设置timer定时器，执行立即删除，对内存友好，对CPU很不友好
惰性删除：读写时判断是否过期，过期就删除，对内存不友好
定期删除：每过一定时间扫描数据库，检查过期键。可以通过控制每次要删除多少过期键，扫描几个数据库来决定对CPU影响。

Redis通过惰性删除和定期删除配合使用来合理利用CPU和内存

2. RabbitMQ

AMQP messaging 中的基本概念

在这里插入图片描述

Broker: 接收和分发消息的应用，RabbitMQ Server就是Message Broker。
Virtual host: 出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。
Connection: publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。
Channel: 如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
Exchange: message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。
Queue: 消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。
Binding: exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。
参考：RabbitMQ与AMQP协议详解

RabbitMQ如何实现延时队列

通过TTL（Time To Live）和DLX(Dead-Letter-Exchange)来实现
为消息添加过期时间，时间过期后进入死信队列，然后重新发布消费，这就做到了误差极小的演示队列
参考-优选，参考-预备

3. Kafka

kafka中的 zookeeper 起到什么作用

broker在zk中注册
kafka的每个broker（相当于一个节点，相当于一个机器）在启动时，都会在zk中注册，，当节点失效时，zk就会删除该节点，就很方便的监控整个集群broker的变化，及时调整负载均衡。
topic在zk中注册
在kafka中可以定义很多个topic，每个topic又被分为很多个分区。一般情况下，每个分区独立在存在一个broker上，所有的这些topic和broker的对应关系都有zk进行维护
consumer(消费者)在zk中注册
1. 注册新的消费者，当有新的消费者注册到zk中，zk会创建专用的节点来保存相关信息，路径ls /consumers/{group_id}/ [ids,owners,offset]
  
  Ids:记录该消费分组有几个正在消费的消费者，
  Owmners：记录该消费分组消费的topic信息，
  Offset：记录topic每个分区中的每个offset
2. 监听消费者分组中消费者的变化
  
  监听/consumers/{group_id}/ids的子节点的变化，一旦发现消费者新增或者减少及时调整消费者的负载均衡

kafka启动了一个broker，可以设置多个partition吗？可以设置多个副本吗？为什么

可以设置多个partition，但是不能设置多个副本。
设置多个partition是为了可以提高性能，设置多个副本是为了提高可用性，但是只有一个broker设置多个副本是没有意义的，所以kafka也不允许副本数多与broker数

3. Elasticsearch

为什么要使用Elasticsearch?

　　因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，可以提高查询速度。

全文搜索(Full-text Search)

全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。

倒排索引（Inverted Index）

与之对应的是普通索引，普通索引是通过单词找到索引再找到文档。倒排索引相反，直接通过单词找到文档列表。
倒排索引组成：

倒排索引项：记录文档id，单词出现次数，位置信息
倒排列表：由倒排索引项组成

通过单词就可以找到倒排列表，倒排列表中倒排索引项记录了单词所有的信息

ES基本概念

索引：Elasticsearch 数据管理的顶层单位就叫做 Index（索引），相当于关系型数据库里的数据库的概念。另外，每个Index的名字必须是小写。
文档（Document）：Index里面单条的记录称为 Document（文档），相当于关系型数据库column。许多条 Document 构成了一个 Index。Document 使用 JSON 格式表示。同一个 Index 里面的 Document，不要求有相同的结构（scheme），但是最好保持相同，这样有利于提高搜索效率。
类型（Type）：Document 可以分组，比如employee这个 Index 里面，可以按部门分组，也可以按职级分组。这种分组就叫做 Type，它是虚拟的逻辑分组，用来过滤 Document，类似关系型数据库中的数据表。
不同的 Type 应该有相似的结构（Schema），性质完全不同的数据（比如 products 和 logs）应该存成两个 Index，而不是一个 Index 里面的两个 Type（虽然可以做到）。
文档元数据（Document metadata）：文档元数据为_index, _type, _id, 这三者可以唯一表示一个文档，_index表示文档在哪存放，_type表示文档的对象类别，_id为文档的唯一标识。