求解“微信群覆盖”的三种方法：暴力，染色，链表，并查集(文章没火，你有责任)...
Posted 58沈剑
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了求解“微信群覆盖”的三种方法：暴力，染色，链表，并查集(文章没火，你有责任)...相关的知识，希望对你有一定的参考价值。
这是一篇聊算法的文章，从一个小面试题开始，扩展到一系列基础算法，包含几个部分：
(1) 题目简介；
(2) 思路一：暴力法；
(3) 思路二：染色法；
(4) 思路三：链表法；
(5) 思路四：并查集法；
除了聊方案，重点分享思考过程。文章较长，可提前收藏。
第一部分：题目简介
问题提出：求微信群覆盖
微信有很多群，现进行如下抽象：
(1) 每个微信群由一个唯一的gid标识；
(2) 微信群内每个用户由一个唯一的uid标识；
(3) 一个用户可以加入多个群；
(4) 群可以抽象成一个由不重复uid组成的集合，例如：
g1u1, u2, u3
g2u1, u4, u5
可以看到，用户u1加入了g1与g2两个群。
画外音：
gid和uid都是uint64；
集合内没有重复元素；
假设微信有M个群(M为亿级别)，每个群内平均有N个用户(N为十级别).
现在要进行如下操作：
(1) 如果两个微信群中有相同的用户，则将两个微信群合并，并生成一个新微信群；
例如，上面的g1和g2就会合并成新的群：
g3u1, u2, u3, u4, u5；
画外音：集合g1中包含u1，集合g2中包含u1，合并后的微信群g3也只包含一个u1。
(2) 不断的进行上述操作，直到剩下所有的微信群都不含相同的用户为止；
将上述操作称：求群的覆盖。
设计算法，求群的覆盖，并说明算法时间与空间复杂度。
画外音：你遇到过类似的面试题吗？
对于一个复杂的问题，思路肯定是“先解决，再优化”，大部分人不是神，很难一步到位。先用一种比较“笨”的方法解决，再看“笨方法”有什么痛点，优化各个痛点，不断升级方案。
第二部分：暴力法
拿到这个问题，很容易想到的思路是：
(1) 先初始化M个集合，用集合来表示微信群gid与用户uid的关系；
(2) 找到哪两个(哪些)集合需要合并；
(3) 接着，进行集合的合并；
(4) 迭代步骤二和步骤三，直至所有集合都没有相同元素，算法结束；
第一步，如何初始化集合？
set这种数据结构，大家用得很多，来表示集合：
(1) 新建M个set来表示M个微信群gid；
(2) 每个set插入N个元素来表示微信群中的用户uid；
set有两种最常见的实现方式，一种是树型set，一种是哈希型set。
假设有集合：
s=7, 2, 0, 14, 4, 12
树型set的实现如下：
其特点是：
(1) 插入和查找的平均时间复杂度是O(lg(n))；
(2) 能实现有序查找；
(3) 省空间；
哈希型set实现如下：
其特点是：
(1) 插入和查找的平均时间复杂度是O(1)；
(2) 不能实现有序查找；
画外音：求群覆盖，哈希型实现的初始化更快，复杂度是O(M*N)。
第二步，如何判断两个(多个)集合要不要合并？
集合对set(i)和set(j)，判断里面有没有重复元素，如果有，就需要合并，判重的伪代码是：
// 对set(i)和set(j)进行元素判断并合并
(1) foreach (element in set(i))
(2) if (element in set(j))
merge(set(i), set(j));
第一行(1)遍历第一个集合set(i)中的所有元素element；
画外音：这一步的时间复杂度是O(N)。
第二行(2)判断element是否在第二个集合set(j)中；
画外音：如果使用哈希型set，第二行(2)的平均时间复杂度是O(1)。
这一步的时间复杂度至少是O(N)*O(1)=O(N)。
第三步，如何合并集合？
集合对set(i)和set(j)如果需要合并，只要把一个集合中的元素插入到另一个集合中即可：
// 对set(i)和set(j)进行集合合并
merge(set(i), set(j))
(1) foreach (element in set(i))
(2) set(j).insert(element);
第一行(1)遍历第一个集合set(i)中的所有元素element；
画外音：这一步的时间复杂度是O(N)。
第二行(2)把element插入到集合set(j)中；
画外音：如果使用哈希型set，第二行(2)的平均时间复杂度是O(1)。
这一步的时间复杂度至少是O(N)*O(1)=O(N)。
第四步：迭代第二步与第三步，直至结束
对于M个集合，暴力针对所有集合对，进行重复元素判断并合并，用两个for循环可以暴力解决：
(1)for(i = 1 to M)
(2) for(j= i+1 to M)
//对set(i)和set(j)进行元素判断并合并
foreach (element in set(i))
if (element in set(j))
merge(set(i), set(j));
递归调用，两个for循环，复杂度是O(M*M)。
综上，如果这么解决群覆盖的问题，时间复杂度至少是：
O(M*N) // 集合初始化的过程
+
O(M*M) // 两重for循环递归
*
O(N) // 判重
*
O(N) // 合并
画外音：实际复杂度要高于这个，随着集合的合并，集合元素会越来越多，判重和合并的成本会越来越高。
第三部分：染色法
总的来说，暴力法效率非常低，集合都是一个一个合并的，同一个元素在合并的过程中要遍历很多次。很容易想到一个优化点，能不能一次合并多个集合？
暴力法中，判断两个集合set<i>和set<j>是否需要合并，思路是：遍历set<i>中的所有element，看在set<j>中是否存在，如果存在，说明存在交集，则需要合并。
哪些集合能够一次性合并？
当某些集合中包含同一个元素时，可以一次性合并。
怎么一次性发现，哪些集合包含同一个元素，并合并去重呢？
回顾一下工作中的类似需求：
M个文件，每个文件包含N个用户名，或者N个手机号，如何合并去重？
最常见的玩法是：
cat file_1 file_2 … file_M | sort | uniq > result
这里的思路是什么？
(1) 把M*N个用户名/手机号输出；
(2) sort排序，排序之后相同的元素会相邻；
(3) uniq去重，相邻元素如果相同只保留一个；
“排序之后相同的元素会相邻”，就是一次性找出所有可合并集合的关键，这是染色法的核心。
举一个栗子：
假设有6个微信群，每个微信群有若干个用户：
s1=1,0,5 s2=3,1 s3=2,9
s4=4,6 s5=4,7 s6=1,8
假设使用树形set来表示集合。
首先，给同一个集合中的所有元素染上相同的颜色，表示来自同一个集合。
然后，对所有的元素进行排序，会发现：
(1) 相同的元素一定相邻，并且一定来自不同的集合；
(2) 同一个颜色的元素被打散了；
这些相邻且相同的元素，来自哪一个集合，这些集合就是需要合并的，如上图：
(1) 粉色的1来自集合s1，紫色的1来自集合s2，黄色的1来自集合s6，所以s1s2s6需要合并；
(2) 蓝色的4来自集合s4，青色的4来自集合s5，所以s4s5需要合并；
不用像暴力法遍历所有的集合对，而是一个排序动作，就能找到所有需要合并的集合。
画外音：暴力法一次处理2个集合，染色法一次可以合并N个集合。
集合合并的过程，可以想象为，相同相邻元素所在集合，染成第一个元素的颜色：
(1) 紫色和黄色，染成粉色；
(2) 青色，染成蓝色；
最终，剩余三种颜色，也就是三个集合：
s1=0,1,3,5,8
s3=2,9
s4=4,6,7
神奇不神奇！！！
染色法有意思么？但仍有两个遗留问题：
(1) 粉色1，紫色1，黄色1，三个元素如何找到这三个元素所在的集合s1s2s6呢？
(2) s1s2s6三个集合如何快速合并？
画外音：假设总元素个数n=M*N，如果使用树形set，合并的复杂度为O(n*lg(n))，即O(M*N*lg(M*N))。
我们继续往下看。
第四部分：链表法
染色法遗留了两个问题：
步骤(2)中，如何通过元素快速定位集合？
步骤(3)中，如何快速合并集合？
我们继续聊聊这两个问题的优化思路。
问题一：如何由元素快速定位集合？
普通的集合，只能由集合根(root)定位元素，不能由元素逆向定位root，如何支持元素逆向定位root呢？
很容易想到，每个节点增加一个父指针即可。
更具体的：
element
int data;
element* left;
element* right;
升级为：
element
element* parent; // 指向父节点
int data;
element* left;
element* right;
如上图：所有节点的parent都指向它的上级，而只有root->parent=NULL。
对于任意一个元素，找root的过程为：
element* X_find_set_root(element* x)
element* temp=x;
while(temp->parent != NULL)
temp= temp->parent;
return temp;
很容易发现，由元素找集合根的时间复杂度是树的高度，即O(lg(n))。
有没有更快的方法呢？
进一步思考，为什么每个节点要指向父节点，直接指向根节点是不是也可以。
更具体的：
element
int data;
element* left;
element* right;
升级为：
element
element* root; // 指向集合根
int data;
element* left;
element* right;
如上图：所有节点的parent都指向集合的根。
对于任意一个元素，找root的过程为：
element* X_find_set_root(element* x)
return x->root;
很容易发现，升级后，由元素找集合根的时间复杂度是O(1)。
画外音：不能更快了吧。
另外，这种方式，能在O(1)的时间内，判断两个元素是否在同一个集合内：
bool in_the_same_set(element* a, element* b)
return (a->root == b->root);
甚为方便。
画外音：两个元素的根相同，就在同一个集合内。
问题二：如何快速进行集合合并？
暴力法中提到过，集合合并的伪代码为：
merge(set(i), set(j))
foreach(element in set(i))
set(j).insert(element);
把一个集合中的元素插入到另一个集合中即可。
假设set(i)的元素个数为n1，set(j)的元素个数为n2，其时间复杂度为O(n1*lg(n2))。
在“微信群覆盖”这个业务场景下，随着集合的不断合并，集合高度越来越高，合并会越来越慢，有没有更快的集合合并方式呢？
仔细回顾一下：
(1) 树形set的优点是，支持有序查找，省空间；
(2) 哈希型set的优点是，快速插入与查找；
而“微信群覆盖”场景对集合的频繁操作是：
(1) 由元素找集合根；
(2) 集合合并；
那么，为什么要用树形结构或者哈希型结构来表示集合呢？
画外音：优点完全没有利用上嘛。
让我们来看看，这个场景中，如果用链表来表示集合会怎么样，合并会不会更快？
s1=7,3,1,4
s2=1,6
如上图，分别用链表来表示这两个集合。可以看到，为了满足“快速由元素定位集合根”的需求，每个元素仍然会指向根。
s1和s2如果要合并，需要做两件事：
(1) 集合1的尾巴，链向集合2的头(蓝线1)；
(2) 集合2的所有元素，指向集合1的根(蓝线2,3)；
合并完的效果是：
变成了一个更大的集合。
假设set(1)的元素个数为n1，set(2)的元素个数为n2，整个合并的过程的时间复杂度是O(n2)。
画外音：时间耗在set(2)中的元素变化。
咦，我们发现：
(1) 将短的链表，接到长的链表上；
(2) 将长的链表，接到短的链表上；
所使用的时间是不一样的。
为了让时间更快，一律使用更快的方式：“元素少的链表”主动接入到“元素多的链表”的尾巴后面。这样，改变的元素个数能更少一些，这个优化被称作“加权合并”。
对于M个微信群，平均每个微信群N个用户的场景，用链表的方式表示集合，按照“加权合并”的方式合并集合，最坏的情况下，时间复杂度是O(M*N)。
画外音：假设所有的集合都要合并，共M次，每次都要改变N个元素的根指向，故为O(M*N)。
于是，对于“M个群，每个群N个用户，微信群求覆盖”问题，使用“染色法”加上“链表法”，核心思路三步骤：
(1) 全部元素全局排序；
(2) 全局排序后，不同集合中的相同元素，一定是相邻的，通过相同相邻的元素，一次性找到所有需要合并的集合；
(3) 合并这些集合，算法完成；
其中：
步骤(1)，全局排序，时间复杂度O(M*N)；
步骤(2)，染色思路，能够迅猛定位哪些集合需要合并，每个元素增加一个属性指向集合根，实现O(1)级别的元素定位集合；
步骤(3)，使用链表表示集合，使用加权合并的方式来合并集合，合并的时间复杂度也是O(M*N)；
总时间复杂度是：
O(M*N) //排序
+
O(1) //由元素找到需要合并的集合
*
O(M*N) //集合合并
神奇不神奇！！！
神奇不止一种，还有其他方法吗？我们接着往下看。
第五部分：并查集法
分离集合(disjoint set)是一种经典的数据结构，它有三类操作：
Make-set(a)：生成一个只有一个元素a的集合；
Union(X, Y)：合并两个集合X和Y；
Find-set(a)：查找元素a所在集合，即通过元素找集合；
这种数据结构特别适合用来解决这类集合合并与查找的问题，又称为并查集。
能不能利用并查集来解决求“微信群覆盖”问题呢？
一、并查集的链表实现
链表法里基本聊过，为了保证知识的系统性，这里再稍微回顾一下。
如上图，并查集可以用链表来实现。
链表实现的并查集，Find-set(a)的时间复杂度是多少？
集合里的每个元素，都指向“集合的句柄”，这样可以使得“查找元素a所在集合S”，即Find-set(a)操作在O(1)的时间内完成。
链表实现的并查集，Union(X, Y)的时间复杂度是多少？
假设有集合：
S1=7,3,1,4
S2=1,6
合并S1和S2两个集合，需要做两件事情：
(1) 第一个集合的尾元素，链向第二个集合的头元素(蓝线1)；
(2) 第二个集合的所有元素，指向第一个集合的句柄(蓝线2,3)；
合并完的效果是：
变成了一个更大的集合S1。
集合合并时，将短的链表，往长的链表上接，这样变动的元素更少，这个优化叫做“加权合并”。
画外音：实现的过程中，集合句柄要存储元素个数，头元素，尾元素等属性，以方便上述操作进行。
假设每个集合的平均元素个数是n，Union(X, Y)操作的时间复杂度是O(n)。
能不能Find-set(a)与Union(X, Y)都在O(1)的时间内完成呢？
可以，这就引发了并查集的第二种实现方法。
二、并查集的有根树实现
什么是有根树，和普通的树有什么不同？
常用的set，就是用普通的二叉树实现的，其元素的数据结构是：
element
int data;
element* left;
element* right;
通过左指针与右指针，父亲节点指向儿子节点。
而有根树，其元素的数据结构是：
element
int data;
element* parent;
通过儿子节点，指向父亲节点。
假设有集合：
S1=7,3,1,4
S2=1,6
通过如果通过有根树表示，可能是这样的：
所有的元素，都通过parent指针指向集合句柄，所有元素的Find-set(a)的时间复杂度也是O(1)。
画外音：假设集合的首个元素，代表集合句柄。
有根树实现的并查集，Union(X, Y)的过程如何？时间复杂度是多少？
通过有根树实现并查集，集合合并时，直接将一个集合句柄，指向另一个集合即可。
如上图所示，S2的句柄，指向S1的句柄，集合合并完成：S2消亡，S1变为了更大的集合。
容易知道，集合合并的时间复杂度为O(1)。
会发现，集合合并之后，有根树的高度变高了，与“加权合并”的优化思路类似，总是把节点数少的有根树，指向节点数多的有根树（更确切的说，是高度矮的树，指向高度高的树），这个优化叫做“按秩合并”。
新的问题来了，集合合并之后，不是所有元素的Find-set(a)操作都是O(1)了，怎么办？
如图S1与S2合并后的新S1，首次“通过元素6来找新S1的句柄”，不能在O(1)的时间内完成了，需要两次操作。
但为了让未来“通过元素6来找新S1的句柄”的操作能够在O(1)的时间内完成，在首次进行Find-set(“6”)时，就要将元素6“寻根”路径上的所有元素，都指向集合句柄，如下图。
某个元素如果不直接指向集合句柄，首次Find-set(a)操作的过程中，会将该路径上的所有元素都直接指向句柄，这个优化叫做“路径压缩”。
画外音：路径上的元素第二次执行Find-set(a)时，时间复杂度就是O(1)了。
实施“路径压缩”优化之后，Find-set的平均时间复杂度仍是O(1)。
稍微总结一下。
通过链表实现并查集：
(1) Find-set的时间复杂度，是O(1)常数时间；
(2) Union的时间复杂度，是集合平均元素个数，即线性时间；
画外音：别忘了“加权合并”优化。
通过有根树实现并查集：
(1) Union的时间复杂度，是O(1)常数时间；
(2) Find-set的时间复杂度，通过“按秩合并”与“路径压缩”优化后，平均时间复杂度也是O(1)；
即，使用并查集，非常适合解决“微信群覆盖”问题。
知其然，知其所以然，思路往往比结果更重要。
算法，其实还是挺有意思的。
架构师之路，给自己一个机会，看别处没有的文章
求解“微信群覆盖”的三种方法：暴力法，染色法，链表法，并查集法，新技能get了吗？希望大家有收获。
这篇文章没火，你真的有责任。
楼主雪地luo跪求收藏，转发，点赞，再看。
以上是关于求解“微信群覆盖”的三种方法：暴力，染色，链表，并查集(文章没火，你有责任)...的主要内容，如果未能解决你的问题，请参考以下文章