对红黑树、跳表、B+树的一些理解

毫无疑问数据结构是复杂的，让人头大的，大学时唯一挂科的就是数据结构，上学时不用心，不晓得自己的职业生涯要一直被数据结构支配。

或多或少，面试抱佛脚时，数据结构都会背一背刷一刷，HashMap的红黑树，Redis的跳表一个个都跑不了。

当回归日常时，学习及理解数据结构真的有什么收益吗

举个例子，最近看到IO多路复用的时候，说到select，poll与epoll对比时

有两个点
1.epoll通过维护一个链表来记录就绪事件，无需遍历所有文件描述符来获取所有就绪事件，而是通过事件通知机制，将就绪事件添加到链表中，epoll_wait()函数获取所有就绪事件。

int s = socket(AF_INET, SOCK_STREAM, 0);
bind(s, ...);
listen(s, ...)int epfd = epoll_create(...);
epoll_ctl(epfd, ...); //将所有需要监听的socket添加到epfd中while(1) {int n = epoll_wait(...);for(接收到数据的socket){//处理}
}

2.epoll通过红黑树来维护所有文件描述符。

当我看到第2点时，反应是居然是你，真的有你，可算再次遇到你了，除了HashMap中，终于又和你体会到了铺面而来的重逢喜悦感，另外带着一种原来你真的挺有用的欣慰感。

红黑树、B+树以及跳表这三个数据结构，之前在我心目中，地位是一样的，需要面试的时候，对于他们我口若悬河，头头是道，而日常开发就是，对不起，我们好像不太认识。

红黑树HashMap，B+树MySQL索引，跳表Redis跳表，我几乎快要把他们画等号了，背后的原理，为什么是这样的，却从来都想不起再去深究。

随着开发的生涯越走越远，我很欣慰自己没有原地踏步，那么为什么呢？

红黑树

红黑树不算是严格的二叉平衡查找树，标准的二叉平衡查找树父子上下节点的高度最大不会超过1，为了维护这个平衡，当新增或者删除数据时，标准的平衡二叉查找树需要耗费更多的资源，不可避免需要进行多次旋转。
红黑树使得二叉查找树能保持大体的平衡，不至于退化成链表，又不至于频繁的转换操作，在与平衡二叉树的时间复杂度相差不大的情况下，保证每次插入最多只需要三次旋转就能达到平衡，实现起来也更为简单。

红黑树在二叉查找树的基础上增加了着色和相关的性质使得红黑树相对平衡，从而保证了红黑树的查找、插入、删除的时间复杂度最坏为O(log n)。所以红黑树适用于搜索，插入，删除操作较多的情况。

应用场景

红黑树常用于存储内存中的有序数据，增删很快，内存存储不涉及 I/O 操作。

• HashMap
• IO多路复用-epoll
• Linux公平调度器

跳表

1.对有序列表查询性能的优化。

2.跳表的基本思想是将有序链表分层，每个节点在不同层中拥有不同数量的前向指针。上层链表是下层链表的子集，且上层链表中的元素顺序与下层链表一致。

3.通过增加指针和添加层级的方式，跳表可以实现对数级别的查找效率。

4.实现简单

原以为除了Redis ZSet中，也不会再见到跳表了，直到看到LevelDB时，了解到其Memtable中使用的也是跳表实现。

使用场景

• Redis zset
• LevelDB底层数据结构

B+树

号称为文件系统而生的数据结构。

多路平衡二叉树，选用B+树最大的理由，我理解是树的高度，高度，还是tm的高度。
B+树只需要3层就能存储大约2kw的数据，定位一个数据，也就是页大的读取IO次数，最多3,4次，换成红黑树或者跳表，大概需要10倍左右；
对于文件系统、数据库的场景，需要从磁盘读取数据，IO的耗费相对于内存来说是不可接受的。

使用场景

B+ 树在处理磁盘I/O、范围查询和大数据量管理方面优势明显

• 数据库：MySQL innodb索引，PostgreSQL索引，Oracle索引等基本主流的数据库
• 文件系统：NTFS、ReiserFS、大名鼎鼎的HDFS等文件系统