java面试

它是一个几乎无状态节点，可集群部署，节点之间无任何信息同步

Broker分为Master与Slave

一个Master可以对应多个Slave，但是一个Slave只能对应一个Master

Master与Slave的对应关系通过指定相同的BrokerName

BrokerId为0表示Master，非0表示Slave

每个Broker与Name Server 集群中的所有节点建立长连接，
定时注册Topic信息到所有Name Server。

Consumer与Name Server集群中的其中一个节点
（随机选择，但不同于上一次）建立长连接

定期从Name Server 取Topic路由信息

向提供Topic服务的Master、Slave建立长连接

定时向Master、Slave发送心跳

Producer 与Name Server集群中的其中一个节点
（随机选择，但不同于上一次）建立长连接

定期从Name Server取Topic路由信息

向提供Topic服务的Master建立长连接

且定时向Master发送心跳

数据以Protobuf形式放入到消息队列中

公司不定期会有新的定制设备需要推送数据

这样新的设备就可以从消息队列订阅数据

不需要更改原推送代码

其中有一次 一次性要给几十万台设备推送消息

要是同步一条条去推送，那要等多久才能完成，最后推送的设备很久才能收到消息

如果使用了消息队列，我就可以把消息都放到多个mq中，
可以同时从多个消息队列中消费，大大提高了推送时间

引入外部依赖越多，系统越容易挂掉

加个MQ进来，你考虑消息重复、丢失、传输顺序等问题

如果向多个系统写入数据，其中某个失败了，怎么保证这些系统的一致性

普通集群模式

镜像集群模式

如何开启这个镜像集群模式

kafka8.0后，提供了HA 机制（副本机制）

每个 partition 的数据都会同步到其它机器上，形成自己的多个副本（replica ）

副本（replica ）会选举一个 leader 出来，其他 副本 就是 follower

当leader挂掉时，从follower中重新选举出leader，读和写只由leader负责，follower只用来备份数据

在写的时候，leader 会负责把数据同步到所有 follower 上去

需要让生产者发送每条数据的时候，里面加一个全局唯一的 id

先根据这个 id 去比如 Redis 里查一下，如果存在跳过消费，如果不存在，消费并将id写入redis

消息传入MQ过程中丢失

解决方案

MQ挂掉还没消费的消息会丢失

解决方案

消费者消费消息的过程中挂掉，导致消息丢失

解决方案

场景1

场景2

场景

在消费者处可以把消息写入多个内存queue，
需要顺序执行的消息写入同一个queue
然后N个线程分别消费一个内存queue

把需要顺序执行的消息放入同一个queue中，然后一个queue对应一个消费者去消费

先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉

新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量

然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，
消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue

接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据

等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息

写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去

一个索引有多个分片，每个分片都是一个Lucene的索引

如果一个索引的数据量很大，比如图书索引数据量太大，
硬盘压力大，就可以创建多个分片

拷贝一份分片就完成了分片的备份，除了主分片挂掉以后备份，还可以分担搜索的压力。

分片只能在创建索引的时候指定

备份可以后期动态修改

此即为切词，或分词。

一次I/O读写的过程

I/O操作一般分为两个阶段

在等待I/O准备就绪阶段，线程阻塞，等待磁盘就绪，
此时操作系统可以将这个空闲的CPU核心用于服务其他线程

但redis是基于内存，不涉及I/O操作，
使用多线程不仅不能提高效率，而且多线程上下文切换还需要耗费时间

内存大小

网络带宽

普通的 set 和 get

类似 map 的一种结构

hset person name bingo
hset person age 20
hset person id 1
hget person name

有序列表

lpush mylist 1
lpush mylist 2
lpush mylist 3 4 5
# 1
rpop mylist

无序集合，自动去重

排序的 set，去重但可以排序，写进去的时候给一个分数，自动根据分数排序。

redis默认每隔100ms就随机抽取一些设置了过期时间的key，
检查其是否过期，如果过期就删除

过期的key如果没有被定期删除删掉，当你再次获取这个key时，
redis会检查是否过期，过期则删除key，不返回任何东西

当内存不足以容纳新写入数据时，新写入操作会报错

当内存不足以容纳新写入数据时，
在键空间中，移除最近最少使用的key

最常用

当内存不足以容纳新写入数据时，
在键空间中，随机移除某个key

当内存不足以容纳新写入数据时，
在设置了过期时间的键空间中，
移除最近最少使用的key

当内存不足以容纳新写入数据时，
在设置了过期时间的键空间中，
随机移除某个key

当内存不足以容纳新写入数据时，
在设置了过期时间的键空间中，
有更早过期的时间的key优先移除

概括

特点

注意

叫做 failover 故障转移，也可以叫做主备切换

基于哨兵的高可用

新收到的命令缓存在内存中

挂掉重连后，接着上次复制的地方，继续复制下去

master node 会在内存中维护一个 backlog

master 和 slave 都会保存一个 replica offset 还有一个 master run id

如果 master 和 slave 网络连接断掉了，
slave 会让 master 从上次 replica offset 开始继续复制

没有找到对应的 offset，那么就会执行一次 resynchronization

负责监控 redis master 和 slave 进程是否正常工作

如果某个 redis 实例有故障，
那么哨兵负责发送消息 作为报警通知 给管理员

如果 master node 挂掉了，会自动转移到 slave node 上

如果故障转移发生了，通知 client 客户端新的 master 地址

经典的 3 节点哨兵集群

需要 >=majority（majority=voters/2+1），
也就是大多数哨兵都是运行的，才能执行故障转移

sdown

odown

通过 redis 的 pub/sub 系统实现

每个哨兵都会往 __sentinel__:hello 这个 channel 里发送一个消息

所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在

情况

解决办法

每隔一段时间生成一次全量的数据快照

特点

对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中

在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建数据集

特点

事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃

事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。

事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

从数据库中只要没查到，就写一个空值到缓存里去

下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

将热点数据设置为永远不过期；或者基于 redis or zookeeper 实现互斥锁，
等待第一个请求构建完缓存之后，再释放锁

读的时候，先读缓存，缓存没有的话，就读数据库，
然后取出数据后放入缓存，同时返回响应

更新的时候，先更新数据库，然后再删除缓存

读请求和写请求串行化，串到一个内存队列里去

先更新数据库，再删除缓存。

如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据

数据就出现了不一致。

先删除缓存，再更新数据库。

数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改

一个请求过来，去读缓存，发现缓存空了，去查询数据库，
查到了修改前的旧数据，放到了缓存中

随后数据变更的程序完成了数据库的修改，数据库和缓存中的数据不一样了

更新数据的时候，将相同唯一标识的数据操作放入一个队列中执行

一个队列对应一个工作线程，这样就能保证一个数据读写顺序

读超时的问题

高性能：NGINX 以其高并发处理能力和低资源占用著称，适用于高流量网站和应用。
灵活性：支持多种负载均衡算法（如轮询、最小连接数、IP 哈希等）和丰富的配置选项。
反向代理功能：除了负载均衡，NGINX 还能作为反向代理、静态文件服务器和缓存服务器。
模块化设计：支持各种第三方模块，功能扩展性强。
广泛应用：有丰富的社区资源和文档，易于获取支持和解决方案。

复杂性：配置文件较为复杂，需要一定的学习曲线。
缺少原生健康检查：虽然可以通过配置进行健康检查，但没有 HAProxy 那样灵活和强大。

高性能：同样以高性能和低资源消耗著称，适用于高并发场景。
灵活性：提供多种负载均衡算法和高级的健康检查功能，支持 TCP 和 HTTP 多层负载均衡。
透明代理：支持透明代理模式，可以保留客户端的真实 IP 地址。
详细监控：内置监控界面，提供丰富的统计信息，便于管理和调试。
稳定性：多年发展积累了大量的生产环境经验和优化，稳定性高。

配置复杂：需要较高的配置技巧，配置文件较为复杂。
功能单一：专注于负载均衡和代理，不具备 NGINX 那样丰富的功能（如反向代理和静态文件服务）

收费

在准备阶段，协调者向所有参与者发送准备请求，并等待所有参与者的响应。只有在收到所有参与者的响应后，协调者才会决定提交或回滚事务，并向所有参与者发送相应的请求。期间，协调者处于阻塞状态，无法处理其他请求

在提交阶段，协调者向所有参与者发送提交请求，并等待所有参与者的响应。只有在收到所有参与者的提交成功响应后，协调者才会确认事务提交。如果有任何一个参与者未能提交事务，协调者将向所有参与者发送回滚请求。期间，协调者同样处于阻塞状态，无法处理其他请求。

协调者向所有参与者发送 CanCommit 请求，询问它们是否可以提交事务。参与者在收到请求后，会检查自己是否可以执行事务，并在准备好后向协调者发送 Ready 或 Abort 响应。如果所有参与者都准备好了，则协调者会向所有参与者发送 DoCommit 请求，否则会向所有参与者发送 DoAbort 请求。

协调者收到所有参与者的 Ready 响应后，会向所有参与者发送 PreCommit 请求，告知它们即将提交事务。参与者收到 PreCommit 请求后，会进入预提交状态，并在事务提交前执行一些准备工作，如持久化日志。如果有任何一个参与者在超时时间内未响应或者发送了 Abort 响应，则协调者会向所有参与者发送 DoAbort 请求。

在收到所有参与者的 Ack 响应后，协调者会向所有参与者发送 DoCommit 请求，要求它们正式提交事务。参与者收到请求后，会执行事务提交操作，并在提交成功后向协调者发送 Ack 响应。协调者收到所有参与者的 Ack 响应后，确认事务提交，并向所有参与者发送确认消息。如果有任何一个参与者在超时时间内未响应，则协调者会向所有参与者发送 DoAbort 请求。

验证

准备

解析

b+树

很多时候用 exists 代替 in 是一个好的选择：

分表能够解决单表数据量过大带来的查询效率下降的问题

分库详细策略

每个代理类只能为一个接口服务

通过一个代理类完成全部的代理功能

volatile关键字的作用是：保证变量的可见性

volatile轻量级，只能修饰变量；synchronized重量级，还可修饰方法。

volatile不会造成线程的阻塞，而synchronized可能会造成线程的阻塞。

具体实现细节

乐观锁是一种思想。CAS是这种思想的一种实现方式

不可重入锁和可重入锁

阻塞队列

Executors类里面提供了一些静态工厂

1、设置关键参数

2、根据处理的任务类型选择不同的阻塞队列

3、创建自己的 ThreadFactory

4、然后就可以创建线程池了

两种提交任务的方法（ExecutorService提供）

关闭线程池