微信产品经理面试题

微信产品经理面试题

其中其次题是一道偏技术的问题，消失在产品经理的面试中的确有点意外，但这题不失为一道很好的产品设计与系统分析的题目。系统分析也是我们"产品经理学技术'系列文章规划中的一个部分，也是将我们所讲的技术进行"升华'的一部分内容。

下面我们尝试回答一下这个问题，算是抛砖引玉了，大家有好的答案也可以给我们留言进行争论。

伴侣圈的基本数据结构设计是怎样的?既能做到完善阅读权限设置，又能兼顾性能?

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

而在权限管理上，微信采纳了给用户打"标签'来进行分组，这个标签的分组与微信通讯录全都。在数据上，就是给每个关系增加一个"标签'标记。

这里需要留意的是，虽然微信的关系在产品使用上给用户是双向的(即相互关注)，但是在存储的时候，是给相互关的两个用户分别建立了关系数据，也就是每个人独有自己的一份"通讯录'。

这通过删除了自己的好友之后，自己并不从别人的通讯录删除就可以看得出来。标签分组的基础数据就是这样了，这也是后面伴侣圈权限管理的基础。

对于个人伴侣圈timeline所能看到的消息，根据一般的规律是先猎取全部伴侣的消息，然后剔除掉没有授权给自己看的消息、剔除掉自己屏蔽的用户消息，然后才得到自己当前看到的timeline。

假如是这样的规律的话，等于每次刷新伴侣圈，都要跑到全部的消息池里面去找到上述通讯录中伴侣们的消息，还要对找到的每条消息去推断用户是否有权限阅读。

这明显是效率低下的方式，更何况微信是这么大的一个访问量和数据量。所以，这种数据结构设计是行不通的了。

一般规律下伴侣圈每次读取的过程：

解决这种性能问题一般的思路就是把需要大计算量的过程分散到平常零散的时间去做。

在这里的思路就是：平常就把每个用户需要的timeline数据根据权限设置预备好，等到用的时候(刷新伴侣圈)就直接读取预备好的内容。

那么答案就出来了：除了存储一份上面讲到的文字，图片等基本信息外，还需要给每个用户存储一份timeline数据，留意，是每个用户一份。

当然，这里的"每份'不需要存储完整信息，只需要存储消息的ID和时间(可能需要)。每个人刷新自己的伴侣圈时，读取自己的那份数据就行了，既不用去消息池子里面筛选，也不用推断用户权限。

那是怎么实现权限掌握呢?

当一个用户发布一条消息时会根据上面讲的标签设置相关的权限，服务器就会给每个有权限接收这条消息的用户的timeline中写入这条消息。

也就是在用户发布的这一刻，就做好了权限支配，而不是等到读取的时候。这样就自然削减了读取的时候的计算量，提高了效率。

发布时进行权限掌握(示意图，实际比这简单)

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

那怎么证明上面说的合理呢?

感爱好的同学可以去测试下：先发一条带阅读权限的'消息，比如允许某个标签的人看。然后再给这个标签添加一个新人。

结果是这个新人是看不到这条消息的，由于权限划分是在发布的时候就划分好了，新人加入标签的时间是在发布之后，所以没法获得这条消息的权限安排机会，虽然他后来在标签组中，但是仍旧没有方法看到这条消息。

这就是上面问题的答案，其实主要考察的是在产品设计时是否能够考虑到技术方案的限制。

我把上面的答案贴在知乎上，有人就问了：微信产品团队是在一开头设计就考虑到了这个问题，还是经过不断的迭代成现在这样的?

这是个好问题，好的产品经理应当在设计的时候就考虑到这种状况，或者至少应当有相应的预案，而不至于在消失问题或者被研发发难时束手无策。

在这个案例中，微信是一开头考虑到了还是迭代过来的并不重要，对于微信"伴侣圈'来说，原来就是一个迭代产品，最早的权限管理是单独于通讯录的，那个时候是纯插件的模式，现在才与通讯录共用了分组模式进行权限管理。

假如对于上面的技术对产品设计的影响还不是很清楚的话，那么就再跟两个问题(好的产品经理除了能回答问题外，还要能提出问题^_^)：

1、伴侣圈的消息为啥不能编辑，只能删除?

我理解这是产品设计和技术实现平衡的结果。

编辑功能对于主要以发布照片和即时消息的伴侣圈来说，并不是刚性的需求。但是在上面的技术框架下，编辑功能在技术上，就不好实现。

详细来说就是：前面我们讲了，权限的掌握是在发布的时候确定了，假如增加编辑功能的话，意味着一旦用户在编辑的时候调整了阅读权限的话，就需要将之前写入到有权限的用户timeline的数据删除掉，重新写入一遍，这对于技术实现来说，也是一个很大的成本，需要更新的数据许多(该条消息全部涉及到的用户的timeline数据都要更新)。

所以，平衡的结果是宁愿让用户删除了重新发布，也不供应编辑的功能。

你可能又要问了，删除时就不用更新相关人的timeline吗?

首先删除比写入简洁多了，其次个是用户timeline的数据可能还真不用删除。详细缘由就不解释了，想知道的给我们留言单独解释。

2、上述发布时的权限安排规章中会考虑屏蔽的人吗?也就是问，假如一个用户A屏蔽了某个人B的伴侣圈，B发布的消息会进入A的timeline的预备数据中吗(不是指用户微信里看到的)?

先说一下我的答案：在发布时的权限掌握是不会考虑屏蔽的人的。前面我们讲了，在消息发布的时候，服务器会依据用户设置的权限信息，将消息有选择的放到有权限阅读人的timeline中。

假如这个时候需要考虑屏蔽的人的话，那就还要去读取每个有权限阅读的人的屏蔽人清单，然后依据每个人的清单去打算是不是放到这个人的timeline中，明显这又会增加多大的计算量。

那么有人就要问了，那怎么实现屏蔽的功能呢?

两种方法实现，一种是在这个用户刷新伴侣圈时，将读取到的自己的那份timeline数据(含屏蔽人的消息)，在服务器端过滤掉屏蔽人的消息。

另外一种则是读取的时候，服务器端根据原样下发给客户端，客户端依据存储的屏蔽清单来过滤，被屏蔽的则不显示给用户。

两种方法在实现效率上几乎没有差别，通过对于微信的使用体验来看，我倾向于这个是由客户端来过滤的。实际这也可以有方法去验证，这里就不做了。这种屏蔽方案也是基于上面提到的"把需要大计算量的过程分散到平常零散的时间去做'。

那么怎么验证上述关于屏蔽的规律是对的呢?

上面我们在验证"发布时进行权限安排'中讲到了，后添加标签分组的人，是看不到之前发布的分组权限消息的。这里我们也可以通过类似的方法验证：把用户屏蔽后，该用户的消息全部看不到，但是取消屏蔽之后，又马上能在伴侣圈中看到，包括之前发布的消息但没有看过的消息。

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