Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
60 lines (39 sloc) 7.52 KB
title tagline last_updated category layout tags published description
关于微信朋友圈数据结构设计
漫谈
post
微信朋友圈
漫谈
true

{% include JB/setup %}

前段时间学校期末考试回了一趟学校,也是过了近半个月的潇洒日子。没啥事也就看了下部门老大安排的“家庭作业”吧,--关于微信朋友圈的数据结构设计。

知乎上看了几篇文章都很不错,就先贴出来做个记录,以后再做完善~ 这段时间真的好冷!!

相关链接:

https://www.zhihu.com/question/26812650?rf=27345775

https://www.zhihu.com/question/20959807/answer/16728749

https://www.zhihu.com/question/21854335

其中一篇原文下:

著作权归作者所有。
商业转载请联系作者获得授权,非商业转载请注明出处。
作者:PM学技术王志刚
链接:https://www.zhihu.com/question/26812650/answer/34137753
来源:知乎

关于消息的基础数据,比如文字、图片、发布时间、地理位置,这些咱就不表了。这些数据基本上与权限和性能没有多大关系,可以理解为单独存储,纯技术活。这里只讨论权限与性能相关的数据结构。

而在权限管理上,采用了给用户打“标签”来进行分组,这个标签的分组与微信通讯录一致。在数据上,就是给每个关系增加一个“标签”标记。这里需要注意的是,虽然微信的关系在产品使用上给用户是双向的(即互相关注),但是在存储的时候,是给互相关的两个用户分别建立了关系数据,也就是每个人独有自己的一份“通讯录”。这个通过删除了自己的好友之后,自己并不从别人的通讯录删除就可以看得出来。标签分组的基础数据就是这样了,这也是后面朋友圈权限管理的基础。

按照一般的逻辑,朋友圈的timeline是获取所有朋友的消息,然后剔除掉没有授权给自己看的消息,剔除掉自己屏蔽的用户消息,然后才得到自己当前看到的timeline。如果是这样做的话,等于每次刷新朋友圈,都要跑到所有的消息池里面去翻一遍朋友们的消息,还要去判断用户是否有权限阅读,显然是效率低下的方式,何况是这么大de一个访问量和数据量。所以,肯定不是这个样子的数据结构。

解决这种性能问题一般的思路就是把需要大计算量的内容分布到平时零散的时间去做,也就是说,平时就把每个用户需要的timeline准备好,等到用的时候(刷新朋友圈)就直接读取准备好的内容。那么答案就出来了,那就是除了存储一份上面讲到的文字,图片等基本信息外,还需要给每个用户存储一份timeline数据,注意,是每个用户一份。当然,这里的“每份”不需要存储完整信息,只需要存储消息的ID和时间(可能需要)。每个人刷新自己的朋友圈时,读取自己的那份数据就行了,既不用去消息池子里面筛选,也不用判断用户权限。

那是怎么实现权限控制呢?当一个用户发布一条消息时,服务器就会给每个有权限接收这条消息的用户的timeline中写入这条消息。也就是在用户发布的这一刻,就做好了权限安排,而不是等到读取的时候。这样就自然减少了读取的时候的计算量,提高了效率。

至于分库分表这些就不展开了,知道有这么回事就行。有时候这种技术上的设计也是会限制产品的设计。

基本思路就是这样了,用iPad敲的,很痛苦,只想尽快结束。感兴趣的同学可以去测试下:先发一条带阅读权限的消息,比如允许某个标签的人看。然后再给这个标签添加一个新人。结果是这个新人是看不到这条消息的,因为,权限划分是在发布的时候就划分好了,新人加入标签是在发布之后,所以没法获得这条消息的权限分配机会。

终于要结束了,那么问题来了,看看这个问题与产品设计还有哪些关系:
1、朋友圈的消息为啥不能编辑,只能删除?
2、上述发布时的权限分配规则中会考虑屏蔽的人吗?也就是问,如果一个用户A屏蔽了某个人B的朋友圈,B发布的消息会进入A的timeline的准备数据中吗(不是指用户微信里看到的)?

看点赞的数量,高的话就回来把这两个自问的问题回答了。

自问的答案:
1、我理解这是产品设计和技术实现平衡的结果。编辑功能对于主要以发布照片和即时消息的朋友圈来说,并不是刚性的需求。但是在上面的技术框架下,编辑功能在技术上,就不好实现。具体来说就是:前面我们讲了,权限的控制是在发布的时候确定了,如果增加编辑功能的话,意味着一旦用户在编辑的时候调整了阅读权限的话,就需要将之前写入到有权限的用户timeline的数据删除掉,重新写入一遍,这对于技术实现来说,也是一个很大的成本,需要更新的数据很多(该条消息所有涉及到的用户的timeline数据都要更新)。所以,平衡的结果是宁愿让用户删除了重新发布,也不提供编辑的功能。你可能又要问了,删除时就不用更新相关人的timeline吗?首先删除比写入简单多了,第二个是用户timeline的数据可能还真不用删除。具体原因就不解释了,想知道的给我们留言单独解释。

2、先说一下我的答案:在发布时的权限控制是不会考虑屏蔽的人的。(这里的“屏蔽”指的是发布消息的用户的好友们屏蔽了发布消息的人,而不是发布消息的人的屏蔽清单,想想是不是!)前面我们讲了,在消息发布的时候,服务器会根据用户设置的权限信息,将消息有选择的放到有权限阅读人的timeline中。如果这个时候需要考虑屏蔽的人的话,那就还要去读取每个有权限阅读的人的屏蔽人清单,然后根据每个人的清单去决定是不是放到这个人的timeline中,显然这又会增加多大的计算量。那么有人就要问了,那怎么实现屏蔽的功能呢?两种方法实现,一种是在这个用户刷新朋友圈时,将读取到的自己的那份timeline数据(含屏蔽人的消息),在服务器端过滤掉屏蔽人的消息;另外一种则是读取的时候,服务器端按照原样下发给客户端,客户端根据存储的屏蔽清单来过滤,被屏蔽的则不显示给用户。两种方法在实现效率上几乎没有差别,通过对于微信的使用体验来看,我倾向于这个是由客户端来过滤的。实际这也可以有方法去验证,这里就不做了。这种屏蔽方案也是基于上面提到的“把需要大计算量的过程分散到平时零散的时间去做”。
那么怎么验证上述关于屏蔽的逻辑是对的呢?上面我们在验证“发布时进行权限分配”中讲到了,后添加标签分组的人,是看不到之前发布的分组权限消息的。这里我们也可以通过类似的方法验证:把用户屏蔽后,该用户的消息全部看不到,但是取消屏蔽之后,又立即能在朋友圈中看到,包括之前发布的消息但没有看过的消息。

最后要说的是,作为一个微信设计的旁观者,以上答案是作为一个用户从系统分析的角度去考虑的,并不代表微信确实是这样的一个设计思路,但答案中的方案已经尽可能做到了可以验证。