从一个BUG聊微信朋友圈设计

Y说

最近生活方式发生了一点变化。搬家了，住的地方离公司更近了。

这就让我多了很多的操作空间，比如早上起来跑个步啥的。跑完步还能有点时间写博客，所以紧赶慢赶花了几个早上把这篇很早之前就想写的文章写出来了。

平时也会积累一些写博客的灵感，后面慢慢写吧。

过段时间打算想试试短视频的形式聊一些技术话题或者编程实战，计划中。。。

一个权限bug

前不久无意间发现了一个微信朋友圈的权限bug。

事情是这样的，我平时会在微信朋友圈发点动态。

因为本人“过于羞涩”，所以很多动态都会一般会屏蔽公司的领导，偶尔也会屏蔽同事。比如偶尔写的公众号文章，也会屏蔽他们（防止他们发现我过于菜的事实）。

微信的朋友圈是支持这种简单的权限控制需求的，在发朋友圈的时候，可以选择：所有朋友可见、仅自己可见、不给谁看、只给谁看。

这种情况，我一般是设置不给带有“领导”和“同事”的标签看。

点击发送，没有任何问题，他们看不到这条动态。

直到我新加了一个同事的微信（以前没加过）。。。

我确定在加之前就给他设置好“同事”的标签，发现他居然能看到我发的那条动态！！！

这算bug吗？我觉得当然算啊！我明明“处心积虑”地设置好了权限不给同事看，结果新加的朋友可以无视这个设置，直接看到这条动态！

这让我又想起了之前加了一个同事，第二天她说我公众号文章写得不错。我内心一顿问号，心想我不是把你们屏蔽了吗？？？现在想来也是这个bug的锅了。

朋友圈的设计

因为这事，又想起了之前的一个编程设计题（其实是面试题）：如果让你设计一个朋友圈，你会怎么设计？

设计一个朋友圈的功能不难，难的是如何能够在微信这么大的日活下维持高性能。常见的设计有两种：推模式和拉模式。适用于不同的场景。

所谓推模式，指的是一个用户发了一条动态，会把这条动态推送给所有朋友。这样每个人在刷朋友圈的时候，只需要把自己收到的动态按收到的顺序展示出来就行了。

所谓拉模式，指的是一个用户在刷朋友圈的时候，去请求他所有好友最近的动态，然后排序展示。

我们先来看看微信是怎么设计的。朋友圈目前有两个入口：

1. 点击发现-朋友圈，可以看到自己的好友发的动态

2. 点击某个好友的头像-朋友圈，可以看到这个好友的动态

对第一种业务场景，使用推模式比拉模式好，如果使用拉模式，我们要同时发出大量的网络请求，要处理某些请求失败的情况，拿数据之前要校验权限，拿到数据后要处理排序等。

而第二种业务场景，显然拉模式比推模式好。因为是查看一个单独的好友的动态，所以没有问题。

权限的设计

先来看产品层面的设计。我们在发朋友圈的时候，可以选择谁可见谁不可见。如果使用推模式，就很好控制权限了，直接把要推的人算出来，推给这些人就行了。其他人接收不到推送，自然也就看不到你发的这条动态了。

而众所周知，朋友圈一旦发表以后，内容是不可以修改的，权限也是不可修改的。所以也就不会有后续的权限变更维护问题。

按照这个逻辑，如果我在一分钟前发了一条朋友圈动态，然后新加了一个好友A，这个时候好友A的朋友圈是看不到我们刚刚发的这条动态的（即使他应该有权限），因为我们没有推给他，除非微信在加好友的时候做了补推的操作，我没试过，但估计没有做补推操作，感兴趣的读者可以做个实验看看有没有。

而如果好友A点击我的头像进入我的朋友圈，是能够看到我刚刚发的那条动态的。理论上来说，应该在拉的时候做一下权限校验，但很明显微信没有做。

这个权限校验其实并不复杂，也不需要很高的性能。我们用一个图来解释：

所以我理解这个并不是技术实现的问题，而是单纯的产品问题，没考虑到这个业务场景吧。但这个使用场景对于我来说确实是会经常遇到。不知道什么时候会修复，多久可以修复，但希望可以早点修复~

推模式有什么弊端？

最后再讨论一下推模式。推模式比较适合好友比较少的业务场景。在发动态这种业务下，一般有两种业务场景：

1. 双向关注，比如微信好友，A和B是互相关注的关系，发的动态对方都能看到
2. 单向关注，比如微博，A关注了B，那B发的动态A可以看到，但A发的动态B看不到。

如果是单向关注，那就不适合使用推模式，比如某大V，有好几千万粉丝，如果使用推模式，发一条动态就给这几千万人推送，那对服务器来说消耗巨大，不划算。所以这种单向关注的场景使用拉模式更适合。

但单向关注有时候也会结合推模式和拉模式两种方式来做，设定一个阈值（比如1万），如果粉丝量小于这个阈值，就使用推模式，否则使用拉模式。

微信好友上限是5000人，所以全部使用推模式也还好。结合上面提到的权限问题，估计应该是使用的这种模式。但具体有没有其它什么实现，就不得而知了。