volatile可以实现内存的可见性和防止指令重排序。
通过内存屏障技术实现的。
为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障指令，内存屏障效果有：
volatile 修饰变量指令的重排序sychronized能实现有序性和可见性，但不能防止指令重排（所以单例模式中即使使用了双重锁检查，也需要使用volatile关键词（new 操作分三步，如果指令重排了可能会先把对象指向空的内存区域，导致其他线程使用异常））
https://juejin.im/post/5ae6dc04f265da0ba351d3ff
https://juejin.im/post/5aeb07ab6fb9a07ac36350c8
公平锁与非公平锁的差别是公平锁在请求锁时判断AQS中当前节点是否有前驱节点，如果有，说明有更早的线程在等待锁
https://juejin.im/post/5aeb0a8b518825673a2066f0
https://juejin.im/post/5aeb0e016fb9a07ab7740d90
包含三个概念：写锁、乐观读、读锁。其中读锁和写锁等同于ReentrantReadWriteLock，乐观读相当于数据库中的乐观锁，在读完后判断版本号（stamp）是否过期，如果过期了，就升级为读锁。在多读少写的场景下，性能更胜于ReentrantReadWriteLock。该锁的非可中断方法对中断的响应有bug，会导致CPU100%，如果有响应中断的需求，需要使用可响应中断的方式获取锁。
http://www.cnblogs.com/xrq730/p/5060921.html
CyclicBarrier
CountDownLatch
死循环原因：在多线程环境下resize导致形成环形链表，get操作时将死循环
HashMap扩容每次都是按原大小两倍扩容的原因：https://segmentfault.com/q/1010000020673403/a-1020000020676787
https://juejin.im/post/5e5283abf265da573d61a311
双亲委托加载机制：类加载器遇到一个加载需求时，会将其委托给父加载器进行加载，如果父加载器没有加载，再由当前类加载器进行加载。方便在加载一些基础类如Object类时，不同子类加载器均加载了该类而导致各种问题（不同类加载器加载了同一个class，也视为不同类型）
过程：
CMS缺点：
当使用大内存服务器时建议使用该回收器，通过-XX:MaxGCPauseMillis可以设置每次GC停顿的最长时间，来防止需要回收大量垃圾时STW太长导致业务异常
过程：
Shenandoah并发整理通过转发指针来实现，在每个对象上标记其需要转发的位置，在没有重分配时，转发指针指向自身，当进行重分配时，转发指针指向重分配后的地址。转发指针需要使用读前屏障来实现，所以会影响GC时的吞吐，导致GC时长变长。https://juejin.im/entry/5b86a276f265da435c4402d4
JDK11引入的新垃圾收集器，可以回收超大堆（达到数T）并保证10ms以内的停顿。
与标记对象的传统算法相比，ZGC在指针上做标记，在访问指针时加入Load Barrier（读屏障），比如当对象正被GC移动，指针上的颜色就会不对，这个屏障就会先把指针更新为有效地址再返回，也就是，永远只有单个对象读取时有概率被减速，而不存在为了保持应用与GC一致而粗暴整体的Stop The World。
染色指针来实现并发整理算法，通过占用指针中的4个bit来标记当前引用对象是否处于重分配状态，当读屏障拦截到染色指针时，会进行自愈过程，即查询记录并将指针指向新的地址，所以只会影响重分配内存后的第一次访问。并且由于染色指针的映射关系不记录在对象本身，所以原内存可以立刻被用来使用。过程：
G1优势：可以设置GC停顿时间；通过标记-整理/复制算法实现，没有内存碎片；
CMS优势：只需要维护老年代到年轻代的Remember Set，但G1每个region无论是什么代都需要维护一份Remember Set，内存占用更高；都使用了读后屏障维护Remember Set，但是CMS的RSet更轻量级，性能消耗更小；G1通过原始快照方式来处理并发标记时的指针变化问题，CMS使用增量标记方式，性能消耗更小。
https://segmentfault.com/a/1190000006824196?utm_source=tuicool&utm_medium=referral
https://zhuanlan.zhihu.com/p/23488863
https://javadoop.com/post/spring-ioc
prepareRefresh() 准备工作，设置启动状态，处理配置文件占位符等
obtainFreshBeanFactory() 将需要的Bean解析成BeanDefinition并注册到BeanFactory中
invokeBeanFactoryPostProcessors(beanFactory) 调用所有的BeanFactoryPostProcessors.postProcessBeanFactory
registerBeanPostProcessors(beanFactory) 注册ProcessBeanProcessor
initMessageSource() 处理国际化资源
initApplicationEventMulticaster() 初始化事件广播
onRefresh() 初始化bean之前的预留的拓展点（模板方法）
registerListeners() 检查和注册事件监听器
finishBeanFactoryInitialization(beanFactory) 初始化所有的非懒加载单例
InstantiationAwareBeanPostProcessor#postProcessBeforeInstantiation， 给某些BeanPostProcessors执行的机会来返回bean的代理，如AOP(并非所有AOP均在此处实现)https://javadoop.com/post/spring-aop-source
https://www.infoq.cn/article/jlDJQ*3wtN2PcqTDyokh
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。
当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。
服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。
如果在一定时间内超过85%的节点没有正常心跳，那么Eureka认为客户端与注册中心的网络出现故障，Eureka进入保护模式，不再剔除任何服务哪怕长时间没有收到其心跳；该阶段仍接受新服务的注册和查询，但不会同步到其他节点上；当网络稳定后再将新注册信息同步到其他节点中。
创建Bean的时候，每次创建完对象实例(对象A)，在进行参数设置之前，会将当前对象（还没有赋值完毕的Bean，也称为早期引用）先缓存起来；在参数赋值时，需要创建其依赖的对象，如果这个依赖的对象(对象B)正好依赖了当前需要被赋值的Bean，其可以从缓存中获取到其早期依赖，那么这个被依赖的对象(对象B)就能顺利初始化完成，随后对象A也可以被顺利初始化完成。
根据上述原理，一般情况下的依赖都可以解决循环依赖的问题，但是前提是只有创建完对象实例后才会被缓存，所以如果在调用构造方法时循环依赖，会导致无法创建实例，也就无法得到缓存起来的早期引用了。
BeanFactory实现了IOC容器最基本的功能，其定义了一系列getBean接口，通过这个方法可以获取容器所管理的Bean。ApplicationContext继承了BeanFactory，在BeanFactory的基础上扩展了一些功能，例如国际化、资源访问、事件发布等。其也是Spring框架的基础，提供了各种扩展能力。
ApplicationContext中getBean接口的实现都是委托给内置的BeanFactory对象，例如使用最多的DefaultListableBeanFactory。
https://juejin.im/post/5de3c8026fb9a07194761641
http://www.itpub.net/2019/11/27/4449/
https://itzones.cn/categories/rocketMQ/
NameServer集群相当于精简版zooKeeper，用来注册topic与broker信息。NameServer之间不进行通讯，只与broker维持心跳，即broker定时上报其所负责的topic数据。broker中所有元数据存储到其中。单个文件最大1G，该broker中的所有topic共用此文件，所有的元数据顺序写入，写入性能高Group，Topic以及Consumer消费offset等信息。commitLog的索引。消费者按序consumeQueue文件，再通过每一条记录中的offset去commitLog中读取元数据。客户端发送消息给broker时，broker将所有topic的数据写入同一个commitLog文件，在多个topic情况下顺序写入性能仍很高（对比kafka每个topic一个文件）。写入完成后，定时任务会不断扫描commitLog中的数据，将其写入到对应的consumerQueue中。
客户端读取对应的consumeQueue文件，此过程为顺序读取可以利用操作系统PageCache，性能较高。通过读取到的记录中对应的元数据offset，可以在commitLog文件中找到对应的元数据。
在读取过程中，在通过offset读consumeQueue文件时会出现随机读，没有办法很好命中缓存，所以性能较差，主要通过Java文件映射（mmap）的方式，可以将文件直接映射到用户态内存地址，读写文件相当于是内存读写操作，将带来良好的性能。这种方式比较消耗内存，所以在主从模式下， 当master机器内存占用超过40%时，读请求将会转发给salve节点。
master宕机时不可写入，可以从slave读取master宕机时，该机器上面的数据不可读，如果Topic分布在多台master上，那么其余的master可以读写master宕机，只会导致该master不可写入，可以从salve读取；如果Topic分布在多台master上，那么其余的master可以读写broker上数据的冗余，当master宕机不可恢复时保证数据不丢失（或很少丢失）master宕机，客户端可以连接salve节点进行消费；生产者也可以连接topic对应的其他broker节点进行发送master有消息堆积时（内存使用超过40%）会将读请求转发到salve节点，减轻master节点的压力http://www.itpub.net/2020/01/07/5010/
为了防止某台master出现消息堆积而导致大量消息超时，RocketMQ使用了快速失败机制。通过一个定时任务，每隔10ms扫描队列中第一个节点，如果排队时间超过200ms（可配置），就会把等待时间超过该值的任务全部返回失败。而客户端将会捕获失败而进行重试，可以在其他master机器上进行重试。
https://www.javadoop.com/post/netty-part-1
信号量模式将接受请求与请求下游接口放在同一个线程中执行，即请求下游接口时不创建新的线程执行，没创建线程与上下文切换带来的开销，只通过maxConcurrentRequests参数限制最大并发数。
线程池模式将请求下游接口放到线程池中执行，可以异步执行多个下游接口。
https://juejin.im/post/5dc3a9fbf265da4d3c072eab
主从模式、哨兵模式、集群模式
https://juejin.im/post/5b7d226a6fb9a01a1e01ff64
当需要选举主节点时，需要选举一个哨兵（Sentinel）节点为Leader。每个哨兵节点会要求其他哨兵节点选举自己为Leader，如果被请求的节点没有参与过选举，则将同意其请求，即发起请求的节点票数+1；否则不同意其请求，票数不变。
如果某个哨兵节点的得票数大于一半，则其成为Leader。如果没有超过一半的节点，则重新选举。
https://mp.weixin.qq.com/s/zjwiOkRFvQDpKfeFL1-dUQ
一个redis集群包含2^14=16384个哈希槽，集群中的每个节点会分配到一部分槽，如下图
集群使用公式 CRC16(key) % 16384 来计算每次请求的键 key 属于哪个槽，再通过槽对应节点配置，就可以找到key所对应的数据应该请求哪一个节点。
这种方式很方便进行扩容和缩容，例如：
如果用户将新节点 D 添加到集群中，那么集群只需要将节点 A 、B、C 中的某些槽移动到节点 D 就可以了。
与此类似，如果用户要从集群中移除节点 A ，那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ，然后再移除节点 A 就可以了。
例如A节点的X槽迁移到B节点
MIGRATING B，此时A节点X槽状态设置为**MIGRATING**IMPORTING A，此时B节点X槽状态设置为**IMPORTING**原子性的，也就是一个key要么还在A节点中，要么已经迁移至B节点中，不会同时存在ASK指令，客户端将使用ASKING指令重新请求B节点；这能保证A节点中key数量只减不增，B节点key只增不减UPDATE指令给所有节点，通知其更新槽对应的节点信息，后续的X槽指令将全部被重定向（MOVED指令）到B节点https://juejin.im/post/5e6df710e51d4526fc74b4ec
SET key random_value NX PX 30000在集群模式下，如果在master节点上获取了锁，但是数据还没来得及同步到到slave节点主节点就挂了，故障转移后，从新的master节点将可以获取到一个新的锁，出现了一把锁被两个线程持有的问题。
上锁：在集群模式下，即有N个节点的情况下，通过一个统一key+随机值的方式，向N个节点获取锁。只要有N/2+1个节点加锁成功，则视为获取锁成功，否则需要进行解锁。
解锁：依次向每个节点发起解锁操作，即便这个节点上没有上锁成功。
风险点：当某个节点上锁成功，但是故障重启后，可能会丢失数据从而导致其他客户端可以重复上锁成功。例如三个节点中有两个加锁成功一个加锁失败，加锁成功数大于等于N/2+1，所以视为上锁成功。此时加锁成功的一个节点故障重启并丢失了数据，此时如果有客户端申请加锁，将可以获取锁成功。
https://zackku.com/redis-rdb-aof/
定时把数据的快照保存到文件中，由于是某个时间点的快照，所以可能会丢数据，但是持久化和加载性能更高，文件数据更小。
将每次的操作记录写入到缓冲区，根据策略（每次刷盘、每秒刷盘、等操作系统自动刷盘）将记录追加到文件上。
由于记录每次操作，日志文件冗余，加载速度会很慢，所以可以开启日志重写，例如将多次INCR操作合并成一次SET操作。
AOF相对于RDB可靠性更高，但是默认刷盘策略为一秒一次，仍不能保证数据绝对安全；AOF记录的是操作日志，所以可读性更高，即使文件被部分破坏，也容易恢复到某个数据节点；但是存储的文件更大，写入和加载性能效率低于RDB
| Redis | 底层数据结构 | 备注 |
|---|---|---|
| string | 当存储值为整数时，使用int 当存储值为字符串且小于32字节，使用embstr，即优化后的 SDS当存储值为字符串且大于32字节，使用raw，即SDS |
SDS为包装后的char数组浮点数也通过char数组，需要计算时转成浮点数计算，计算完转成char数组保存 SDS中最大只能保存512M数据 |
| list | 3.2版本前&数据较少时，使用ziplist 3.2版本前&数据较多时，使用linkedlist 3.2版本后，使用quicklist |
ziplistlinkedlistquicklist |
| hash | hashtable |
hashtable |
| set | 当所有元素为整数&个数小于512时，使用intset其他情况，使用 hashtable |
intset |
| zset | 当元素较少时，使用ziplist + hashtable当元素较多时，使用 skiplist + hashtable |
skiplist使用 skiplist + hashtable是为了利用查询时hashtableO(1)时间复杂度和排序时skiplistO(logn)时间复杂度的优势 |
noeviction(默认策略)：对于写请求不再提供服务，直接返回错误（DEL请求和部分特殊请求除外）
allkeys-lru：从所有key中使用LRU算法进行淘汰
volatile-lru：从设置了过期时间的key中使用LRU算法进行淘汰
allkeys-random：从所有key中随机淘汰数据
volatile-random：从设置了过期时间的key中随机淘汰
volatile-ttl：在设置了过期时间的key中，根据key的过期时间进行淘汰，越早过期的越优先被淘汰
可以操作一个值中的二级制位，可以用来实现布隆过滤器
可以存储位置，并通过目标位置的距离查询指定距离范围内的数据，例如实现附近的人。
适合用来统计一个集合中不重复的元素个数，但不要求数据完全准确的情况，例如访问UV等。
一亿个统计数据约只占12M内存。
https://draveness.me/mysql-innodb
MySQL索引背后的数据结构及算法原理（包含B树和B+树原理）http://blog.codinglabs.org/articles/theory-of-mysql-index.html
互斥锁、共享锁、意向互斥锁、意象共享锁
什么是意象锁
如果没有意向锁，当已经有人使用行锁对表中的某一行进行修改时，如果另外一个请求要对全表进行修改，那么就需要对所有的行是否被锁定进行扫描，在这种情况下，效率是非常低的；不过，在引入意向锁之后，当有人使用行锁对表中的某一行进行修改之前，会先为表添加意向互斥锁（IX），再为行记录添加互斥锁（X），在这时如果有人尝试对全表进行修改就不需要判断表中的每一行数据是否被加锁了，只需要通过等待意向互斥锁被释放就可以了。
如果where 条件中包含主键索引或其他索引作为过滤条件，那么将在B+树中找到对应记录并上锁，即为Record Lock；
如果没有索引，那么只能进行锁表。
当where条件中存在范围条件时（必须有索引，否则仍为表锁），例如where id between 10 and 20，将会上Gap Lock。
Next-Key Lock算法，锁定的不是单个值，而是一个范围（GAP）。上面索引值有1，3，5，8，11，其记录的GAP的区间如下：是一个左开右闭的空间
（-∞,1]，(1,3]，(3,5]，(5,8]，(8,11]，(11,+∞）
Next-Key Lock是Record Lock和Gap Lock的组合，即锁住范围的同时锁住区间，在RR(REPEATABLE-READ)隔离级别下, SELECT ... FOR UPDATE使用Next-Key Lock, 即Record Lock + Gap Lock.
在一些场景下Next-Key Lock会退化
| 场景 | 退化成的锁类型 |
|---|---|
使用unique index精确匹配(=), 且记录存在 |
Record Lock |
使用unique index精确匹配(=), 且记录不存在 |
Gap Lock |
使用unique index范围匹配(<和>) |
Record Lock + Gap Lock 且 锁上界不锁下界 |
官方文档：https://docs.oracle.com/cd/E17952_01/mysql-5.0-en/innodb-record-level-locks.html
带翻译版：https://cloud.tencent.com/developer/article/1447138
在多个SQL以不同顺序申请锁时，可能会产生死锁，例如:
使用索引A（非主键）进行更新时，如果恰巧有其他sql通过主键更新A字段时，将有可能死锁。因为通过非主键更新时，会先将A（辅助索引）上锁，再找到其主键上锁；通过主键更新时，会先对主键上锁，如果发现需要更新的字段为辅助索引（如A索引）时，再将辅助索引上锁，此时就会导致死锁。
如果在辅助索引中（例如(user_id,user_name)），不包含所要查询的字段，例如 select user_name,sex from tb_user where user_id = xxx语句中，需要查询user_name和sex，但是在该索引中不包含sex字段，所以需要通过辅助索引找到主键，再通过聚集索引找到完整数据才能获取到sex字段，这个过程即为回表 。
上文回表可以看出，回表操作需要额外通过主键索引找到完整数据的过程，比不回表的操作多了一次IO，所以可以尽量避免此类消耗。例如将常用的查询字段放入索引中，若索引中的字段涵盖了要查询的所有字段，即为索引覆盖。不过会增大索引的空间造成浪费，通过空间换时间，需要根据业务场景选择。
索引下推可以在范围查询或like查询情况下，减少回表操作。
例如有a,b两个字段，建立 (a,b) 联合索引，执行 select * where a > 0 and b >0
正常情况下，只能用到a字段的索引，因为B+树中只能通过前缀匹配范围查询。通过筛选 a>0条件后，进行回表操作，再筛选出 b>0的记录
可以发现，这种方式回表的数据较多，其实可以做一次优化，在筛选完a>0后，再进行一次b>0筛选，这样回表的数据就少多了，这种优化方式成为索引下推，MySQL中默认开启。
回表操作，请求量大的SQL可以考虑进行索引覆盖LIMIT，因为LIMIT能尽可能保证进行内存排序而不是文件排序，参见LIMIT优化计划任务中出现Using filesort表示需要额外排序，但不一定是文件排序，也有可能是内存排序
where条件的记录sort buffer，例如(id+key)sort buffer能存放下所有的记录，则在内存中使用快速排序；如果放不下，就需要放入文件中，使用归并排序limit则进行过滤；如果需要回表，则执行回表例如Order by limit M,N，虽然所有元素都要参与排序，但是在sort buffer中只需要能放下N+M个元素即可在内存中使用堆排序，而不需要进行文件排序，减少IO提高性能。
此处注意甄别数据库规范与InnoDB具体实现之间的差异，此处指InnoDB的具体实现
不可重复读是指在一个事务中，已加锁的记录第二次读取时与之前的内容不同，但数量不变，即可能被update
幻读是指在一个事务中，已加锁的数据第二次读取时结果集数量不同，即可能被insert或delete。官方链接：https://dev.mysql.com/doc/refman/8.0/en/innodb-next-key-locking.html
https://www.cnblogs.com/itcomputer/articles/5133254.html
https://chenjiayang.me/2019/06/22/mysql-innodb-mvcc/
https://www.cnblogs.com/naci/p/3753644.html?utm_source=tuicool&utm_medium=referra
MVCC (Multiversion Concurrency Control) 中文全程叫多版本并发控制，是现代数据库（包括 MySQL、Oracle、PostgreSQL 等）引擎实现中常用的处理读写冲突的手段，目的在于提高数据库高并发场景下的吞吐性能。用来实现InnoDB中的RC和RR级别。
在每一行数据中，增加了两个隐藏字段，分别是DATA_TRX_ID和DATA_ROLL_PTR，DATA_TRX_ID表示更新这条记录的事务id，事务id为每次开启事务时分配的id，保证先开启事务的事务id小于后开启的事务。DATA_ROLL_PTR为指向指向undo log中该行之前版本的指针。
在每次更新，把需要更新的行数据原样拷贝到undo log中；再修改表中改行的值，并把DATA_TRX_ID的值设置为当前修改事务id、DATA_ROLL_PTR设置为undo log行所在的地址；
插入操作仅需要把新插入的行中DATA_TRX_ID设置为当前事务id即可；
删除操作与更新操作的差别为需要修改需要删除行的删除标记为已删除；
在执行select操作时，将当前系统中所有的活跃事务id拷贝到一个列表中，生成一个ReadView。其中的事务id称为m_ids。
在RC中，每一个select均会生成一个ReadView；RR中，只在每个事务的第一次select生成ReadView。
trx_id 小于 m_ids 中的最小值，说明生成该版本的事务在 ReadView 生成前就已经提交了，所以该版本可以被当前事务访问。trx_id 大于 m_ids 列表中的最大值，说明生成该版本的事务在生成 ReadView 后才生成，所以该版本不可以被当前事务访问。需要根据 Undo Log 链找到前一个版本，然后根据该版本的 DB_TRX_ID 重新判断可见性。trx_id 属性值在 m_ids 列表中最大值和最小值之间（包含），那就需要判断一下 trx_id 的值是不是在 m_ids 列表中。如果在，说明创建 ReadView 时生成该版本所属事务还是活跃的，因此该版本不可以被访问，需要查找 Undo Log 链得到上一个版本，然后根据该版本的 DB_TRX_ID 再从头计算一次可见性；如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。ReadView 来说的可见结果。此时，如果这条记录的 delete_flag 为 true，说明这条记录已被删除，不返回。否则说明此记录可以安全返回给客户端。数据写操作走主库，读操作走从库，实现读写分离。所有写操作记录写入binlog，从库通过一个IO线程将主库binlog同步至本地，再将内容写入relay log。从库中的SQL 线程将读取relay log将其顺序执行，实现数据变更从主库同步到从库的过程。
主库与从库间的数据延迟的可能原因
binlog从主库同步到从库是异步的，外加需要同步完成后再重新执行binlog，天然存在延迟binlog没来得及同步到从库半同步复制：主库在提交完事务后，不直接返回给客户端，而是等待至少一个从库接受并写入到relay log后才返回。保障了数据的安全性，但是会导致用户请求的延迟。并行复制：从库可以开启多个线程读取relay log中不同库的日志，实现库级别的并行总结：ZK适合在不需要高TPS支持的业务场景下处理分布式锁、分布式选主、主备切换等；如果在高TPS链路上、大规模数据存取、服务发现、健康检查等方便并不适合。
https://www.cnblogs.com/laoqing/p/12091471.html
https://segmentfault.com/a/1190000019959411
HMaster：负责Region的分配；表结构创建修改等操作；通过ZK监听管理RegionServer
RegionServer：管理Region，每个RegionServer可管理1000个Region；处理Region的读写请求；切分过大的Region
Region：Table中的数据根据rowKey的范围被水平分割存放在多个Region上
HBase中的一张特殊的表，用来存放RowKey与RegionServer的关系Write Ahead Log 是HDFS中的一个文件，也称为HLog。同一个RegionServer共用同一个WAL文件，所有写操作信息会被优先写入WAL文件MemStore后即视为写入成功，后续根据一定策略进行刷盘（flush如HDFS）（类似与操作系统中的PageCache）。每个Column Family都会对应一个MemStore
WALMemStore由于WAL文件写入采用append方式，所以为顺序写入，性能很高。在成功写入WAL后再写入MemStore保证机器宕机掉电导致MemStore中数据丢失，也可以通过WAL文件恢复丢失数据。
当MemStore中积累一定数据后，每个MemStore会往HDFS上写入一个新的HFile，当一个MemStore满了，内存中的所有MemStore都会被flush到HDFS中
每次MemStore刷盘操作都会生成新的HFile，过多HFile会导致读性能问题，需要通过压缩来解决
HFile将其合并成较大的HFile，这个过程不会处理已经删除或失效的数据。Region中的所有HFile合并成一个大的HFile（每个Column Family仍为独立的HFile），由于Major Compaction对机器的IO等影响较大，所以一般在低峰期计划执行。一张表刚开始只有一个region，当数据变多变大时，它会分裂成两个region，各自包含原来的一半数据。出于负载均衡考虑，HMaster会将新生成的region迁移到其他HRegionServer中，此时的迁移只是逻辑上的，也就是说只是把新的region交给其他HRegionServer管理，但数据仍在原处，所以此时HRegionServer需要访问不在本地（本机）的数据而影响性能。等到下一次Major Compaction可以将数据移到HRegionServer附近存储解决问题。
ZK处查询MetaTable所在的HRegionServerHRegionServer获取MetaTable，根据MetaTable确定RowKey所在HRegionServerHRegionServer查询数据在查询HRegionServer的具体查询过程如下：
BlockCache中查询MemStore中查询HFile，由于查询HFile涉及到磁盘IO会影响性能，所以会通过BlockCache中的索引和布隆过滤器进行查询优化。由于每一个RowKey存在多个历史版本，所以一次读操作可能需要查询多次，而每个版本数据可能会在不同HFile上，会影响性能，这被称为读放大。
当某个RegionServer宕机时，该节点与ZK的链接会断开，此时HMaster将会监听到此事件，HMaster开始自动进行故障恢复：
RegionServer管理的region分配给其他健康的RegionServerMemStore中并没有刷盘，此时需要将WAL日志按Region进行切分Region执行日志回放进行数据恢复HDFS作为底层数据存储，保障数据安全性WAL进行数据恢复保证高可用Major Compaction会占用大量I/O资源https://zhuanlan.zhihu.com/p/86426969
三次握手是指服务器与客户端建立一个TCP链接一共需要通讯三次，目的是为了互相确认彼此的接受和发送能力均正常。
| 次序 | 发包方向 | 发送信息 | 能力确认 | 是否可携带数据 |
|---|---|---|---|---|
| 第一次 | 客户端->服务端 | SYN=1,seq=x | 客户端发送能力正常 | 否 |
| 第二次 | 服务端->客户端 | SYN=1,ACK=1,ack=x+1,seq=y | 服务端发送能力、接受能力正常 | 否 |
| 第三次 | 客户端->服务端 | ACK=1,ack=y+1,seq=x+1 | 客户端接受能力正常 | 是 |
服务器端在收到客户端发来的第一次SYN报文后，会处于SYN_RCVD状态，服务器会将这种状态的连接放入队列中，称为半连接队列。在这个队列中的连接如果等待一段时间没有收到客户端的确认包，将会进行重传直到达到最大重传次数，然后会被从半连接队列中移除。
针对这种机制，有可能受到SYN攻击，即客户端发起大量SYN请求，导致半连接队列被占满并且不断进行重试，最终导致网络瘫痪。
完成三次握手的连接，将会放入全连接队列中。
断开连接需要四次通讯，因为断开连接需要连接双方各主动发起一次结束报文，证明发起方不再向对方发送数据了，并且每一次发起对方均需要响应，所以一共有四次通讯。
| 次序 | 发包方向 | 发送信息 | 当前状态 |
|---|---|---|---|
| 第一次 | 客户端->服务端 | FIN=1,seq=i | 客户端停止发送数据 |
| 第二次 | 服务端->客户端 | ACK=1,ack=i+1,seq=j | 服务端停止接受数据 |
| 第三次 | 服务端->客户端 | FIN=1,ACK=1,ack=i+1,seq=k | 服务端停止发送数据 |
| 第四次 | 客户端->服务端 | ACK=1,ack=k+1,seq=i+1 | 客户端等待2MSL后关闭并进入CLOSE 服务端接受后直接进入CLOSE |
MSL（Maximum Segment Lifetime）表示一个报文在网络传输时最大生命周期，如果超过这个时间，就算被接受到，报文也会被丢弃。
第四次挥手时，客户端的ACK报文在传输中可能会丢失，服务器会要求客户端进行重传，如果客户端立即进入CLOSED，将没有能力响应，从而导致服务端无法正常CLOSED。等待2MSL表示服务端已经无需客户端进行重传了，则可以关闭。
host字段header中数据重复传输HTTP数据传输完全明文，容易被抓包和劫持；HTTPS使用TLS（SSL的新版本）来保证安全传输，数据加密传输。
HTTPS过程：
https://www.javadoop.com/post/HashedWheelTimer
将一个轮盘分为512格，每一格跨度100ms。每个任务根据执行时间放入对应的格子里，并计算其轮次。每次循环到下一个格子时，先计算距离当前格子的执行开始时间，如果还没到，则sleep到目标时间，然后按顺序执行这个格子中轮次为0的所有任务，轮次不为0的任务全部自减；如果已经超过这个格子的deadline，即开始时间+100ms，则直接跳过这次执行。
例如1000ms后执行的任务，需要放到(1000/100)%512=10号格子中，轮次为0；513000ms后执行的任务，需要放到(513000/100)%512=10，轮次为1；
可以发现1000ms和513000ms后执行的任务放在了同一个队列中，但是轮次不同，第一次执行当10号格子时，100ms任务轮次为0，正常执行；513000ms任务轮次自减成0，下一次轮到的时候就可以执行了。
正常情况下，每个格子只有100ms的执行窗口期，但是在执行过程中不会判断是否执行超时，只有全部执行完，走到下一个格子时，会判断是否超过当前格子的deadline。如果超过了，将直接执行当前格子对应的任务。
执行所有任务的线程是单线程的，如果每个格子中的任务执行时间之和超过100ms，后续的所有任务将会受到影响，所以尽量不要提交执行时间很长的任务到HashedWheelTimer中。
LRU全称是Least Recently Used，即最近最少使用。当缓存需要清理时，清除最近一段时间没有使用过的数据。
数据结构：双向链表+哈希表
算法复杂度：一般情况下为O(1)，特殊情况下由于哈希碰撞严重，可能会退化为O(N)
通过一个双向链表存储所有的节点，如果某个数据被访问，那么将该节点移动到链表最开始，需要淘汰时，将链表最后一个节点移除。为了方便查询，在哈希表中存储的数据结构为key:(value,point),其中point表示该数据在链表中的指针，方便移动时能快速找到链表中的节点。
LFU 即Least Frequently Used，最近最少使用。当缓存需要清理时，清除最近使用次数最少的数据。
数据结构：TreeMap + 哈希表 + 双向链表
算法复杂度：一般情况下为O(1)，特殊情况下由于哈希碰撞严重，可能会退化为O(N)
在TreeMap中保存访问次数与访问次数对应的数据，相同的访问次数可能对应多个数据，这些数据通过双向链表进行保存。哈希表中的数据结构为key:(value,point),其中point表示该数据在双向链表中的指针，方便修改访问次数时可以快速在链表中移除该节点并添加到新的链表中。
FIFO 即First In First Out，先进先出。当缓存需要清理时，清除最先加入缓存的数据。
数据结构：双向链表 + 哈希表
算法复杂度：一般情况下为O(1)，特殊情况下由于哈希碰撞严重，可能会退化为O(N)
通过双向链表保存数据的加入顺序，新加入的数据添加到队尾，需要清理时，移除队头数据。
https://mp.weixin.qq.com/s/gg4q_53eiHCI3OUWzN7eWg
2PC(two phase commit)的一种实现，分别需要执行预提交(precommit)和提交(commit)两个阶段，需要底层数据库支持。
缺点：
TCC分为三个操作，分别是try、confirm、cancel，其中每一个操作都是完整的本地事务。
try：尝试执行业务检查和准备操作，例如转账前检查余额，并将余额进行冻结。
confirm：如果所有从属业务try操作均成功执行，则依次执行confirm。confirm不允许业务异常，例如冻结金额不足等业务问题。如果执行失败，则将不断重试，所以需要保证幂等。例如将try操作冻结的余额进行扣除。
cancel：如果有任何一个从属业务try失败，则执行所有try成功业务对应的cancel操作。如果执行失败，将不断重试，需要保证幂等。例如将try操作冻结的金额释放。
有些情况下，不需要保证数据的强一致性，只需要保证数据的最终一致性，即允许数据在某个阶段不一致，但最终一定是一致的。
通过本地消息表+本地事务实现
例如：扣除余额业务需要修改用户余额的同时，记录一条流水记录，这两个操作均由两个子系统实现，无法使用本地事务。
可以增加一张本地消息表，每次扣除余额时，在本地消息表中记录流水，并设置状态为未处理；在记录流水记录的事务中进行余额扣除，如果扣除成功则提交本地事务；如果不成功则回滚本地事务。
如果本地事务提交成功成功，说明本地流水和余额扣除操作均成功，可以同步/异步通知流水系统记录流水，记录流水业务需要保证幂等，在一次通知不成功的情绪，将需要不断重试。
当流水系统成功记录流水后，通知主业务系统，主业务系统修改本地消息表中对应流水的状态为已完成，后续不再继续重试。
将主业务拆分成若干子业务操作为：T1, T2, T3, …, Tn
定义所有子业务操作的反操作：C1, C2, C3, …, Cn
业务按次序执行，如果全部正常执行完成，则主业务执行完成；如果执行到某个业务失败，则按次序执行反操作。
例如T1, T2, …, Tj均执行成功，Tj+1执行失败，则依次执行Cj,…, C2, C1进行业务撤销
这种方案跟TCC比较没有try&confirm的过程，例如增加余额操作没有先冻结余额再解冻金额，而是一步直接增加，会导致需要执行反操作（扣除余额）的时候，发现余额不足了，就无法正常执行反操作了。这就是事务之间没有隔离性的问题。
https://github.com/seata/seata
https://github.com/liuyangming/ByteTCC
https://www.cnkirito.moe/file-io-best-practise/
https://juejin.im/post/5d7c7a14f265da03f47c4f93
https://coolshell.cn/articles/17416.html
一般情况下，先写数据库再删除缓存，当数据已失效并有读写线程并发时，才有可能出校小概率读进程把脏数据写入缓存的情况发生。
可以通过异步MQ消息、binlog订阅更新、分布式读写锁等方式提高一致性。
更新时选择删除缓存而不是更新缓存是由于更新的数据不一定是热点数据，直接写入内存浪费空间，而且缓存数据可能是经过加工，非热点数据提前处理也浪费性能。
对性能要求高的数据可以考虑通过数据异步刷盘的方式，参考操作系统中的PageCache，数据读写全走缓存，写数据通过定时任务异步刷盘。该方案有丢数据的风险。
当大量请求（可能是非法请求）查询一个不存在的值时，由于无法命中缓存，所以这些请求全部会打到数据库层从而导致数据库问题。
解决方案：
当有大量请求查询同一个缓存值时，如果这个缓存刚好失效了，那么就会出现这些请求都会打到数据库层。同样冷启动时也可能会有这样的问题。
解决方案：
缓存雪崩可能由于缓存服务宕机、同一时刻大量缓存到期等原因造成
解决方案：
缓存击穿https://www.cnblogs.com/linbingdong/p/6253479.html
https://juejin.im/post/5ae1476ef265da0b8d419ef2
消费端限流：Sentinel 为 RocketMQ 保驾护航
https://www.cnblogs.com/rexcheny/p/9382396.html
CPU load是在一段时间内CPU正在处理以及等待CPU处理的进程数之和
CPU使用率是指进程对cpu占用的时间比例
例如只有一个进程使用一颗单核CPU，IO等待了15ms，CPU计算了45ms，那么此时的CPU load是1，CPU 使用率是75%
https://www.infoq.cn/article/kzmlUsizYFlw7F9t5jPO
一般一次读文件写文件（网络流）操作的伪代码如下
1 | File.read(file, buf, len); |
DMA：Direct Memory Access 实现主存与I/O设备之间数据交换不需要依赖CPU
期间经历了四次数据拷贝，分别为：
其中1、4部分不消耗CPU资源
其中步骤2可以省略，通过FileChannel的transferTo() 方法可以直接将数据从文件通道直接写入目标写字节通道，即数据不拷贝到用户态内存中，仅加载入内核缓冲区，所以不需要CPU参与进行数据拷贝。
Linux2.4以后进行了优化，可以将从文件中读取到内核中的数据信息追加到套接字缓冲区，此时数据将可以直接从内核缓冲区直接拷贝到协议引擎，此次拷贝不需要消耗CPU
阿里巴巴长期招人，HC无限，要求无上限、待遇无上限，欢迎加入，有意可联系邮箱：eeelinzhou@gmail.com ，其他联系方式详见关于