单表数据上亿之后，索引的查询效果可能就没那么明显了。因为B+树的层级可能会变高，定位一条数据可能要经过好几次磁盘IO加载。
以三层高度为例，一颗B+树能承载的数据量是多少？
这里只考虑聚簇索引，数据页大小16kb，假设一行用户记录大小为1kb，所以叶子节点一个数据页存放记录16条。 对于非叶子节点，一个目录项由主键id和页号组成，主键id是（bigint）8个字节，Innodb中页号指针6个字节，所以一个非叶子节点的数据页有大概 16k / (8+6) = 1170条目录项记录。
那么此时高度为3的树可以存放 1170 1170 16 约等于2000w的数据，所以2000w以内的数据的索引树高度大概是1到3层。
哪些场景会频繁full gc？
主要看下大对象的场景：
1 | !/bin/bash |
下一次响应变慢的时候，找到对应时间点的jstack日志文件，里面有很多线程阻塞在logback输出日志的过程，后来精简了log + 配置日志异步输出，则问题得以解决。
背景：
1 | update order set status = 'canceled' where created_time > '2020-01-01 08:00:00' and created_time < '2020-01-01 08:00:00' and status = 'UNPAID'; |
因为created_time是二级索引，会先给二级索引加锁，再给对应的聚簇索引加锁。（加锁步骤如下所示）
1 | update t_order set status = 'CANCELLED' where id in (2, 3, 5) and status = 'UNPAID' |
直接在聚簇索引的记录上加锁：
可以看到定时任务的sql对主键索引加锁顺序是5，4，3，2。而后台的sql对主键加锁顺序是2，3，5。
比如第一个sql对3加锁之后，尝试对2加锁时发现后台取消的sql事务已经对2加锁，而此时第二个sql又尝试对3加锁，两个sql互相等待对方的锁，也就发生了死锁。
解决办法：
问题描述：公司的后台系统，导出功能之后偶发性的发生OOM。
问题描述：在测试环境的页面速度很快，但到生产会变慢。推测访问量增大之后，对象创建变多，频繁的GC导致STW。
MetaSpace会存放静态变量和很多类的信息，在启动时如果不设置元空间大小，则默认21M。
描述一下B+树索引的结构？
什么叫做聚簇索引？
聚簇索引是指叶子节点包含完整数据列，即主键索引和其余所有数据列，innodb中以主键索引构建的B+Tree即为聚簇索引，按照主键id排序。其余的索引皆为稀疏索引。
B树和B+树的区别是什么？为什么选用B+树？
为什么不使用Hash结构来作索引？
为什么建议主键用自增id而不使用UUID？
什么是索引覆盖？什么是回表？
什么是二叉树？
数据库的索引是要求排好序的数据结构。引入了二叉查找树。
设计合理的时候可以将一组数据转化为二叉查找树，时间复杂度和二分查找一致。
但是存在设计不合理的场景：
当二叉查找树不平衡，可能退化为一个线性的链表，查找时间复杂度高了起来。
二叉搜索树可能不平衡，所以再看下平衡二叉树
相对于二叉查找树，平衡二叉树查找效率稳定。
但也有缺点：
平衡二叉树存在树过高导致的IO问题，B-Tree用来解决的思想是在每一个节点上存放多个元素，来降低树的高度，以来减少磁盘IO。
B-Tree是一个多路搜索树，m阶的B-tree有如下特性：
B-Tree中索引和除了索引之外的列是放在一起的，非叶子节点没有冗余索引，同时上层节点中索引关联的指针指向叶子节点，索引节点的左边孩子节点都比索引值小，右边节点都比索引值大。
这样的多路搜索已经降低了树的高度。
但Mysql还是采用了B+Tree。
是B-Tree的变种，也是一种多路搜索树，有几点不同：
非叶子节点不存放数据，单个节点能装下更多索引的值，降低了树的高度。
叶子节点双向指针连接，叶子节点中记录项用单向指针连接，提高了区间访问和范围查找的效率。
为什么不使用hash结构来存放索引呢？
Redis加锁性能更高，但会出现锁丢失数据不一致问题；ZK加锁性能没有那么高，但集群通过ZAB协议（写入时原子广播，故障恢复时zxid最大作为Leader节点）保证了数据一致性。
Redis主从/哨兵或者cluster模式下都是AP的，保证了可用性而采用master异步复制数据给slave，存在master加锁成功之后挂了，slave未同步master数据之后再升级为新的主节点，之前的master锁数据就丢失的场景。
Redis的Redisson实现分布式锁在重入加锁、重入解锁有锁续期逻辑，且调用默认的lock方法时会注册一个watchdog任务来完成锁续期的逻辑。所以可以支持锁续期；ZK默认不支持锁续期，当然zk是在执行完成之后去释放锁，不存在业务执行超过锁时间的问题。
zk实现分布式锁的核心原理是利用临时顺序节点和其监听Watcher机制。临时节点有些特点：
基本过程：当客户端抢到锁之后为这个客户端分配一个临时节点，只要锁没有释放就一直持有这个临时节点，当锁释放或者服务意外宕机之后，临时节点会删除，其他客户端可以继续抢占锁（创建临时节点）
未竞争到锁的客户端会阻塞等待，并会开一个监听器监听上一个节点，如果上一个节点释放了锁，那么立即得到通知去上锁。所以加锁的客户端需要感知到上一个客户端节点是谁，也就需要有顺序编号的临时节点，即临时顺序节点。
最后的释放锁就是持有锁的节点删除临时顺序节点，注册监听的其他客户端会收到通知，然后去创建自己的临时顺序节点加锁。
1 | /** |
客户端加锁入口是：1
2
3
4
5// org.apache.curator.framework.recipes.locks.InterProcessMutex#acquire(long, java.util.concurrent.TimeUnit)
public boolean acquire(long time, TimeUnit unit) throws Exception {
// 直接调用internalLock()方法
return internalLock(time, unit);
}
内部的internalLock方法（删减代码版）：1
2
3
4
5
6
7
8
9
10
11
12
13
14// org.apache.curator.framework.recipes.locks.InterProcessMutex#internalLock
private boolean internalLock(long time, TimeUnit unit) throws Exception {
// 获取当前线程
Thread currentThread = Thread.currentThread();
// 尝试加锁
String lockPath = internals.attemptLock(time, unit, getLockNodeBytes());
// 加锁成功的话就放到threadData里 是一个currentHashMap中，缓存在本地是为了锁重入
if ( lockPath != null ) {
LockData newLockData = new LockData(currentThread, lockPath);
threadData.put(currentThread, newLockData);
return true;
}
return false;
}
尝试加锁调用的internals.attemptLock方法1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27// org.apache.curator.framework.recipes.locks.LockInternals#attemptLock
// 下面是删减后的代码
String attemptLock(long time, TimeUnit unit, byte[] lockNodeBytes) throws Exception {
try {
// 创建这个锁
ourPath = driver.createsTheLock(client, path, localLockNodeBytes);
// 多个client抢锁时互斥阻塞等待
hasTheLock = internalLockLoop(startMillis, millisToWait, ourPath);
}
catch ( KeeperException.NoNodeException e ) {
//...
}
return null;
}
// createsTheLock内部逻辑
// org.apache.curator.framework.recipes.locks.StandardLockInternalsDriver#createsTheLock
// 下面代码是删减后的代码
public String createsTheLock(CuratorFramework client, String path, byte[] lockNodeBytes) throws Exception {
return client
.create()
.creatingParentContainersIfNeeded()
.withProtection()
// 就是在对应的目录下创建一个临时顺序节点
.withMode(CreateMode.EPHEMERAL_SEQUENTIAL)
.forPath(path, lockNodeBytes);
}
可以看到加锁就是创建了一个临时顺序节点，加锁成功会构建一个LockData类型的对象，内部维护了线程id、重入次数和锁节点的路径，根据线程id为key缓存在本地的一个ConcurrentHashMap中。
创建的锁临时顺序节点示例：
锁的目录会加一个UUID防止幽灵节点。即创建成功但因为网络原因客户端没拿到成功的结果再次去重试创建对应的节点，会带着UUID去查询，如果存在说明不需要去重试。
整体流程：
锁的重入次数就是维护在本地的一个map中，value是一个LockData结构。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16private final ConcurrentMap<Thread, LockData> threadData = Maps.newConcurrentMap();
// LockData结构
private static class LockData
{
final Thread owningThread;
final String lockPath;
// 锁的重入次数
final AtomicInteger lockCount = new AtomicInteger(1);
private LockData(Thread owningThread, String lockPath)
{
this.owningThread = owningThread;
this.lockPath = lockPath;
}
}
可以看到在加锁流程中，以当前线程为key查询LockData对象如果存在，直接是把其lockCount++，以此来记录锁的重入次数。1
2
3
4
5
6
7
8// 根据当前线程获取锁对象，如果获取到了，那肯定是有锁的，这次是锁重入
LockData lockData = threadData.get(currentThread);
if ( lockData != null ) {
// 锁重入的关键：其实就是我们上面说的那个AtomicInteger原子类自增1
lockData.lockCount.incrementAndGet();
// 加锁直接返回成功
return true;
}
所以锁重入的流程嵌入加锁流程为：
当客户端尝试获取锁时，如果发现/lock目录被占用，这里为了满足锁的互斥性，当前客户端要互斥等待Watcher回调通知。
这里互斥等待的逻辑在LockInternals#internalLockLoop方法中1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31// org.apache.curator.framework.recipes.locks.LockInternals#internalLockLoop
// 下面代码是删减后的代码
private boolean internalLockLoop(long startMillis, Long millisToWait, String ourPath) throws Exception {
boolean haveTheLock = false;
try {
while ((client.getState() == CuratorFrameworkState.STARTED) && !haveTheLock) {
// 获取path下对应临时顺序节点，并按编号从小到大排序。底层采取的java.util.Comparator#compare来排序的
List<String> children = getSortedChildren();
// 获取当前线程创建的临时顺序节点名称
String sequenceNodeName = ourPath.substring(basePath.length() + 1);
// 这个方法底层就是判断当前节点编号是不是children里的第一个，是的话就能抢锁，不是的话就计算出上一个节点序号是谁，然后下面监听这个节点。（因为按照编号排序了，所以可以得出上一个节点是谁）
PredicateResults predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);
// 如果当前客户端就是持有锁的客户端，直接返回true
if (predicateResults.getsTheLock() ) {
haveTheLock = true;
} else {
// 如果没抢到锁，则监听上一个节点
String previousSequencePath = basePath + "/" + predicateResults.getPathToWatch();
synchronized(this) {
try {
// 监听器，watcher下面分析
client.getData().usingWatcher(watcher).forPath(previousSequencePath);
// 重点在这了，wait()，等待。也就是说没抢到锁的话就开启监听器然后wait()等待。
wait();
} catch ( KeeperException.NoNodeException e ) {}
}
}
}
}
return haveTheLock;
}
逻辑为：
注册的Watcher通知回调逻辑：（其实就是notifyAll来实现）1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18// org.apache.curator.framework.recipes.locks.LockInternals#watcher
private final Watcher watcher = new Watcher() {
public void process(WatchedEvent event) {
// 调postSafeNotify方法
client.postSafeNotify(LockInternals.this);
}
};
// org.apache.curator.framework.CuratorFramework#postSafeNotify
default CompletableFuture<Void> postSafeNotify(Object monitorHolder) {
return this.runSafe(() -> {
synchronized(monitorHolder) {
// 重点在这里，notifyAll。通知所有等待（wait）的节点。
monitorHolder.notifyAll();
}
});
}s
锁释放调用的是release方法：
1 | // org.apache.curator.framework.recipes.locks.InterProcessMutex#release |
流程为：
最基本的zk分布式锁实现：不考虑临时顺序节点，只去创建一个临时节点/lock。
未竞争到锁的客户端去监听外层的/lock节点的删除事件。
这带来两个问题：
基于这两个问题，利用ZK的临时顺序节点的功能，让被阻塞的节点只监听上一个序号的节点，去注册Watcher，实现了公平排队获取，也避免了羊群效应。
消费端的发送请求模型如下：
