ALL Java
2020-10-23 11:22:54 0 举报AI智能生成
java面试知识总结
作者其他创作
大纲/内容
消息队列
使用目的
解耦
异步
削峰
MQ高可用
rabbitmq
不是分布式
单机/集群镜像集群
kafka
天然分布式
replica副本机制（副本存在多台机器上面）
会选举leader,只有leader进行读写
保证不重复消费（幂等性）
kafka 中有一个offset ，这个offset是存在zookeeper里面的，记录上一次消费到哪一个消息
保证消息不丢失
rabbitmq
生产者弄丢数据
事务功能（没有收到就回滚，消耗性能）（同步）
confirm模式 （异步）
成功 回传 ack
失败 回调 nack接口 通知失败
rabbitmq弄丢数据
开启rabbitmq的持久化
创建queue的时候将其设置为持久化
发送消息的时候将消息的deliveryMode设置为2
消费端弄丢数据
ack机制
关闭rabbitmq自动ack，消费端处理完再通知消息队列
kafka
kafka弄丢了数据
topic设置replication.factor参数：这个值必须大于1（有2个副本）
kafka服务端设置min.insync.replicas参数：这个值必须大于1
至少一个follower还跟自己保持联系
producer端设置acks=all
这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
设置了acks=all,生产者就不会有数据丢失的情况了，无效重试
producer端设置retries=MAX（很大很大很大的一个值，失败无限次重试的意思）
消费端弄丢了数据
kafka 的offset会记录消费了的，可以在消费端将信息放入内存队列，并且关闭offset自动提交，改为手动提交
保证顺序消费
rabbitmq
kafka
数据积压
分布式搜索
lucene
倒排索引的原理
elasticsearch
底层其实还是基于lucene的
index -> type -> mapping -> document -> field
shard
primary shard （负责写入数据）
replica shard
NRT(Near Realtime)近实时
分布式搜索引擎的架构
ES读写原理
写
读
搜索数据过程
写原理（难）
过程
写入buffer（搜索不到的）
buffer，满时，执行reflush os cache-->segment file
buffer中的数据被refresh操作，刷入os cache中，就代表这个数据就可以被搜索到
写入translog日志文件,持久化
大到一定程度，会触发commit操作
NRT，near real-time
（数十亿级别）如何提高查询效率
性能优化的杀手锏——filesystem cache
filesystem cache更多的内存
让es性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半
数据预热
提前访问热点数据，让数据存在filesystem中，这样用户访问就快
冷热分离
冷，热数据放不同机器，保证filesystem都是热数据
document模型设计
不要使用复杂的关联查询
分页性能优化
scroll api
缓存 redis
使用原因：高性能，高并发
Reactor模型
redis和memcached有啥区别
Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作
redis官方就是支持redis cluster集群模式的，比memcached来说要更好
redis线程模型
文件事件处理器（单线程）
多个socket
IO多路复用程序
文件事件分派器
事件处理器
连接应答处理器
AE_READABLE事件
命令请求处理器
命令回复处理器
AE_WRITABLE事件
redis数据类型
redis过期策略
设置过期时间
定期删除+惰性删除
内存淘汰
noeviction
内存不足，插入报错
allkeys-lru
所有值进行LRU缓存淘汰（最常用）
allkeys-random
随机干掉一个
volatile-lru
（随机）在指定了缓存失效的值中进行LRU缓存淘汰
volatile-random
所有值进行LRU缓存淘汰，随机干掉
volatile-ttl
所有值进行LRU缓存淘汰，更早时间干掉
手写LRU
redis高可用
redis replication（主从复制）
开启master node的持久化
RDB （Redis DataBase）
优缺点
缺点：非实时，完整性和一致性不高，新开一个线程，占内存
优点：适合大规模数据恢复
copy-on-write
AOF (Append Only File)
缺点：占空间，多余，记录的内容多，文件会越来越大，数据恢复也会越来越慢
优点： 数据的完整性和一致性更高
完整流程
主从架构
全量备份（full resysnchronization）
当slave node第一次连接master node 的时候触发
rdb save
主从复制的断点续传
backlog
无磁盘化复制
过期key处理
集合类
CopyOnWriteArrayList
doubbo
序列化 hessian
笔记
负载均衡策略
分布式事务
两阶段提交方案/XA方案
TCC方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案
网络基础
netty
BIO/NIO/AIO
同步阻塞BIO
调用后需要阻塞等待
同步非阻塞NIO
调用后可以去干别的事情，但需要轮询IO状态，询问操作系统那些IO有数据 select/poll
异步非阻塞AIO
调用后可以去干其他事情，操作系统会通知状态 epoll
io多路复用/select/poll/epoll
如何解决粘包以及拆包
7层网络模型
物理层（电缆）
4层模型
数据链路层（以太网协议，定义了那几个0101为同一部分（帧），指定目标mac）
网络层(ip，数据链路层只能进行广播在局域网，如果要去到其他局域网，就需要ip了)
传输层(规定端口号，tcp/udp)
应用层 (规定数据格式 http协议)
会话层
表示层
三次握手，四次挥手
握手
客户端发送带有SYN数据包到服务端
服务端发送带有SYN/ACK标志的数据包到客户端
客户端发送带有ACK标志的数据包给服务端
挥手
客户端发送一个FIN,用来关闭客户端到服务端的数据传送
服务端收到这个FIN，会发回一个确认的ACK，确认序号为收到的序号加1,和SYN一样，一个FIN将占用一个序号
服务端-关闭与客户端的连接，发送一个FIN给客户端
客户端-发回ACK报文确认，并将缺序号设置为收到序号加1
mysql
数据库事务（ACID）
读未提交
读已提交（不可重复读）
可重复读（mysql默认级别）
实现方式（MVCC） 版本并发控制
幻读
串行化
数据库锁
myisam
表锁
查询加共享锁（只允许读）（表共享锁）
写时加入互斥锁（不允许读写）（表独占锁）
innodb
行锁
排它锁(x)
一个事务可以写这行数据，别的事务只能读，不能写
共享锁(s)
多个事务可以加共享锁读同一行数据，但别的事务不能写这行数据
表锁 （innodb引擎自动加的）
意向排他锁
给某行加排他锁的时候，必须先给表加排它锁
意向共享锁
加共享行锁时，必须加这个共享表锁
乐观锁
手动加个版本号，设置的时候检查版本号
悲观锁
for update(尽量少用，会发生死锁)
系统文件层
日志文件
错误日志 Error log
通用查询日志 General query log
二进制日志 binary log
慢查询日志 Slow query log
数据文件
db.opt 文件
frm 文件
MyISAM
MYD 文件
MYI 文件
InnoDB
ibd文件和 IBDATA 文件
MySQL日志系统原理
Undo Log
实现事务的原子性
Redo Log和Binlog
spring源码
并发编程
可见性，有序性硬件底层
可见性
MESI
flush处理器缓存
reflush处理器缓存
总线（bus）
volatile保证可见性原理
可见性两种情况
处理器1强制从处理器2的高速缓存中读
处理器2强制刷数据到主内存，同时失效了处理器1的数据，这时处理器1会去主内存中拿数据
不是原子性的操作
i++
i = y+1
i = x*y
有序性
javac静态编译器
JIT动态编译器
0 条评论
下一页
