ALL Java 思维导图模板_ProcessOn思维导图、流程图

消息队列

使用目的

解耦

异步

削峰

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性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半<br>

数据预热

提前访问热点数据，让数据存在filesystem中，这样用户访问就快

冷热分离

冷，热数据放不同机器，保证filesystem都是热数据

document模型设计

不要使用复杂的关联查询

分页性能优化

scroll api

缓存 redis

使用原因：高性能，高并发

Reactor模型

redis和memcached有啥区别

Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作

redis官方就是支持redis cluster集群模式的，比memcached来说要更好<br>

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<br>

调用后可以去干别的事情，但需要轮询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动态编译器