java面试刷题------中间件

最新推荐文章于 2024-05-10 08:11:50 发布

Fuly1024

最新推荐文章于 2024-05-10 08:11:50 发布

阅读量1.6k

点赞数 1

分类专栏：面试刷题文章标签： JAVA

本文链接：https://blog.csdn.net/xy3233/article/details/97004207

版权

面试刷题专栏收录该内容

39 篇文章 0 订阅

订阅专栏

Redis支持的数据类型？
string（字符串） list（列表） set（集合） hash（hash） zset(有序集合)
redis 持久化有几种方式？
持久化方式：快照（RDB）写日志(AOF)
Redis集群方案什么情况下会导致整个集群不可用？
有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。
说说Redis哈希槽的概念？
Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。
redis 是什么？都有哪些使用场景？
缓存数据库可用于缓存 ,计数器 , 队列 ,
redis为什么那么块
1, Redis是纯内存数据库，
2, 再说一下IO，Redis使用的是NIO，IO多路复用，
3, 单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。
4, Redis全程使用hash结构，读取速度快
5, Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。
redis 支持的 java 客户端都有哪些？
Redisson,Jedis等等，官方推荐使用Redisson。
zset底层原理
skipList
Redis过期键删除策略
定时删除: 在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除
惰性删除: key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
定期删除: ：每隔一段时间执行一次删除过期key操作
什么是缓存穿透？怎么解决？
访问一个不存在的key，缓存不起作用，请求会穿透到DB，流量大时DB会挂掉。
解决方案:
(1)采用布隆过滤器，使用一个足够大的bitmap，用于存储可能访问的key，不存在的key直接被过滤；
(2)访问key未在DB查询到值，也将空值写进缓存，但可以设置较短过期时间。
缓存雪崩怎么处理?
大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。
解决方案
可以给缓存设置过期时间时加上一个随机值时间，使得每个key的过期时间分布开来，不会集中在同一时刻失效。
一个字符串类型的值能存储最大容量是多少？
答：512M
Redis常见性能问题和解决方案：
1、Master最好不要写内存快照，如果Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务
2、如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一
3、为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网
4、尽量避免在压力很大的主库上增加从
5、主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。
Jedis与Redisson对比有什么优缺点？
答：Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持；Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。
Redis集群最大节点个数是多少？
答：16384个。
redis 淘汰策略有哪些？
答：Redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。
相关知识：Redis提供6种数据淘汰策略：
volatile-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据,报错
redis常见性能问题和解决方案?
1, Master写内存快照,save命令调度rdbSave函数,会阻塞主线程工作, 当快照比较大时对性能的影响会很大解决方案: Master不要写内存快照
2, Master 写日志(AOF)持久化,如果步重写AOF文件,这个持久化方式对性能的影响时最小的,但是AOF文件会不断增大,文件过大会影响Master重启恢复的速度; 解决方案:Master最好不要做任何持久化工作，包括内存快照和AOF日志文件,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3, Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
4, Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内
怎么保证缓存和数据库数据的一致性？
出现问题的原因: 由于操作缓存与操作数据库不是原子的，非常有可能出现执行失败。
解决方案大概有以下几种：
1, 对删除缓存进行重试，数据的一致性要求越高，我越是重试得快。
2, 定期全量更新，简单地说，就是我定期把缓存全部清掉，然后再全量加载。
3, 给所有的缓存一个失效期。
redis 如何做内存优化？
1, 尽量使用短的key
2, 避免使用keys *
3,在存到Redis之前先把你的数据压缩下
4, 设置 key 有效期
使用RabbitMQ有什么好处？
1.解耦，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！
2.异步，将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度
3.削峰，并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常
RabbitMQ 上的一个 queue 中存放的 message 是否有数量限制？
答：可以认为是无限制，因为限制取决于机器的内存，但是消息过多会导致处理效率的下降。
如何解决丢数据的问题?
1.生产者丢数据
RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。
transaction机制就是说，发送消息前，开启事物(channel.txSelect())，然后发送消息，如果发送过程中出现什么异常，事物就会回滚(channel.txRollback())，如果发送成功则提交事物(channel.txCommit())。然而缺点就是吞吐量下降了。生产上用confirm模式的居多。一旦channel进入confirm模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。
2.消息队列丢数据
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。
3.消费者丢数据
启用手动确认模式可以解决这个问题
如何避免消息重复投递或重复消费？
MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重和幂等的依据（消息投递失败并重传），避免重复的消息进入队列；
在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重和幂等的依据，避免同一条消息被重复消费。
rabbitmq 有哪些重要的角色？
RabbitMQ 中重要的角色有：生产者、消费者和代理：
生产者：消息的创建者，负责创建和推送数据到消息服务器；
消费者：消息的接收方，用于处理数据和确认消息；
代理：就是 RabbitMQ 本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。
rabbitmq 有哪些重要的组件？
ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。
Channel（信道）：消息推送使用的通道。
Exchange（交换器）：用于接受、分配消息。
Queue（队列）：用于存储生产者的消息。
RoutingKey（路由键）：用于把生成者的数据分配到交换器上。
BindingKey（绑定键）：用于把交换器的消息绑定到队列上
rabbitmq 集群有什么用？
集群主要有以下两个用途：
高可用：某个服务器出现问题，整个 RabbitMQ 还可以继续使用；
高容量：集群可以承载更多的消息量。
rabbitmq 有几种广播类型？ (4种)
直连交换机（direct exchange）(默认): 它会把消息路由到BindingKey与RoutingKey完全匹配的队列中。
主题交换机（Topic）: 是direct上的扩展，同样是利用RoutingKey与BindingKey相匹配，但是匹配规则不一样，支持模糊匹配,可以将一条消息发送给指定的多个队列上。
扇型交换机（funout exchange）: 它会把交换器上的所有消息发送给绑定在自己身上的队列中，不需要BindingKey生效
头交换机（headers） :首部交换机是忽略routing_key的一种路由方式。路由器和交换机路由的规则是通过Headers信息来交换的，这个有点像HTTP的Headers。这种交换器性能会很差，一般不会使用。
zookeeper 是什么？
zookeeper=文件系统+监听通知机制。
ZAB协议？
ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。
ZAB协议包括两种基本的模式：崩溃恢复和消息广播
当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的Leader服务器，然后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。
zookeeper 都有哪些功能？
维护配置信息，命名，提供分布式同步和提供组服务。
Zookeeper有哪几种节点类型
持久：创建之后一直存在，除非有删除操作，创建节点的客户端会话失效也不影响此节点。
持久顺序：持久节点名后缀加上一个10位数字。
临时：创建客户端会话失效（注意是会话失效，不是连接断了），节点也就没了。不能建子节点。
临时顺序：临时节点名后缀加上一个10位数字。
zookeeper 怎么保证主从节点的状态同步？
zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 zab 协议。
zab 协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。
当服务启动或者在领导者崩溃后，zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。
状态同步保证了 leader 和 server 具有相同的系统状态。
说一下 zookeeper 的通知机制？
客户端端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知，然后客户端可以根据 znode 变化来做出业务上的改变。
Zookeeper集群角色
，根据其身份特性分为leader、follower、observer。
leader负责客户端writer类型的请求；
follower负责客户端reader类型的请求，并参与leader选举；
observer是特殊的follower，可以接收客户端reader请求，但是不会参与选举，可以用来扩容系统支撑能力，提高读取速度。
Dubbo是什么？
一款微服务服务框架 ,高性能和透明化的RPC远程服务调用方案.他与SpringCloud的区别就是，他支持多种协议，而SpringCloud只支持Http协议。
默认使用的是什么通信框架，还有别的选择吗?
默认也推荐使用netty框架，还有mina。
服务调用是阻塞的吗？
默认是阻塞的，可以异步调用，没有返回值的可以这么做。
使用什么序列化框架，你知道的还有哪些？
默认使用Hessian序列化，还有Duddo、FastJson、Java自带序列化。
服务提供者能实现失效踢出是什么原理？
服务失效踢出基于zookeeper的临时节点原理。
当一个服务接口有多种实现时怎么做？
当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。
服务上线怎么兼容旧版本？
可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。
Dubbo的管理控制台能做什么？
管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。
dubbo推荐用什么协议？
默认使用dubbo协议。
集群容错怎么做？ dubbo容错模式有四种
1、Failover Cluster(默认)
失败自动切换，当出现失败，重试其它服务器。(缺省)
通常用于读操作，但重试会带来更长延迟。
2、Failfast Cluster
快速失败，只发起一次调用，失败立即报错。
通常用于非幂等性的写操作，比如新增记录。
3、Failsafe Cluster
失败安全，出现异常时，直接忽略。
通常用于写入审计日志等操作。
4、Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。
通常用于消息通知操作。
5、Forking Cluster
并行调用多个服务器，只要一个成功即返回。
通常用于实时性要求较高的读操作，但需要浪费更多服务资源。