java知识体系思维导图模板_ProcessOn思维导图、流程图

mysql

事务

事务的基本特性（acid）

原子性：同一个事务中的sql操作，要么全部成功，要么全部失败

一致性：事务将数据库从一种状态转变为下一种一致的状态

隔离性：一个事务的未提交操作对于其他事务是不可见的状态

持久性：一个事务执行完成，数据会永久保存在数据库中

并发事务带来的问题

更新丢失：t1读取库存十条,t2读取库存十条,t1,t2同时对十这个库存进行减少操作（外部加锁解决）

脏读：一个事务读到了另一个事务未提交的数据

不可重复读：t1读到数据a，t2对数据a进行修改，
t1读到的数据为t2修改后的数据

幻读：t1第一次读到一条数据，t2新增一条数据,t1再次读读到了两条数据（和第一次不同）

事务的隔离级别

读未提交：一个事务读到另一个事务未提交的数据、

读已提交：一个事务读到另一个事务已经提交的数据

可重复读：一次事务开始之后，无论读取多少次，读到的数据都是相同的

可串行化：一个事务执行之后，下一个事务才能开始执行

不同隔离级别带来的问题

事务的七种传播行为（spring）

Propagation.REQUIRED（default）：如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务。

Propagation.SUPPORTS：如果当前存在事务，则加入该事务；如果当前不存在事务，则以非事务的方式继续运行。

Propagation.MANDATORY：如果当前存在事务，则加入该事务；如果当前不存在事务，则抛出异常。

Propagation.REQUIRES_NEW：重新创建一个新的事务，如果当前存在事务，延缓当前的事务。

Propagation.NOT_SUPPORTED：以非事务的方式运行，如果当前存在事务，暂停当前的事务。

Propagation.NEVER：以非事务的方式运行，如果当前存在事务，则抛出异常。

Propagation.NESTED：如果没有，就新建一个事务；如果有，就在当前事务中嵌套其他事务。

存储引擎

innodb

主键索引结构

非主键索引结构

myisam

索引结构

innodb 和 myisam的区别

1. InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；

2. InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；

3. InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。
MyISAM是非聚集索引，也是使用B+Tree作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

4. InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快（注意不能加有任何WHERE条件）；

5. Innodb不支持全文索引，而MyISAM支持全文索引，在涉及全文索引领域的查询效率上MyISAM速度更快高；PS：5.7以后的InnoDB支持全文索引了

6. MyISAM表格可以被压缩后进行查询操作

7. InnoDB支持表、行(默认)级锁，而MyISAM支持表级锁

8、InnoDB表必须有唯一索引（如主键）（用户没有指定的话会自己找/生产一个隐藏列Row_id来充当默认主键），而Myisam可以没有

9、Innodb存储文件有frm、ibd，而Myisam是frm、MYD、MYI

Innodb：frm是表定义文件，ibd是数据文件

Myisam：frm是表定义文件，myd是数据文件，myi是索引文件

索引

概念用途：用于高效获取数据的一直方式

匹配规则：最左匹配原则

索引结构：

b+tree

hash

hash索引和btree索引的区别：

hash索引不支持排序，范围查询

hash索引存在hash碰撞问题

hash索引不支持联合索引最左匹配原则

hash索引等值查询效率高于btree

锁

表/行锁

表锁：粒度大，开销小

行锁：粒度小，开销大，并发高

乐观/悲观锁

悲观锁：并发低，需要锁等待

乐观锁：并发控制，一个数据多个版本（cas 版本号）

读/写锁

读锁（共享锁）：阻塞写，不阻塞读

写锁（排他锁）：阻塞写，阻塞读

间隙锁

要避免幻读可以用间隙锁在Session_1下面执行update account set name =
'zhuge' where id > 10 and id <=20;，则其他Session没法在这个范围所包含的
间隙里插入或修改任何数据

mvvc（多版本并发控制）：维持一个数据的多个版本，使得读写操作没有冲突

log

二进制日志(binlog)

作用：用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步；用于数据库的基于时间点的还原
什么时候产生：事务提交的时候，一次性将事务中的sql语句或者是修改过后的语句按照一定的格式记录到binlog中
什么时候释放：由参数expire_logs_days决定

重做日志(redo log)

作用：当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，如果这个时候发生非正常的DB服务重启，那么这些数据还没在内存，并没有同步到磁盘文件中（注意，同步到磁盘文件是个随机IO），也就是会发生数据丢失，所以在重启mysql服务的时候，可以根据redo log进行重做，从而达到事务的持久性
内容：物理日志，即记录修改后的数据行
什么时候产生：事务开始之后产生redo log
什么时候释放：当对应事务的脏页写入到磁盘之后，redo log即可被覆盖

回滚日志(undo log)

作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读(MVCC)
内容：物理日志，修改前的数据行
什么时候产生：事务开始之前，将当前版本生成undo log，undo也会产生redo来保证undo log的可靠性
什么时候释放：当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间

高可用

分表

主从

主从复制

binlog线程：负责将主服务器上的数据写入二进制日志中

i/o线程：复制从主服务器上读取二进制日志，并写入从服务器的中继日志（replay log）

sql线程：夫妇在读取中继日志，解析出主服务器已经执行的数据更改并在从服务器中重放（replay）

读写分离

延时怎么办

sem-sync：半同步

并行复制

实时性要求高的强制走主库

写完加缓存

Redis

基础

为什么要用：基于内存，高性能，高并发

为什么这么快

基于内存操作

非阻塞io多路复用

单线程，避免多线程频繁上下文切换

redis和memcached的区别

redis数据类型更多

redis官方支持集群

redis单线程

线程模型

数据类型

字符串

list

set

hash

zset有序集合

bitmap（位图）

计算用户登录次数

scan:遍历key，不会阻塞线程

高级

持久化

rdb（二进制）

开启rdb：save 60 1000

save同步

save 60 1000 60s操作1000次自动保存

bgsave异步

aof

什么是aof：AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中

开启aof：# appendonly yes

aof三种模式

appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非
常安全

appendfsync everysec：每秒 fsync 一次，足够快（和使用 RDB 持久化差不多），并且在
故障时只会丢失 1 秒钟的数据。

appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒 fsync 一次，这种 fsync 策略可以兼顾速度和安全性。

aof重写

什么事aof重写：AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件

aof重写的三种方式

# auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本
来就很快，重写的意义不大

# auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重
写

入redis客户端执行命令bgrewriteaof重写AOF

AOF重写redis会fork出一个子进程去做，不会对redis正常命令处理有太多影响

rdb/aof混合

开启混合持久化：aof-use-rdb-preamble yes

AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将
重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一
起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改
名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的
AOF 全量文件重放，因此重启效率大幅得到提升。

混合持久化AOF文件结构

高可用

主从

结构

主从复制(全量复制)

主从复制(部分复制)

哨兵

结构

选举机制：

缺点：master主节点挂了，哨兵会选举主节点（选举期间，redis会停止对外的服务）

集群

结构

数据分配原理：
Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点
中。
槽位定位算法：
Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体
槽位。
HASH_SLOT = CRC16(key) mod 16384

选举机制：

群是否完整才能对外提供服务：当redis.conf的配置cluster-require-full-coverage为no时，表示当负责一个插槽的主库下线且没有相应的从库进行故
障恢复时，集群仍然可用，如果为yes则集群不可用。

Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

缓存设计

缓存击穿

什么是缓存击穿？缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

解决方案：
设置热点数据永远不过期。
加互斥锁，互斥锁参考代码如下：

缓存失效

什么是缓存失效？由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大
甚至挂掉

解决方案：
对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同
时间。

缓存穿透

什么是缓存穿透？缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

解决方案：
1.接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
2.从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
3.使用布隆过滤器

缓存雪崩

什么是缓存雪崩？缓存雪崩指的是缓存层支撑不住或宕掉后，流量会像奔逃的野牛一样，打向后端存储层。
由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不能提供服务(比如超大并
发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下
降)，于是大量请求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。

解决方案：
1）保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
2）依赖隔离组件为后端限流并降级。比如使用Hystrix限流降级组件。
3）提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基
础上做一些预案设定。

分布式

分布式锁setnx

锁释放放在finally中

服务直接被kill 或者服务器宕机锁永远释放不了

加定时key失效时间

redisson实现

jvm

jvm类加载机制

类加载过程

加载

验证

准备

解析

初始化

使用

退出

类加载器

引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等

扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包

应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类

自定义加载器：负责加载用户自定义路径下的类包

双亲委派机制

什么是双亲委派：双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

打破双亲委派机制：
自己的classLoader实继承ClassLoader重写类加载方法（loadClass(String name, boolean resolve)），实现自己的加载逻辑，不委派给双亲加载

为什么要设计双亲委派机制？
沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改
避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性

jvm调优

JVM整体结构及内存模型

逃逸分析

什么是逃逸分析？

基于逃逸分析的优化（不逃逸的好处）

JVM内存分配与回收

分配

1.1 对象优先在Eden区分配

1.2 大对象直接进入老年代

1.3 长期存活的对象将进入老年代

1.4 对象动态年龄判断

1.5 Minor gc后存活的对象Survivor区放不下

1.6 老年代空间分配担保机制

1.7 Eden与Survivor区默认8:1:1

回收

1 引用计数法

2 可达性分析算法

常见引用类型

强引用

软引用

弱引用

虚引用

如何判断一个类是无用的类？

垃圾收集算法

标记-清除算法

复制算法

标记整理算法

分代收集算法

垃圾收集器

Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)

ParNew收集器(-XX:+UseParNewGC)

Parallel Scavenge收集器(-XX:+UseParallelGC(年轻代),-
XX:+UseParallelOldGC(老年代))

CMS收集器(-XX:+UseConcMarkSweepGC(old))

收集过程

初始标记：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快；

并发标记：同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段
结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新
引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引
用更新的地方。

重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记
产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍
长，远远比并发标记阶段时间短

并发清理：开启用户线程，同时GC线程开始对未标记的区域做清扫

优点

并发收集、低停顿。

缺点

对CPU资源敏感（会和服务抢资源）；
无法处理浮动垃圾(在并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理
了)；
它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然
通过参数-XX:+UseCMSCompactAtFullCollection 可以让jvm在执行完标记清除后再做整
理
执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触
发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回
收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the
world，用serial old垃圾收集器来回收

三色标记算法

G1收集器(-XX:+UseG1GC)

G1垃圾收集器jvm堆内存结构

G1内存划分

G1收集器一次GC的过程

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用
的对象，速度很快；

并发标记（Concurrent Marking）：同CMS的并发标记

最终标记（Remark，STW）：同CMS的重新标记

筛选回收（Cleanup，STW）

G1被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点：

并行与并发

分代收集

空间整合

可预测的停顿

G1垃圾收集分类

YoungGC

MixedGC

Full GC

G1垃圾收集器优化建议

并发

计算机组成原理

早期冯诺依曼计算机

结构

生活例子

销售部门应该直接从仓库拿货，减少生成生产部门的压力，提供效率

缺点：以运算器为中心（输入/输出设备与存储器直接的数据传输通过运算器完成【效率降低】）

现代计算机

结构

简化结构

多核cpu缓存架构

结构图

缓存一致性协议

m修改

e 独享，互斥

s 共享

i 失效

缓存一致性协议失效：
1.如果缓存长度大于一个缓存行，加总线锁
2.cpu并不支持缓存一致性mesi协议

JMM模型

什么是JMM？

为什么有jmm模型？

如何理解JMM模型

Java内存模型与硬件内存架构的关系

结构

JVM和JMM

volatile

会触发总线嗅探机制(更新把主内存的变量最新值更新工作内存)

什么是volatile？

作用

volatile缓存可见性实现原理

Java内存模型内存交互操作

1.lock(锁定)

2.read(读取)

3.load(载入)

4.use(使用)

5.assign(赋值)

6.store(存储)

7.write(写入)

8.unlock(解锁)

内存屏障

volatile会在底层添加内存屏障来禁止指令重排

volatile多并发高可能产生总线风暴

加了volatile 才会触发mesi协议

锁

显示/隐示锁

隐示锁

Synchronized

被Synchronized包裹的代码依然会发生指令重排

可重入锁，非公平锁

什么是Synchronized

原理

加锁方式

JVM加锁过程

每个对象都有一个自己的Monitor(监视器锁)

与Redisson分布式锁实现类似,Redisso自旋争夺锁资源，且Redisson也是可冲重入锁

对象的内存结构

对象一定存在堆区吗？

锁的粗化

锁的消除

JVM内置锁优化升级过程

无锁

偏向锁

轻量级锁

重量级锁

显示锁

ReentantLok

原理

可重入锁

结构图

非公平锁

公平锁

同步队列

条件队列

乐观锁/悲观锁

CAS

比较和交换,用Unsafe类

会带来ABA问题，加版本号解决

AQS

线程池

什么时候使用线程池？

为什么用线程池？

线程池优势

原理图

行为

execute（Runnable command）

submit（task）

shutdown（）

shutdownNow（）

isTerminated（）

isShutdown（）

五种状态

RUNNING

SHUTDOWN

STOP

TIDYING

TERMINATED

mq

RabbitMq

优势

应用解耦

异步提速

削峰填谷

劣势

系统可用性降低

系统复杂度提高

五种工作模式

简单模式 HelloWorld

工作队列模式 Work Queue

发布订阅模式 Publish/subscribe

路由模式 Routing

通配符模式 Topic

高级特性

消息的可靠性投递

确认模式

退回模式

服务端确认方式

自动确认：acknowledge="none"

手动确认：acknowledge="manual"

消费端限流

TTL

死信队列

消息成为死信的三种情况

延迟队列

RocketMq

使用方式

生产者发送消息步骤

消息消费者的固定步骤

RocketMQ的消息样例

3.1 基本样例

1、同步发送消息的样例见：org.apache.rocketmq.example.simple.Producer

2、异步发送消息的样例见：org.apache.rocketmq.example.simple.AsyncProducer

3、单向发送消息的样例：producer.sendOneWay

4、使用消费者消费消息。

一种是消费者主动去Broker上拉取消息的拉模式

另一种是消费者等待
Broker把消息推送过来的推模式。

3.2 顺序消息

顺序消息生产者样例见：org.apache.rocketmq.example.order.Produce

顺序消息消费者样例见：org.apache.rocketmq.example.order.Consumer

3.3 广播消息

广播消息的消息生产者样例见：org.apache.rocketmq.example.broadcast.PushConsumer

3.4 延迟消息

3.5 批量消息

批量消息是指将多条消息合并成一个批量消息，一次发送出去。这样的好处是可以减少网络IO，提升吞
吐量

相信大家在官网以及测试代码中都看到了关键的注释：如果批量消息大于1MB就不要用一个批次
发送，而要拆分成多个批次消息发送。也就是说，一个批次消息的大小不要超过1MB
实际使用时，这个1MB的限制可以稍微扩大点，实际最大的限制是4194304字节，大概4MB。但
是使用批量消息时，这个消息长度确实是必须考虑的一个问题。而且批量消息的使用是有一定限
制的，这些消息应该有相同的Topic，相同的waitStoreMsgOK。而且不能是延迟消息、事务消息
等。

批量消息的消息生产者样例见：org.apache.rocketmq.example.batch.SimpleBatchProducer和
org.apache.rocketmq.example.batch.SplitBatchProducer

3.6 过滤消息

在大多数情况下，可以使用Message的Tag属性来简单快速的过滤信息。

一些比较复杂的场景就有点不
足了。这时候，可以使用SQL表达式来对消息进行过滤

SQL过滤的消息生产者案例见：org.apache.rocketmq.example.filter.SqlFilterProducer

SQL过滤的消息消费者案例见：org.apache.rocketmq.example.filter.SqlFilterConsumer

3.7 事务消息

什么是事务消息？

高级特性

一、基础概念：

1 消息模型（Message Model）

2 消息生产者（Producer）

3 消息消费者（Consumer）

4 主题（Topic）

5 代理服务器（Broker Server）

6 名字服务（Name Server）

7 消息（Message）

二、消息存储

1、何时存储消息

推其实就是拉，推的话 mq需要知道消费者的状态。
拉的话不需要知道消费者状态，

2、消息存储介质

2.1磁盘保存文件慢吗？

2.2零拷贝技术加速文件读写

3 消息存储结构

4 刷盘机制

同步刷盘

异步刷盘

配置方式

5 消息主从复制

6 负载均衡

6.1Producer负载均衡

6.2 Consumer负载均衡

1、集群模式

默认：平均分配

2、广播模式

7、消息重试

1、如何让消息进行重试

2、重试消息如何处理

8、死信队列

9、消息幂等

1、幂等的概念

三、源码解读

二、NameServer启动

NameServer的核心作用

源码重点

三、Broker启动

1、功能回顾

2、源码重点

四、Broker注册

1、功能回顾

2、源码重点

五、Producer

1、功能回顾

2、源码重点

路由管理流程

负载均衡

六、消息存储

1、功能回顾

2、源码重点：

5文件存储部分的总结：

kafka

Kafka的使用场景

日志收集

消息系统

用户活动跟踪

运营指标

Kafka基本概念

Broker

Topic

Producer

Consumer

消费模式

消费顺序

ConsumerGroup

Partition

为什么要对Topic下数据进行分区存储？

深入理解kafa

Kafka核心总控制器Controller

Controller选举机制

Partition副本选举Leader机制

消费者消费消息的offset记录机制

消费者Rebalance机制

producer发布消息机制剖析

HW与LEO详解

线上问题及优化

1、消息丢失情况：

消息发送端：

消息消费端：

2、消息重复消费

消息发送端：

消息消费端：

3、消息乱序

4、消息积压

5、延时队列

6、消息回溯

7、分区数越多吞吐量越高吗

8、消息传递保障

9、kafka的事务

10、kafka高性能的原因

四大MQ

elastic-job-lite

概念 & 功能

调度模型

进程内调度

弹性调度

分片

资源最大限度利用

高可用

失效转移

需要手动开启，但是耗性能

错过任务重执行

使用手册

作业开发

简单作业

数据流作业

脚本作业

HTTP作业（3.0.0-beta 提供）

配置错误处理策略

记录日志策略

抛出异常策略

忽略异常策略

邮件通知策略

企业微信通知策略

钉钉通知策略

参数说明

作业配置

jobName

job命名空间-对应zk的一个目录

shardingTotalCount

分片总数

cron

timeZone

shardingItemParameters

当前机器分片参数

jobParameter

monitorExecution

是否开启zk监控

failover

是否开启失败转移

* 只有对monitorExecution的情况下才可以开启失效转移.

misfire

任务错过重执行机制

maxTimeDiffSeconds

reconcileIntervalMinutes

jobShardingStrategyType

分片策略

平均分片策略

默认

奇偶分片策略

轮询分片策略

jobExecutorServiceHandlerType

jobErrorHandlerType

jobListenerTypes

description

props

disabled

设置作业是否启动时禁止.

子主题

overwrite

设置本地配置是否可覆盖注册中心配置.

http

什么是http？http是超文本传输协议

tcp/ip

三次握手

定义

client:"我要开始了"

server:"好的"

client:"那我真的开始了"

为什么要三次握手

四次挥手

定义

client:"我要结束啦"

server:"好的, 等我把数据发完"

server:"我发完啦"

client:"那我真结束啦"

为什么要四次挥手

https

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性

TLS/SSL是一种加密通道的规范

SSL由从前的网景公司开发
有1,2,3三个版本，但现在只使用版本3

TLS是SSL的标准化后的产物
有1.0 1.1 1.2三个版本
默认使用1.0

TLS1.0和SSL3.0几乎没有区别

可重入锁

可重入锁指的是在一个线程中可以多次获取同一把锁，比如：
一个线程在执行一个带锁的方法，该方法中又调用了另一个需要相同锁的方法，则该线程可以直接执行调用的方法，而无需重新获得锁；

题主想问的其实是可重入锁的必要性，如果不用重入会导致什么问题。

关于别的回答里面说的递归调用，跟重不重入其实关系不大，正常人不会递归调用加锁的方法，跟在外面加一把锁里面再去递归调用的意义没什么区别，所以说服性不强。

public class LockTest {
static ReentrantLock lock = new ReentrantLock();

public void m1(){
lock.lock();
try {
m2();
}finally {
lock.unlock();
}
}

private void m2() {
//既然m1已经加锁了，为什么m2还需要加锁？不加锁一样能够保证m1调用m2的安全性
lock.lock();
try {
System.out.println("同步代码块");
}finally {
lock.unlock();
}
}
}

在这段代码中，m1调用了m2，既然m1已经加锁了，为什么还要给m2加锁？

原因是既然m2独立出来成了一个方法，你就没法保证你在调用m1的方法的同时，别的人不通过m1调用m2，而是直接调用m2。如果m2不加锁，这里就必然会出现线程安全问题。

Ribbon本地负载均衡和Nginx服务器端负载均衡的区别

spring

ioc

spring boot

自动装配原理

spring cloud

sentinel

流控规则

warm up

排队等待

降级规则

RT

异常比例

异常数

热点规则

@SentinelResource("")

整合feign

feignClient 可以使用相同的 name属性

分布式事务

谈谈中间件开发

elk+fileBeat

搭建日志处理系统的需求原因

集中式日志系统，包含几个主要特点

收集－能够采集多种来源的日志数据 ---logstash、fluent bit

传输－能够稳定的把日志数据传输到中央系统 ----MQ（rabbitmq/kafka）

存储－如何存储日志数据 --ElasticSearch/Redis/Kafka等

分析－可以支持 UI 分析 -- grafana/kibana 等

警告－能够提供错误报告，监控机制 -- Prometheus的监视系统 - 简书

日志采集的可行性方案

系统架构图示例