后台开发常见层式结构设计：时间轮、跳表、LSM_Tree

时间轮：内核定时器的实现、skynet、kafka、netty；
跳表：redis、rocksdb
LSM-Tree：写多读少 b+树 :读多写少

思想：分治

1、海量并发定时任务：时间轮

定时任务 定时器
以时间顺序来进行组织 过期时间戳
以事件的执行顺序进行组织： 时间轮 处理定时任务的优先级

多层级时间轮


多线程环境下如何进行加锁？锁的粒度
lock(&mtx);
操作时间轮
unlock(&mtx);

2、高并发读写有序结构组织;跳表

增删改查

增删改容易破坏理想状态，并且需要重新维护
增加节点时候，随即层数 1/2 1/4 1/8
O(log n)
多层级的有序链表
原子变量：最高层级、节点
内存可见性
指令优化问题
原子性

redis zset 排行榜 range,利于范围查找
双向链表，可以反向查找

3、空间利用率以及写性能高的磁盘数据组织：LSM_Tree

提升写的效率: 顺序内存 >> 随即内存~=顺序磁盘 >> 随机磁盘io

B+树 存储效率不高（空间放大比较严重 写放大比较严重） 167G
LSM-Tree 读多写少的问题 容易产生节点的分裂（double write） 50G

内存中支持跳表（更细粒度上加锁（只对修改的附近的节点加锁），支持多线程）
磁盘中有序的结构sorted string Table
Memtable可写内存
immutable memtable 只读内存

流程：
写到日志，同时写道可写内存，当可写内存写满，移到只读内存中，只读内存写道level0中，level0中可能出现相同的key（修改了某个值），level0中归并排序到level1

为什么是顺序写？
因为是append log。

怎么去高效地读？
加一个布隆过滤器：能确定一定不存在，有误差判定存在；
首先在level0的第一个ssTable中，用布隆过滤器判断，没有就去下一个ssTable；
level0都没有，就去下一个level