java面试准备

redis的哨兵模式

用于主从切换的场景。

通过配置哨兵来监听主服务和从服务器的状态，来进行主从切换。（此处类似于keepalive的逻辑）

但单个哨兵监听也会有单点问题，所以后来出现了多哨兵模式。

多哨兵组成一个集群后，通过投票结果判定redis服务的状态，并将新的master消息通知到所有的从服务器。

redis的持久化机制

redis的持久化机制分为两种：rdb（redis database）和aof（append of file）

rdb可以理解为数据库的快照，可以手动/自动进行快照备份。备份文件是二进制。文件小，恢复快，但不实时。

aof可以理解为mysql的binlog日志。但redis的日志是先写数据，再写日志。日志只是用来备份使用。恢复较慢，逐条语句进行重放。但aof有重写功能，当文件太大，根据当前数据进行重写日志进行文件瘦身。

rdb和aof可以结合使用。

redis 雪崩 穿透 击穿 怎么办

穿透：请求redis不存在的key，查询打到数据库，而数据库也没有，数据库面临全索引扫描。导致数据库瘫痪。解决方案：当数据库也查不到时，在redis设置返回值为空，避免频繁查询数据库；或者使用布隆过滤器。

雪崩：redis大量key同时过期，导致数据库压力过大。解决方案：分开设置key过期时间

击穿：热点数据在过期的瞬间，涌入大量请求导致瞬时大量请求打到数据库；解决方案：对集中式的热点数据构造加互斥锁。

redis的reactor模式

看了一圈还是不太明白。自己理解和NIO的逻辑类似

使用单独的线程处理IO，而redis的内存操作是单线程顺序处理；redis的持久化操作则另起一个线程进行操作。

jvm gc算法 

垃圾回收，回收的是堆和方法区的内存。主要是堆内存。

gc算法包含两个阶段，一个标记，一个清理

标记：根据gcRoot发散下去，寻找跟root相关联的对象。

清理：清理则分为复制（从eden和survival复制到另一个survival区）；清理（直接删除，但会有内存碎片）；整理（整理成连续的内存后进行清理）

CMS中的gc模式是：

1. 首次标记stop the world（包括try catch、for等安全点):用于标记root相关的对象

2. 二次标记并发进行，根据一层关系进行关联分析

3. 检查标记是否有误 stop the world：查看当前并发标记后是否有误 

4. 清理数据。

mysql 锁分类

行锁：行锁分为排他锁X和共享锁S；比如for update就是排他锁。

排他锁和共享锁的逻辑和AQS的处理逻辑类似。排它锁和共享锁互斥，但共享锁和共享锁不互斥。

表锁：分为表锁 和 MDL元数据锁 ；当修改表字段时会加MDL写锁。onlineDDL，先取mdl读锁，同步进行ddl，最后取mdl写锁，进行写入，最后释放锁。

gap锁：gap锁是为了解决rr隔离级别中的幻读的问题。幻读主要出现在一个事务中多次count的场景下。而gap锁则是事务操作中锁住了索引间的间隙。

mvcc

multi version concurrent control

多版本并发控制

事务开启时，会获取到事务id，而当前事务可读的记录是在当前事务id之前的版本记录。

当前事务的操作会记录binlog 和 undolog；

如当前事务提交前，后开启的事务需要读取当前事务修改的数据时，需要使用undolog对数据进行回滚之后才能读取。

所以单个事务处理数据量大且事务时间长，会导致数据库性能下降。

redolog binlog undolog relaylog

WAL 日志先行。为了保证数据安全性，在数据落盘前，先记录操作日志。

binlog和redolog应该都是这个逻辑

不同的是redolog是innodb层记录的写缓存的日志。后续写不下了可以强制落盘清空一波

binlog是server层的操作日志，事务提交后统一append到日志文件中

undolog 用于事务回滚以及mvcc的控制

relaylog 在mysql主从复制中，从库用来重放的日志，实际也是binlog的数据

b-树

amqp 协议 kafka 如何保证顺序
死信队列 roketmq 2pc
并发 线程和进程区别，线程通信，aqs，sync原理

es 分片，索引
aio bio nio

hashmap 扩容机制 
redis 底层数据结构

http 三次握手 四次挥手