java八股文整理了1年多 非常全！

每次被引用计数器+1

循环引用不会被判定为垃圾

被GCRoot引用不会被回收

GC Root

强引用

软引用

弱引用

虚引用

标记需要回收的对象，直接删除

碎片化严重，大对象可能找不到内存空间

存活拷贝到新内存，老地方剩余对象清空

浪费内存空间，使用率减半

同一空间，边整理排列，边清理

效率低，STW 移动存活对象需要时间

新生代  需要回收的垃圾较多，所以用拷贝算法（需要拷贝的对象较少）

老年代 标记压缩算法（CMS除外）

单线程 回收STW

效率低

最小内存适用

多线程回收 Serail的多线程版本

CMS（ConCurrent Mark Sweep）

PS+PO 1.8的默认回收器

最大吞吐量

特点：自适应调节策略：-XX:+UseAdptiveSizePolicy

1.9以后的默认回收器  并发+并行

摒弃了分代模型，采用分区算法 部分回收（物理不分代，逻辑分代）

采用标记压缩算法，不产生碎片

根据每个区优先级不同，垃圾量不同，执行策略不同，保证了高吞吐，低延迟

Oracl官方支持

不分代 速度快 （大中小页面）

颜色指针 零停顿 100ms扫一遍

OpenJDK12 开源

并发回收阶段

指向虚拟机字节码指令位置

若执行native方法，则为空

局部变量表

操作数栈

动态链接（指向元数据的指针）

方法出口

执行本地C语言方法

逻辑与虚拟机栈一致

存储已被JVM加载的类方法信息

JDK8已经把方法区的实现，从永久代转变为元空间

新生代

老年代

对象、成员变量

运行时常量

类常量池

类信息

最上层，加载核心类库

负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现

不允许直接获取引用

负责加载JRE的扩展目录

lib/ext或者由java.ext.dirs系统属性指定的目录中的JAR包的类

加载用户路径上的类库

加载来自Java命令的-classpath选项、java.class.path系统属性，或者CLASSPATH换将变量所指定的JAR包和类路径

硬盘IO读取class文件，生成一个代表这个类的class对象 放到元空间（懒加载）

内存分配 指针碰撞

堆中生成class对象，作为访问入口

对象内存布局

验证（verification）

准备（preparation）

解析（resolution）

类变量的赋值和静态初始块的执行

执行 类构造器< clinit>() 方法的过程。

保证子类的Clint方法执行前，父类的已经执行完毕，所以第一个执行的一定是java.lang.Object

1.自定义类加载，重写loadclass方法
因为双亲委派的机制都是通过这个方法实现的，这个方法可以指定类通过什么类加载器来进行加载，所有如果改写他的加载规则，相当于打破双亲委派机制

2.使用线程上下文类
双亲委派模型的第二次“破坏”是由这个模型自身的缺陷所导致的，双亲委派很好的解决了各个类加载器的基础类统一问题，基础类之所以“基础”，是因为他们总被用户代码所调用，但是如果基础类又要重新调用用户代码，那咋办？
比如说JNDI是java的标准服务，它的代码是由启动类加载器进行加载的，但是jndi的作用就是进行资源的集中管理和查找，它需要调用由开发人员开发在classpath下的类代码，但是启动类加载器不会进行加载。
所以引入线程上下类加载器，通过java.lang.Thread类的setContextClassLoader()方法进行设置。如果创建线程是还未设置，它会从父线程继承一个，如果在应用程序全局范围内没有设置，那么这个线程上下类加载器就是应用程序类加载器。
那么这样JNDI服务使用这个线程上下类加载器去加载所需的spi代码，也就是父类加载器请求子类加载器去完成类加载的动作，这个实际是打通了双亲委派的逆向层次结构。

传入二进制至defineClass

JIT会进行逃逸分析，如果发现一个对象不会被外界访问，通过标量替换代替这个对象
从而达到栈内存分配，避免了堆内存分配和垃圾回收

锁消除优化（堆中加锁消耗太大）

堆内存大

能处理的QPS变大

单次GC时间长

导致后面排队的线程等待时间边长

堆内存小

能处理的QPS变小

单次GC时间短

线程等待的延迟小

适用于交互性应用，尽量不要有明显的STW时间

Serial（新）
Serial Old

Parallel Scavenge（新）
Parallel Old

ParNew(新)
CMS

并行+并发

分代收集

空间整合

可预测的停顿

列出Java程序进程ID和Main函数名称

jps -l：输出主函数的完整路径

查看Java程序运行时相关信息，可以通过它查看堆信息的相关情况

jstat -gc 7063 500 4   7063 是进程ID ，采样时间间隔为500ms，采样数为4

查看正在运行的java程序的扩展参数，甚至支持运行时修改部分参数

jinfo -flags 8384  查看所有参数

查看堆内存使用状况，一般结合jhat（分析工具）使用

jmap -dump:format=b,file=2022xxxx.hprof  产生堆内存转储文件

jmap - histo 进程号 | head -20    对象占用比重

jstack用于生成java虚拟机当前时刻的线程快照

jstack -l pid > jstack_info.txt  将指定进程的当前堆栈情况记录到某个件中

jstack pid         线程内的调用栈信息

java文件夹里 bin自带的

eclipse

命令行的

读日志的，关系不大

dashbord命令 等于top-hp jinfo等命令组合

heapdump  替代jmap

thread 列出所有线程  thread-b 查找死锁

（重要）jad 反编译指定类，可排查线上代码版本是否符合预期

（重要）redefine（在线重新编译class，无需重启，救命用） 重新编辑vim xx. java ,并编译为class(javac XX.java)，上传至远程再redfine。

（重要）trace 单机版的链路追踪

负责注解其他注解

因为泛型的实现需要改变Java的类文件格式。

<? extends T> 上边界解决问题。指定子类关系

<? super T> 下边界解决问题。指定父类关系

ObjectInputStream

ObjectOutputStream

serialVersionUID 为版本号，如果不指定，jvm 会按照自己的计算规则，版本不同代表 class 文件被更改，无法反序列化

必须有无参构造函数（反序列化是通过反射）

必须重写 writeExternal 和 readExternal 自定义要序列化哪些属性

性能更好，但复杂度变高

implements Cloneable

implements Serializable

Proxy.newProxyInstance

内置反射技术，AOP适用

Enhancer.create

如果目标类实现了接口，自动选择jdk动态代理

CGLAB要求低，更通用

编译无法通过，需要catch货throws

例如runtime 编译无法识别

尾部add O1  插入删除 On-1   支持快速随机访问（RandomAccess接口标识）

列表结尾预留一定容量空间

扩容1.5倍

头尾O1 插入删除On 不支持快速随机访问

每一个元素花费的空间比较多

2个元素hash碰撞，同时插入到链表第一个互相覆盖

put的同时在扩容，链表逆转（1.8已修复）会导致闭环链，get的时候死循环

强一致性的迭代器，一边迭代一边插入数据，会报错

1.7、数组+Segment+分段锁

1.8、synchronized+CAS+HashEntry+红黑树

1、非空判断+是否初始化判断

2、计算key的hashcode，与数组长度-1 做与运算，定位索引位置
无元素->新增数组则CAS插入
有元素->判断是否扩容->协助扩容
有元素->synchronize加锁，DCL检验，判断链表插入/红黑树插入

3、插入之后判断是否满足链表大于8，且数组长度大于64，满足则转换transfer，否则扩容（2*old）

put或者putAll触发tryPresize

转树之前判断<64，则tryPresize

保证每次是2的次幂，位运算的时候可以有效散列，且提高运算效率

对数组长度取模，防止hash过于松散，40亿的映射空间

CPU ALU计算单元处理速度是读取内存的100倍，所以中间需要3层缓存增加读取速度

多线程访问缓存行，若处在同一缓存行则需要相互通知失效变更

可以凑64字节，使得关键变量不会在多线程环境下处于相同缓存行

例如：Disruptor的环形队列，就在指针的前后声明了7个Long共56个字节，使得每个线程拿到的指针变量，一定不会出现同一行

@Contended注解 自动补全  java8

芯片级别关闭所有可能中断的命令

SS、LL、SL、LS 保证指令一致性

JVM层面的volatile 也可使CPU层加lock实现禁止重排

编译级别+指令级别

Lock

递增无需加锁

unsafe类 底层compare and swap C++实现

读取值，做递增，再读取一遍和之前读取的对比有没有变化

重新读取的和之前读取的一样，认为没有发生变化

加version或者stamp来标识，是否真的和之前读取的一样。

stamp用户自行实现，在AtomicStampedReference的内部会将这两个变量封装成Pair对象

单个任务执行效率快，就用CAS，自旋消耗CPU不高。

单个任务执行很慢，用synchronize，放入队列，不消耗CPU

jdk1.5之后，synchronize内部有锁升级过程，可以自己从偏向->自旋->重量级锁

CAS不会被阻塞，会在同一线程自旋，消耗CPU，但不会产生线程切换，synchronize会被阻塞/唤醒，频繁的线程切换

java代码：synchronize

字节码编译：monitorenter   monitorexit （监视器）

执行过程中自动升级

底层汇编 lock comxchg

实际是给对象头记录信息（markword）

两把/多把锁 合成为一把锁

反转某一个元素达到目的（效率不高）

奇偶数反转（反转一半元素，效率高）

没有争抢

jdk15之后 废除

较消耗cpu  (自旋线程超过核数2分之1/自旋10次以上 升级)1.6之后，JVM自适应自旋，自己判断是否升级

切换用户态到内核态 做到硬件互斥

每一个重量级锁，后面跟着一个队列，不消耗CPU,转换为线程切换成本

集群主节点挂了，没有同步至从节点，则会重复获取锁

redLock方案，依次从多个独立的redis实例申请加锁，半数以上成功

死锁问题，如进程挂了没有释放

实效性问题，过期时间不应该太长，太短没事，会续期，太长挂了会一直阻塞

主节点挂了，重复加锁。 redlock解决，但过于复杂，不实用

颗粒度过大，锁定资源太多，阻塞过多。

加锁（可重入）

锁续期（默认30s）

解锁

线程间有变化，下次用到重新从主内存 读进各个线程的工作内存

 volatile写（JVM层面）

volatile读（JVM层面）

CPU层面 hostsport源码，用lock进行强锁总线，保证同一时间只有一个CPU工作进程访问内存，访问之后会让三级缓存进行更新

反例：new一个对象分三部：申请内存实例化--初始值--创建引用关联   ，若没有修饰volatile，后两步可能重排，其他线程可能拿到半成品对象

所以 DCL（double check lock）场景 需要加volatile关键字，防止多线程拿到半初始化对象

volatile 修饰变量，会告知编译器每次都从变量的地址读取数据，而在局部变量上，一般使用后即释放，会有很多函数的局部变量用同一地址的SRAM，如果中断函数改写了该数据，会导致执行异常。

可选公平或非公平（默认）

可中断

基于api实现，lock() unlock() ，  必须手动释放锁，但 sync 不用

可以创建多个condition队列，可以精确signal唤醒
传统synchronize只有一个队列，由jvm随机选择唤醒

InheritableThreadlocal

TransmittableThreadLocal

cpu/1-阻塞因子

IO越密集、阻塞因子越大，线程数设置越多，这样 cpu 不会空等，有效利用 cpu

CPU 计算密集，线程数不能太多，因为太多也没用

根据压测来定

默认是任务到达启动，但可以用方法提前开启

如果你设置了keepAliveTime，空闲超时之后，会把超过 core 数量的部分回收

 如果设置了executor.allowCoreThreadTimeOut(true)，会把核心也回收

如果你设置了keepAliveTime，空闲超时之后，会把超过 core 数量的部分回收

无限创建线程的消耗较高，所以需要队列

有界队列 要考虑拒绝策略

无界队列 要考虑提交任务过快内存溢出

阻塞队列主要是：有限的队列长度，队列满了防止溢出，可以阻塞保留当前任务；
队列为空，阻塞线程，保持核心线程不退出

PriorityBlockingQueue （优先级队列 ）

拒绝策略

先判断核心线程数满没

塞进队列

在决定是否新增非核心队列

最大（有界队列的话）也满了，就拒绝策略

上为JUC 原生顺序，tomcat/Dubbo 等模型，为 IO 密集型，重写了队列的入队 offer 方法更改顺序
优先创建线程，避免阻塞时间过长，如果最大线程数也满了，才会放入队列

runnable

runnable和callable都可以  可以future 接收返回值

会被包装成 fetureTas() 执行任务

running

shutdown()/shutdownNow()

tidying（自动）

terminated（自动）

防止任务丢失

共享线程池

threadLocal 线程池场景会失效，用阿里的 ttl

Spring 容器关闭 容易丢数据

OOM

ThreadPoolExcute 用到了 ReentrantLock 类型锁 mainLock，保证了largestPoolSize、completedTaskCount的准确性。
（变量为 HashSet 不安全容器，所以要用锁，并且要实时拿到准确的，而不是等方法完成才拿到，所以没必要用 volatile）

 Worker 继承 AQS 主要就是为了实现了一把非重入锁，维护线程的中断状态，保证不能中断运行中的线程（runWork 的时候会加锁，表示一个线程正在执行任务）。
lock() 方法会调用 tryAcquire() 方法，CAS 加锁

ThreadPoolExcuter 提供了多种 set 和 get ，可用来监控指标和动态调整参数（活跃线程数、队列容量等）
通过钩子函数还可以算出任务执行时长告警等

无界队列的固定线程池

单例线程池，无界队列，保证顺序执行

核心=0，最大=MAXVALUE，适用于执行很多的短期异步任务，或者是负载较轻的服务器   队列没有容量

创建一个以延迟或定时的方式来执行任务的线程池，工作队列为 DelayedWorkQueue。适用于需要多个后台线程执行周期任务。

JDK 1.8 新增，用于创建一个可以窃取的线程池，底层使用 ForkJoinPool 实现。

与 Java 平台的设计相协调，易于理解、易于编程、易于调试和配置

可用线程的数量是有限的，操作系统线程代价高昂，因此我们不能拥有太多线程

这种细粒度的线程共享允许大量并发操作，而不需要消耗大量线程，提高可伸缩性

这种编程 style 与 Java 平台不一致，因为应用程序的并发单元（异步管道）不再是平台的并发单元

pojo轻量级，最小侵入

依赖注入 ，接口实现松耦合

DI为实现方式

基于切面声明式编程

切面和模板减少样板编程

IOC的一个扩展点而已（BeanPostProcessor）

@Service

@Component

@Configuration+@Bean

@Autowired

@Resource

@PostConstruct

read uncommitted

read committed

repeatable read

serializable

有@transaction 注解时，spring会将事务的自动提交关闭，并通过AOP动态代理来调用，若报错，会执行回滚

通过TransactionInterceptor 的invoke实现具体逻辑

用ThreadLocal保证了多方法拿到的同一个JDBC的connect

Bean对象没有被spring容器管理

修饰符不是public

自调用没有经过AOP代理

数据源没有配置事务管理器

异常被捕获/异常类型配置错误

准备工作，解析事务属性，判断是否开启事务

开启时，先获取数据库连接，关闭自动提交，开启事务

执行具体sql逻辑

失败：通过completeTransactionAfterThrowing完成事务回滚。具体逻辑通过doRollBack实现。也是先获取连接对象，然后con.rollBack

成功：commitTransactionAfterReturning 通过doCommit实现，也是先获取连接，再提交

清除事务相关信息 cleanupTransactionInfo

只会回滚运行时异常（RuntimeException）

可以将异常包装，或者rollbackFor=Exception.class 进行声明

一个容器，包含一些map结构方便存储对象

getBean检查是否存在（单例）

读取配置文件/注解 将需要创建的bean封装成beanDefiniton

将BD对象通过反射进行实例化

初始化，变成完整的bean，存储在map中

提供入口通过容器获取对象

提供销毁操作

实例化bean对象

设置bean属性

检查aware相关接口并设置相关依赖

BeanPostProcessor的前置处理

检查是否实现initializingBean接口

初始化方法调用 invokeInitMethod

BeanPostProcessor的后置处理

添加 Bean 对象到容器中 

注册必要的Destruction相关回调接口

singleton

prototype

request

session

global-session

一级存储成品对象

二级存储半成品对象

三级缓存lamda函数式接口

BeanFactory 是用来获取 bean，管理 bean 生命周期的工厂

FactoryBean 是一个 bean，可以重写 getObject 来返回 bean,自定义 创建Bean 的规则，做一些增强，context.getBean("myFactoryBean")可以直接获取到 getObject 的值

目的：动态查询，重写覆盖@Table @Field的值

难点：mybatisPlus会在bean生成之前，把类信息存成静态，无法覆盖

解决：在plus加载之前，找到切入点，应用上下文加载的时候，把类注解的值覆盖到类信息

BeanFactory

ApplicationContext

内部通过CurrentHashMap  保证单里注册表的不冲突

jdk代理实现接口的对象

cglab代理没有实现接口的对象

子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤的实现方式

Spring事件驱动模型

继承ApplicationEvent  定义事件

实现 ApplicationListener 接口，重写 onApplicationEvent() 方法 定义事件监听者

ApplicationContext 的 publishEvent() 方法发布消息 使用事件发布者发布消息

DispatcherServlet 根据请求信息调用 HandlerMapping，解析请求对应的 Handler。解析到对应的 Handler（也就是我们平常说的 Controller 控制器）后，开始由HandlerAdapter 适配器处理。HandlerAdapter 作为期望接口，具体的适配器实现类用于对目标类进行适配，Controller 作为需要适配的类。

spring体现

JDK体现

mybatis体现

协调器全权负责调用顺序，执行 等回复

优势：关系简洁易拓展和管理，降低参与者复杂度（只考虑执行和回复）

劣势：中央协调器复杂难维护，单点故障

各个业务自身达成一定的调用顺序，不需要事务协调

优势：没有单点故障风险，步骤少

劣势：循环依赖风险，服务间关系混乱 难维护

ZAB选举： 互相推荐，节点竞争，选取最完整节点，单向通信多次，流程复杂

Raft选举：先发现leader挂了，先进行投票。也会参照日志完整性，任期等。但通讯消息数更少（双向通信），选举更快，每轮时间固定

raft的leader日志一定是最新的，最新的日志才能当leader。单向数据协议

而zab经过一系列复杂的选举，当成leader，（需要将自己的日志先更新位最新的），再广播

Raft：创建log，广播log，半数成功，自己commit，反馈客户端。下一个心跳包，通知小弟commit

Zab：leader创建Proposal，半数成功，广播commit，自己也同时commit，运用到内存树，反馈客户端

系统轮询调用，每次调用都需要把全部描述符集合从用户态传输到内核态，并且需要判断每个描述符是否就绪

数据就绪之后，会把监听的FD集合都发过去，用户进程需要到FD遍历查找

fd_set大小固定为1024

过程同上

pollfd内核中采用链表，理论无上限

epoll 是基于事件驱动的模型，通过callback函数只处理活跃的文件描述符，效率更高。

epoll是通过内核于用户空间mmap同一块内存实现的

堆内存

直接内存（堆外）

通道是支持读取或者写入缓冲区的，也可以异步地读写，但是是不能直接访问数据的

检查一个或多个NIO通道，负责多个通道看哪个已经将数据准备就绪

通过字节传输，例如视频文件，如果是中文utf-8 一个汉字3字节，字节截断容易出现乱码。而且需要提前知道编码规则

主要传输中文，按照一个字符读取，解决乱码问题，但效率较慢。字符流=字节流+编码

存放服务器地址的消息，将请求打包成网络消息，通过网络远程发送给服务方

接收客户端的请求消息，解包（解码，反序列化），并调用本地方法

过程

核心组件

索引成本变大

若机器挂了，也只会影响节点附近的数据，不会导致所有数据 key 偏移

负载均衡也可设计虚拟节点，平均分布在环上，做一个节点映射的策略

SDS

bitmaps(位图)

encoding

键值对存储计算等场景

单独覆盖某个属性值，无需大json整体出入

存储为双向链表结构，正负索引

无序 去重

算交集/差集   sinterstroe 和sinter 前面的可以将交集结果直接放入新的key，减少IO

随机事件 srandmember/spop

排序且去重，正逆向索引，物理从小到大左边排列，不随命令变化

给出元素和分值

场景: 排行榜、优先级队列

交集并集+权重

原理： 链表存储，skipList 跳跃表，每个层数随机（类平衡树） （牺牲空间 换取查询速度）

父进程fork出一个子进程备份，无需其他IO

优势：适用数据集的备份（灾备），恢复更快

劣势：丢失数据较多，数据集过大fork消耗内存空间及性能

不同时间间隔策略不同，数据变更量越大，同步间隔越小

可以手动触发，也可以自动触发（config配置/重启/shutdown）

在有子进程执行RDB过程的时候，Redis主进程的读写不受影响，但是对于Redis的写操作不会同步到主进程的主内存中，而是会写到一个临时的内存区域作为一个副本，等到主进程接收到子进程完成RDB过程的消息后再将内存副本中的数据同步到主内存。

最大程度保证数据完整。但性能也会降低

频次策略：1、每秒一次，主线程IO写磁盘
         2、每次变更都 IO，影响性能
         3、系统决定

重写策略优化：4.x以前是把数据集操作指令落地，新版是异步线程以rdb形式落地，重写压缩的同时，主线程记录重写过程中的增量，重写结束将增量拼进去，保证过程中的数据完整性

重写策略 ，fork 一个子线程进行 aof 重写， 会把一些重复的命令进行优化  

劣势：文件体积大，恢复慢

执行流程

自身内存存储，无需磁盘IO

每种类型有独特的计算方式，很多统计类方法，实现计算向数据移动，具有IO优势

redis底层提供了动态字符串(SDS)、跳表(skiplist)、压缩列表(ziplist)等数据结构来高效访问数据

activeExpireCycle

时长和频率随机检查过期，对数据一致性有风险

2.8之后可以自定义设置频率

expireIfNeeded

CPU友好，内存不友好

master过期删除，将命令AOF记录，直接通知slave执行删除，达到数据一致，避免了绝对时间误差。

若slave升级为master，AOF还未同步命令，会重新执行淘汰key的策略，保证一致性

一段时间之内，使用次数最少（频率）

标准的 LRU（非 redis） 是一个链表，根据实时访问，更新数据在链表的位置，需要淘汰则直接把链表尾部去除

redis 如果采用链表，数据结构会变更复杂，数据的移动开销增加，导致性能降低。故采用近似 LRU 的算法实现

每一个 KV 中的 V，都是一个 Redis Object，额外记录了访问的LRU时钟信息(精度1s)，最近的一次时间戳

淘汰过程

主从复制集群（手动切换）

带哨兵的HA的主从复制集群（故障自动切换）

解决性能问题，但存在数据一致性问题

客户端实现路由索引

中间件代理层实现

redis自身实现的cluster

salve初始化阶段，master生成RDB文件，并同时开启缓存区记录增量

向所有Slava服务器发送RDB文件，并在发送期间继续在缓冲区内记录被执行的写命令

slave服务器收到RDB快照文件后，会将接收到的数据写入磁盘，然后清空所有旧数据

master服务器发送完RDB快照文件之后，便开始向slave服务器发送缓冲区中的写命令

salve继续执行缓存区命令（开启AOPF则进行重写）

master产生一个命令，则发送一个命令

2.8之后会进行断点续传，之前是全量复制

master在内存缓冲区中给每个slave都维护了一份同步备份日志，缓存最近一段时间的数据

master 和 slave 都维护了一个复制偏移量（replication offset）和 master线程ID（master run id），
每个同步都会携带master run id 和 最后一次同步的复制偏移量offset
通过offset可以知道主从之间的数据不一致的情况。

2.8以前：master会将数据保存在磁盘的rdb文件中然后发送给slave服务器

2.8之后：内存中创建RDB文件，再将rdb文件发送给slave服务器，不使用磁盘作为中间存储（省IO）

repl-diskless-sync ：是否开启无磁盘复制

在关闭master服务器持久化机制并开始自动重启的情况下，会造成主从服务器数据被清空的情况。也就是master的持久化关闭，可能在master宕机重启的时候数据是空的（RDB和AOF都关闭了），此时就会将空数据复制到slave ，导致slave服务器的数据也丢了

若是哨兵模式，master重启较慢，则savle会当选为master，数据则不会清空。
若重启很快未发现宕机，salve立马重连，则有数据丢失风险

生产消息--delayedQueue.offer

延迟任务 ScheduleTask 计时器

初始化  redissonClient.getDelayedQueue(blockingQueue)

获取  blockingQueue.take()

生产阶段保证

存储阶段保证

消费策略

配置

1、生产者发送消息（可指定 topic、partition、key、value），生产者会把消息序列化为字节数组

2、分区器对消息进行分区

3、分好区会把消息发送到 broker，broker 会进行 OS Cache的写入，并返回给生产者是否成功

优势

劣势

海量数据，日志分析收集，可接受丢数据

磁盘

减少网络 io

分区

触发条件

三个分配策略

过程

分区很多，rebalance 会很慢，轻易不要高峰时期触发  （通过 assign 指定了分区 则不会触发rebalance）

优势

双11，可靠性+大并发，对交易可靠性有很高要求

优势

劣势

数据量小，实时性高，轻便

利用超时和死信队列做延时队列

如果一条消息在 TTL 设置的时间内没有被消费，那么它就会变成一条 Dead Letter(死信)。

ABC 联合索引  AC查询A 有效C失效。 BC查询 均失效

like 左模糊匹配 破坏了最左原则

计算、函数、类型转换(自动或手动)导致索引失效

in not in != 范围小会走索引，范围过大会失效(20%)

好处：拆分大数据量，提高性能

坏处：逻辑设计复杂、很难join操作、事务问题、分布式id

ShardingSphere 首选

基于主从复制 依赖与binlog

canal也是依赖于binlog ，更方便

DATA_TRX_ID

主键列

RR 隔离级别下，开始的第一个 select 会生成一个 readView，后续所有语句复用  （形成快照）

RC隔离级别下，每一个 select 都会生成一个 readView，刷新当前快照

1-3层  约2千万数据

叶子节点存放数据，非叶子存放指针，非叶子节点通过二分法确定数据在哪个叶

查询字段被联合索引包含，可减少回表次数

Innodb存储引擎会监控对表上二级索引的查找，如果发现某二级索引被频繁访问，二级索引成为热数据，建立哈希索引可以带来速度的提升

2个以上事务 并发插入相同数据

T1成功插入，T2T3紧接着插入，请求插入意向锁

因发生重复唯一键冲突，请求的排他记录锁转换为共享记录锁

T2T3 都需要争抢排他锁，但需要对方先释放共享锁，产生了死锁

防止一秒内多条重复插入。（按钮防抖 + 2s 内请求幂等防止 slb 重试）

保持事务简短并在一个批处理中

select for update 高并发场景也会死锁，两个线程都拿到间隙锁，获取插入意向锁要等待对方释放间隙锁

innoDb 边扫描边加锁，如果 where 条件是非主键索引，会锁住索引，再去锁主键索引

假如线程A对a b c d e五条数据边扫描边加X锁，而同时线程B对 e f g h a五条数据也边扫描边加X锁

A 锁到 e 会等待 B 释放，B 锁到 a 会等待 A 释放 造成死锁

更新场景使用主键更新，只锁一行数据，不会死锁

事务手动提交，update 之后挂了，没提交，会一直有行锁

一个索引划分多个主分片，分不到不同的节点，提高性能

官方默认一个实例节点，同时最多跑5个分片，每一个分片建议数据量30G

和主分片保持同步，分散节点进行容错，读能力横向扩展

不可变索引

动态索引

多个段文件最终会压缩合并，写入磁盘

每次请求执行刷盘

每隔5s 刷一次

超过阈值

每30min分片自动flush

所以分片越少，查询效率越高

es 节点可以配置节点属性为 hot/cold

可以通过定时任务，定期把过期的数据索引属性改为 cold，节点会自己处理数据的迁移

热节点配置调高

帖子放冗余计数 提高响应速率

回复平铺设计--帖子 id 索引，主评论 id 索引，满足多种查询场景

热搜打分设计

未读已读设计

异步敏感词校验+NLP 的语言识别

隐藏限流 + 报警

各大经典场景的对比和方案确定

ES>=5.0 支持 search after

保证了健壮性，但性能会降低。0容忍业务适用

缺省协议，采用单一长连接和 NIO 异步通讯，Hessian2 序列化，适合于小数据量大并发的服务调用。
不适合传送大数据量的服务。

RMI协议采用阻塞式(同步)短连接， JDK 标准序列化方式，Serializable-OutStream。
适用数据包大小混合，消费者与提供者个数差不多，可传文件。

底层采用Http通讯(同步)，hessian 序列化，采用Servlet暴露服务。
适用于传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。

JSON 序列化