列出功能需求->翻译成逻辑算法->抽象出数据结构->确定物理存储结构后面的不会脱离前面的独立存在，只存在于工作流的运用中，所以不能把它们独立地看。

问题引入

在微博中，两个人可以互相关注；在微信中，两个人可以互加好友。如何存储微博、微信等这些社交网络的好友关系吗？

图的概念

图

特点：

非线性数据结构；

图中的元素就叫做顶点（vertex）；

图中的一个顶点可以与任意其他顶点建立连接关系，这叫做边；

举例：微信

一个用户看做一个顶点；两个用户互加好友，就建立一条边；

每个用户有多少个好友，对应到图中，就叫做顶点的度（degree），就是跟顶点相连接的边的条数。

微博：（微博的社交关系跟微信不一样更加复杂一点。微博允许单向关注，用户 A 关注了用户 B，但用户 B 可以不关注用户 A）

如果用户 A 关注了用户 B，画一条从 A 到 B 的带箭头的边，来表示边的方向。

如果用户 A 和用户 B 互相关注了，那就画一条从 A 指向 B 的边，再画一条从 B 指向 A 的边。

有向图：边有方向的图叫做“有向图”

无向图：把边没有方向的图就叫做“无向图”。

有向图中又分入度和出度

入度：有多少条边指向这个顶点

出度：有多少条边是以这个顶点为起点指向其他顶点

对应到微博的例子，入度就表示有多少粉丝，出度就表示关注了多少人。

QQ：亲密度-如果两个用户经常往来，那亲密度就比较高；如果不经常往来，亲密度就比较低

带权图：在带权图中，每条边都有一个权重（weight），我们可以通过这个权重来表示 QQ 好友间的亲密度。

图的存储方法

邻接矩阵

邻接矩阵的底层依赖一个二维数组。

1、对于无向图来说，如果顶点 i 与顶点 j 之间有边，我们就将 A[i][j]和 A[j][i]标记为 1；

2、对于有向图来说，如果顶点 i 到顶点 j 之间，有一条箭头从顶点 i 指向顶点 j 的边，那我们就将 A[i][j]标记为 1。同理，如果有一条箭头从顶点 j 指向顶点 i 的边，我们就将 A[j][i]标记为 1。

3、对于带权图，数组中就存储相应的权重。

优点：

1、直观、简单；

2、基于数组，获取两个顶点的关系非常高效

3、另外一个好处是方便计算。这是因为，用邻接矩阵的方式存储图，可以将很多图的运算转换成矩阵之间的运算

缺点：浪费存储空间——对于无向图来说，如果 A[i][j]等于 1，那 A[j][i]也肯定等于 1。实际上，我们只需要存储一个就可以了。也就是说，无向图的二维数组中，如果我们将其用对角线划分为上下两部分，那我们只需要利用上面或者下面这样一半的空间就足够了，另外一半白白浪费掉了。如果我们存储的是稀疏图（Sparse Matrix），也就是说，顶点很多，但每个顶点的边并不多，那邻接矩阵的存储方法就更加浪费空间了

比如微信有好几亿的用户，对应到图上就是好几亿的顶点。但是每个用户的好友并不会很多，一般也就三五百个而已。如果我们用邻接矩阵来存储，那绝大部分的存储空间都被浪费了

邻接表(类似散列表)

方式：每个顶点对应一条链表，链表中存储的是与这个顶点相连接的其他顶点。有向图的邻接表存储方式，每个顶点对应的链表里面，存储的是指向的顶点。对于无向图来说，也是类似的，不过，每个顶点的链表中存储的，是跟这个顶点有边相连的顶点。

特点：时间、空间复杂度互换的设计思想。邻接表存储起来比较节省空间，但是使用起来就比较耗时间。

缺点：如果我们要确定，是否存在一条从顶点 2 到顶点 4 的边，那就要遍历顶点 2 对应的那条链表，看链表中是否存在顶点 4。而且，链表的存储方式对缓存不友好。在邻接表中查询两个顶点之间的关系比较低效。

改进：将链表换成其他更加高效的数据结构，比如平衡二叉查找树比如红黑树

解答开篇

以微博为例子（数据结构是为算法服务的，所以具体选择哪种存储方法，与期望支持的操作有关系）。假设支持以下几种操作：

判断用户 A 是否关注了用户 B；
判断用户 A 是否是用户 B 的粉丝；
用户 A 关注用户 B；
用户 A 取消关注用户 B；
根据用户名称的首字母排序，分页获取用户的粉丝列表；
根据用户名称的首字母排序，分页获取用户的关注列表。

因为社交网络是一张稀疏图，使用邻接矩阵存储比较浪费存储空间。所以采用邻接表来存储。但是仅仅用一个邻接表来存储是不够的。当我们去查询某个用户被哪些用户关注了，也即用户的粉丝列表，是非常困难的，因此再加上一个逆邻接表。

邻接表

存储了用户的关注关系；

每个顶点的链表中，存储的就是这个顶点指向的顶点；

如果要查找某个用户关注了哪些用户，在邻接表中查找；

改进：基础的邻接表不适合快速判断两个用户之间是否是关注与被关注的关系，将邻接表中的链表改为支持快速查找的动态数据结构

因为我们需要按照用户名称的首字母排序，分页来获取用户的粉丝列表或者关注列表，用跳表这种结构再合适不过了。这是因为，跳表插入、删除、查找都非常高效，时间复杂度是 O(logn)，空间复杂度上稍高，是 O(n)。最重要的一点，跳表中存储的数据本来就是有序的了，分页获取粉丝列表或关注列表，就非常高效

逆邻接表

存储的是用户的被关注关系；

每个顶点的链表中，存储的是指向这个顶点的顶点；

如果要查找某个用户被哪些用户关注了，从逆邻接表中查找。

可能问题

如果对于小规模的数据，比如社交网络中只有几万、几十万个用户，可以将整个社交关系存储在内存中，上面的解决思路是没有问题。但是如果像微博那样有上亿的用户，数据规模太大，我们就无法全部存储在内存中了。这个时候该怎么办呢？

思路：通过哈希算法等数据分片方式，将邻接表存储在不同的机器上。你可以看下面这幅图，我们在机器 1 上存储顶点 1，2，3 的邻接表，在机器 2 上，存储顶点 4，5 的邻接表。逆邻接表的处理方式也一样。当要查询顶点与顶点关系的时候，我们就利用同样的哈希算法，先定位顶点所在的机器，然后再在相应的机器上查找