图
图的概念
图（graph）和树比起来，是一种更加复杂的非线性表结构。
顶点&边
树中的元素成为节点，图中的元素叫做顶点（vertex）。图一个顶点可以与任意其他顶点建立连接关系，这种建立的关系叫边（edge）。
在微信中，可以把每个用户看作一个顶点，两个用户之间互加好友，那就在两者之间建立一条边。所以，整个微信的好友关系就可以用一张图来表示。其中，每个用户有多少好友，对应到图中，就叫做顶点的度（degree），就是跟顶点相连的边的条数。
有向图&无向图
微博允许单向关注，用户A关注了用户B，但用户B可以不关注用户A。如果用户A关注了用户B，就在图中画一条从
A到B的带箭头的边，来表示边的方向。如果用户A和用户B互相关注了，那我们就画一条从A指向B的边，再画一条从B指向A的边。
这种边有方向的图叫做“有向图”。边没有方向的图就叫做“无向图”。
无向图总的“度”表示一个顶点有多少条边，在有向图中度分为入度（In-degree）和出度（Out-degree）。
顶点的入度，表示有多少条边指向这个顶点；顶点的出度，表示有多少条边是以这个顶点为起点指向其他顶点。
对应到微博中的例子，入度就表示有多少粉丝，出度就表示关注了多少人。
带权图
QQ还记录了两个用户之间的亲密度，如果两个用户经常往来，那亲密度就比较高；如果不经常往来，亲密度就比较低。在带权图（weighted graph）中，每条边都有一个权重（weight），可以通过这个权重来表示QQ好友间的亲密度。
图的存储
邻接矩阵存储方法
邻接矩阵（Adjacency Matrix）的底层依赖一个二维数组。
对于无向图来说，如果顶点i与顶点j之间有边，就将A[i][j]和A[j][i]标记为1；
对于有向图来说，如果顶点i指向顶点j就将A[i][j]标记为1。同理，如果顶点j指向顶点i就将A[j][i]标记为1。对于带权图，数组中就存储相应的权重。
邻接矩阵的底层依赖一个二维数组。对于无向图来说，如果顶点i与顶点j之间有边，我们就将A[i][j]和A[j][i]标记为1；对于有向图来说，如果顶点i和顶点j之间，有一条箭头从顶点i指向顶点j的边，那我们就将A[i][j]标记为1。同理，如果有一条箭头从顶点j指向顶点i的边，我们就将A[j][i]标记为1。对于带权图，数组中就存储相应的权重。
用邻接矩阵来表示一个图，虽然简单、直观，但是比较浪费存储空间。为什么这么说呢？
对于无向图来说，如果A[i][j]等于1，那A[j][i]也肯定等于1，只需要存储上三角矩阵或下三角矩阵可以节省一半的空间。
稀疏图（Sparse Matrix）是指每个顶点的边不多的图，用邻接矩阵的存储方法会非常浪费空间。
比如微信有好几亿的用户，对应到图上有好几亿的顶点，但每个用户的好友一般也就三五百个。如果用邻接矩阵来存储，那绝大部分的存储空间都被浪费了。
但邻接矩阵的存储方式简单、直接，因为基于数组，所以在获取两个顶点的关系时，就非常高效。其次用邻接矩阵的方式存储图，可以将很多图的运算转换成矩阵之间的运算。比如求最短路径Floy-Waeshall算法，就是利用矩阵循环相乘若干次得到的结果。
邻接表存储方法
邻接表（Adjacency List）的每个顶点对应一条链表，链表中存储的是与这个顶点相连接的其他顶点。
无向图可以看作每条边都是双方向的有向图。
邻接矩阵存储起来比较浪费空间，但是使用起来比较节省时间。相反，邻接表存储起来比较节省空间，但是使用起来就比较耗时间。这是时间、空间复杂度互换的设计思想，前者是空间换时间，后者是时间换空间。
上图邻接表的例子中，如果要确定是否存在一条从顶点2到顶点4的边，就要遍历顶点2对应的那条链表，看链表中是否存储顶点4。当然如果链表过长，可以将链表转换成红黑树、跳表、散列表等来提高查询效率，还可以将链表改成有序动态数组，通过二分查找的方法来快速定位两个顶点之间是否存在边。
如果存储微博、微信等社交网络中好友的关系？
假设需要支持下面这几个操作：
- 判断用户A是否关注了用户B；
- 判断用户A是否是用户B的粉丝；
- 用户A关注用户B；
- 用户A取消关注用户B；
- 根据用户名称的首字母排序，分页获取用户的粉丝列表；
- 根据用户名称的首字母排序，分页获取用户的关注列表；
用两个邻接表来存储，一个邻接表存储某个用户关注了哪些用户，即用户的关注关系；另一个邻接表称为逆邻接表存储某个用户被哪些用户关注，即用户的粉丝列表。
如果要查找某个用户关注了哪些用户，在邻接表中查找即可；如果要查找某个用户被哪些用户关注了，从逆邻接表表查找即可。
因为需要按照用户名称的首字母排序，分页来获取用户的粉丝列表或者关注列表，用跳表替换邻接表的链表比较合适。
跳表插入、删除、查找时间复杂度都是O(logn)，空间复杂度上是O(n)。最重要的一点，跳表中存储的数据本身就是有序的，分页获取粉丝列表或关注列表，就非常高效。
如果对于小规模的数据，可以将整个社交关系存储在内存中。
如果对于大规模的数据，可以通过哈希算法等数据分片方式，将邻接表存储在不同的机器上。
例如：
当要查询顶点和顶点关系的时候，就利用同样的哈希算法，先定位顶点所在的机器再在相应的机器上查找。
另外一种解决思路，就是利用外部存储（比如硬盘），数据库是经常用来持久化存储关系数据的。
用下面这张图存储这样一个图。为了高效地支持前面定义的操作，可以在表上对这两列都建立索引。
| user_id | follower_id |
|---|---|
| 1 | 4 |
| 2 | 1 |
| 2 | 4 |
| 3 | 2 |
| 3 | 5 |
| 4 | 2 |
| 4 | 5 |
| 5 | 2 |