将面试遇到的问题 都会持续的记录下来。
1 jvm 原理。程序运行区域划分
问：Java运行时数据区域？
回答：包括程序计数器、JVM栈、本地方法栈、方法区、堆
问：方法区里存放什么？
本地方法栈：和jvm栈所发挥的作用类似，区别是jvm栈为jvm执行java方法（字节码）服务，而本地方法栈为jvm使用的native方法服务。
JVM栈：局部变量表、操作数栈、动态链接、方法出口。
方法区：用于存储已被虚拟机加载的类信息，常量、静态变量、即时编译器编译后的代码等。
堆：存放对象实例。
2 类加载机制是怎样的
JVM中类的装载是由ClassLoader和它的子类来实现的,Java ClassLoader是一个重要的Java运行时系统组件。它负责在运行时查找和装入类文件的类。
类加载的五个过程：
1加载（加载就是将表示类的文件加载进内存中以便于虚拟机调用）
2验证（连接分为三步：验证，准备，解析；目的是确保字节流符合虚拟机的规范，不会危害虚拟机）
3准备（为类变量分配内存并设置初始值）
4解析（解析是将常量池中的符号引用替换成直接引用的过程）
5初始化（对类变量和静态代码块进行赋值和执行）
这个时候虚拟机会为有类变量和静态代码块的类或者接口生成()方法（不是构造方法）。这个方法有以下几个特点。
5.1 这个方法首先会调用父类的这个方法，确保父类的方法已经执行；
5.2 由于父类的方法首先执行，所以父类的静态代码块也会优先于子类执行。
5.3 如果类或者接口没有类变量和静态代码块（接口没有静态代码块，针对类）可以不存在
5.4 接口不需要先执行父接口的方法。
5.5 虚拟机会保证在多线程环境下方法能被正确的加锁，保证线程安全。
5.6 方法同一个加载器下只会执行一次。也就是说如果有多个线程同时请求加载一个类，只有一个线程会进入方法，其他线程被阻塞，当运行完方法后，释放锁，但是其他线程也不会在执行方法了。
从类被加载到虚拟机内存中开始，到卸御出内存为止，它的整个生命周期分为7个阶段，加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸御(Unloading)。其中验证、准备、解析三个部分统称为连接。
3 双亲委派模型
类加载器有是三个：启动类加载器、扩展类加载器、应用程序加载器（系统加载器）
工作过程是：如果一个类加载器收到了一个类加载的请求，它首先不会去加载类，而是去把这个请求委派给父加载器去加载，直到顶层启动类加载器，如果父类加载不了（不在父类加载的搜索范围内），才会自己去加载。
1. 启动类加载器：加载的是lib目录中的类加载出来，包名是java.xxx（如：java.lang.Object）
2. 扩展类加载器：加载的是lib/ext目录下的类，包名是javax.xxx（如：javax.swing.xxx）
3. 应用程序扩展器：这个加载器就是ClassLoader的getSystemClassLoader的返回值，这个也是默认的类加载器。
双亲委派模型的意义在于不同的类之间分别负责所搜索范围内的类的加载工作，这样能保证同一个类在使用中才不会出现不相等的类，举例：如果出现了两个不同的Object，明明是该相等的业务逻辑就会不相等，应用程序也会变得混乱。
4 CAP
一致性(Consistency)
可用性(Availability)
分区容忍性(Partition tolerance)
Zoopkeeper保证CP
Eureka保证AP
CAP理论提出就是针对分布式数据库环境的，所以，P这个属性是必须具备的。
P就是在分布式环境中，由于网络的问题可能导致某个节点和其它节点失去联系，这时候就形成了P(partition)，也就是由于网络问题，将系统的成员隔离成了2个区域，互相无法知道对方的状态，这在分布式环境下是非常常见的。
因为P是必须的，那么我们需要选择的就是A和C。
大家知道，在分布式环境下，为了保证系统可用性，通常都采取了复制的方式，避免一个节点损坏，导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的，所以，当P发生时，也就是无法向某个节点复制数据时，这时候你有两个选择：
选择可用性 A(Availability)，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。
选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。
最常见的例子是读写分离，某个节点负责写入数据，然后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通信问题时，你就面临着选择A（继续提供服务，但是数据不保证准确），C（用户处于等待状态，一直等到数据同步完成）
5 终止线程有几种方式
1.线程正常执行完毕，正常结束
2.监视某些条件，结束线程的不间断运行
3.使用interrupt方法终止线程
6线程池
corePoolSize：
默认线程数量（核心线程数量），在创建线程池之后，线程池里没有任何线程，等到有任务进来时才创建线程去执行任务（懒加载）。当线程池中的线程数达到corePoolSize的值后，就会把到达的任务放到缓存队列里；
maximumPoolSize：
最大线程数量，表明线程中最多能创建的线程数量。当核心线程+非核心线程达到这个数值后，后续任务将会根据RejectedExecutionHandler处理器来进行饱和策略处理；
keepAliveTime：
非核心线程闲置时的存活时间，超过该时长，非核心线程就会被回收；
TimeUnit：
keepAliveTime时长对应的单位（天、小时、分钟、秒、毫秒、微妙、纳秒）；
BlockingQueue：
阻塞队列，存储等待执行的任务；
ThreadFactory：
线程工厂，用来创建线程；
RejectedExecutionHandler：
队列已满，而且任务量大于最大线程数量的异常处理策略。
7 线程池的好处
1、线程池的重用
线程的创建和销毁的开销是巨大的，而通过线程池的重用大大减少了这些不必要的开销，当然既然少了这么多消费内存的开销，其线程执行速度也是突飞猛进的提升。
2、控制线程池的并发数
3、线程池可以对线程进行管理
线程池可以提供定时、定期、单线程、并发数控制等功能。比如通过ScheduledThreadPool线程池来执行S秒后，每隔N秒执行一次的任务。
8 java中volatile和synchronized有什么区别
1.volatile本质是在告诉jvm当前变量在寄存器(工作内存)中的值是不确定的，需要从主存中读取；synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
2.volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的。
3.volatile仅能实现变量的修改可见性，并不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性。
4.volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。
5.volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化
9 synchronized 和 Lock 有什么区别
首先synchronized是Java内置关键字，在JVM层面，Lock是个Java类；
2、 synchronized 可以给类、方法、代码块加锁；而 lock 只能给代码块加锁。
3、 synchronized 不需要手动获取锁和释放锁，使用简单，发生异常会自动释放锁，不会造成死锁；而 lock 需要自己加锁和释放锁，如果使用不当没有 unLock()去释放锁就会造成死锁。
4、 通过 Lock 可以知道有没有成功获取锁，而 synchronized 却无法办到。
10 Array和ArrayList的不同点
ArrayList和LinkedList都实现了List接口，他们有以下的不同点：
ArrayList是基于索引的数据接口，它的底层是数组。它可以以O(1)时间复杂度对元素进行随机访问。与此对应，LinkedList是以元素列表的形式存储它的数据，每一个元素都和它的前一个和后一个元素链接在一起，在这种情况下，查找某个元素的时间复杂度是O(n)。
相对于ArrayList，LinkedList的插入，添加，删除操作速度更快，因为当元素被添加到集合任意位置的时候，不需要像数组那样重新计算大小或者是更新索引。
LinkedList比ArrayList更占内存，因为LinkedList为每一个节点存储了两个引用，一个指向前一个元素，一个指向下一个元素。
11 sleep和wait的区别
1,定义在不同的类上
sleep方法定义在Thread类中
wait方法定义在Object类中
为什么wait要定义在Object中，而不定义在Thread中？
在同步代码块中，我们说需要一个对象锁来实现多线程的互斥效果，也就是说，Java的锁是对象级别的，而不是线程级别的。
2.对锁资源的处理方式不同
sleep不会释放锁
wait会释放锁
3.写在不同的代码域
sleep可以使用在任何代码块
wait必须在同步方法或者同步代码块中执行
4.方法使用区别
sleep会进入time waiting状态,到时间解除sleep
wait会进入waiting状态,可以用时间,或者使用notify或者notifyAll方法进行唤醒
为什么wait必须写在同步代码块中？
原因是避免CPU切换到其他线程，而其他线程又提前执行了notify方法，那这样就达不到我们的预期（先wait再由其他线程来唤醒），所以需要一个同步锁来保护
12 分布式事务的解决方案有哪些？
T（Try）锁资源：锁定某个资源，设置一个预备类的状态，冻结部分数据。
比如，订单的支付状态，先把状态修改为"支付中（PAYING）"。
比如，本来库存数量是 100 ，现在卖出了 2 个，不要直接扣减这个库存。在一个单独的冻结库存的字段，比如 prepare _ remove _ stock 字段，设置一个 2。也就是说，有 2 个库存是给冻结了。
积分服务的也是同理，别直接给用户增加会员积分。你可以先在积分表里的一个预增加积分字段加入积分。
比如：用户积分原本是 1190 ，现在要增加 10 个积分，别直接 1190 + 10 = 1200 个积分啊！你可以保持积分为 1190 不变，在一个预增加字段里，比如说 prepare _ add _ credit 字段，设置一个 10 ，表示有 10 个积分准备增加。
C（Confirm）：在各个服务里引入了一个 TCC 分布式事务的框架，事务管理器可以感知到各个服务的 Try 操作是否都成功了。假如都成功了， TCC 分布式事务框架会控制进入 TCC 下一个阶段，第一个 C 阶段，也就是 Confirm 阶段。此时，需要把 Try 阶段锁住的资源进行处理。
比如，把订单的状态设置为“已支付（Payed）”。
比如，扣除掉相应的库存。
比如，增加用户积分。
C（Cancel）：在 Try 阶段，假如某个服务执行出错，比如积分服务执行出错了，那么服务内的 TCC 事务框架是可以感知到的，然后它会决定对整个 TCC 分布式事务进行回滚。
TCC 分布式事务框架只要感知到了任何一个服务的 Try 逻辑失败了，就会跟各个服务内的 TCC 分布式事务框架进行通信，然后调用各个服务的 Cancel 逻辑。也就是说，会执行各个服务的第二个 C 阶段， Cancel 阶段。
比如，订单的支付状态，先把状态修改为" closed "状态。
比如，冻结库存的字段， prepare _ remove _ stock 字段，将冻结的库存 2 清零。
比如，预增加积分的字段， prepare _ add _ credit 字段，将准备增加的积分 10 清零。
13 mysql事务隔离级别
数据库事务具备ACID特性，即Atomicity(原子性) Consistency(一致性), Isolation(隔离性), Durability(持久性)
原子性：要执行的事务是一个独立的操作单元，要么全部执行，要么全部不执行
一致性：事务的一致性是指事务的执行不能破坏数据库的一致性，一致性也称为完整性。一个事务在执行后，数据库必须从一个一致性状态转变为另一个一致性状态。
隔离性：多个事务并发执行时，一个事务的执行不应影响其他事务的执行，SQL92规范中对隔离性定义了不同的隔离级别：
读未提交(READ UNCOMMITED)->读已提交(READ COMMITTED)->可重复读(REPEATABLE READ)->序列化(SERIALIZABLE)。隔离级别依次增强，但是导致的问题是并发能力的减弱。
大多数数据库系统的默认隔离级别都是READ COMMITTED（但MySQL不是)，InnoDB存储引擎默认隔离级别REPEATABLE READ，通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。
14 mysql 事务日志
事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称之为预写式日志（Write-Ahead Logging），修改数据需要写两次磁盘。 如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。
MySQL Innodb中跟数据持久性、一致性有关的日志，有以下几种：
Bin Log: 是mysql服务层产生的日志，常用来进行数据恢复、数据库复制，常见的mysql主从架构，就是采用slave同步master的binlog实现的
Redo Log: 记录了数据操作在物理层面的修改，mysql中使用了大量缓存，修改操作时会直接修改内存，而不是立刻修改磁盘，事务进行中时会不断的产生redo log，在事务提交时进行一次flush操作，保存到磁盘中。当数据库或主机失效重启时，会根据redo log进行数据的恢复，如果redo log中有事务提交，则进行事务提交修改数据。Undo Log: 除了记录redo log外，当进行数据修改时还会记录undo log，undo log用于数据的撤回操作，它记录了修改的反向操作，比如，插入对应删除，修改对应修改为原来的数据，通过undo log可以实现事务回滚，并且可以根据undo log回溯到某个特定的版本的数据，实现MVCC
MVCC实现
MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号（system version number)。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。
SELECT
InnoDB会根据以下两个条件检查每行记录：
InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
只有符合上述两个条件的记录，才能返回作为查询结果
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
DELETE
InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
UPDATE
InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作
15 #{}和${}的区别是什么？
${}是字符串替换，#{}是预处理；
Mybatis在处理${}时，就是把${}直接替换成变量的值。而Mybatis在处理#{}时，会对sql语句进行预处理，将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值；
使用#{}可以有效的防止SQL注入，提高系统安全性。
16 乐观锁和悲观锁是什么？
乐观锁是什么？
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
乐观锁一般会使用版本号机制或CAS算法实现。
悲观锁是什么？
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
使用场景分别是？
乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。
17 sleep（） 和 wait（） 的区别？
对于sleep()方法，我们首先要知道该方法是属于Thread类中的。而wait()方法，则是属于Object类中的。
sleep()方法导致了程序暂停执行指定的时间，让出cpu该其他线程，但是他的监控状态依然保持者，当指定的时间到了又会自动恢复运行状态。
在调用sleep()方法的过程中，线程不会释放对象锁。
而当调用wait()方法的时候，线程会放弃对象锁，进入等待此对象的等待锁定池，只有针对此对象调用notify()方法后本线程才进入对象锁定池准备
获取对象锁进入运行状态。
18 redis持久化方式？
默认开启RDB方式。
1、AOF
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
2、RDB
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
3 、二者优缺点
RDB存在哪些优势呢？
1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
RDB又存在哪些劣势呢？
1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
AOF的优势有哪些呢？
1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
AOF的劣势有哪些呢？
1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
19 redis事务
Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis事务的三个阶段
事务开始 MULTI
命令入队
事务执行 EXEC
事务执行过程中，如果服务端收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排
Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。
Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。
集群方案
哨兵模式
哨兵的介绍
sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：
集群监控：负责监控 redis master 和 slave 进程是否正常工作。
消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。
故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。
哨兵的核心知识
哨兵至少需要 3 个实例，来保证自己的健壮性。
哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
缓存异常
缓存雪崩
缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案
缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。
给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。
缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案
接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力
20 nacos心跳检测周期是多少？
nacos客户端向服务端发送心跳的时间间隔，默认5s
注：客户端向服务端每隔5s向服务端发送心跳请求，进行服务续租，告诉服务端该实例IP健康。若在3次心跳的间隔时间(默认15s)内服务端没有接受到该实例的心跳请求，则认为该实例不健康，该实例将无法被消费。如果再次经历3次心跳的间隔时间，服务端接受到该实例的请求，那么会立刻将其设置外健康，并可以被消费，若未接受到，则删除该实例的注册信息。推荐配置为5s，如果有的业务线希望服务下线或者出故障时希望尽快被发现，可以适当减少该值。
21 什么样的数据应该放在缓存中
1.数据量不大
2.访问频率高
3.数据更改频率低
22 mysql中如何进行优化？
答案查看： https://mp.weixin.qq.com/s?__biz=MzIxMjg4NDU1NA==&mid=2247483684&idx=1&sn=f5abc60e696b2063e43cd9ccb40df101&chksm=97be0c01a0c98517029ff9aa280b398ab5c81fa1fcfe0e746222a3bfe75396d9eea1e249af38&mpshare=1&scene=1&srcid=0606XGHeBS4RBZloVv786wBY#rd
23 mysql中B+Tree?
B+Tree：
非叶子节点不存储data，只存储索引（冗余），可以放更多索引；
叶子节点包含所有索引字段，即所有的data元素存储在叶子节点上；
叶子节点使用指针连接，提高区间访问的性能；
从左到右一次递增;
B+Tree 相对于 B-Tree的优化点：
优化点1： B-Tree的所有节点都存储了 data 元素， B+Tree的非叶子节点不存储 data元素，则 B+Tree 的一个非叶子节点可以存储更多的索引；
优化点2： B+Tree在叶子节点之间增加了指针连接；对 select * from t where col2 > 20 的范围查找有很好的支持；
MySQL 对 B+Tree 做了优化，叶子节点使用的是双向指针；
**