微信產品經理面試題

微信產品經理面試題

其中其次題是一道偏技術的問題，消失在產品經理的面試中的確有點意外，但這題不失為一道很好的產品設計與系統(tǒng)分析的題目。系統(tǒng)分析也是我們"產品經理學技術'系列文章規(guī)劃中的一個部分，也是將我們所講的技術進行"升華'的一部分內容。

下面我們嘗試回答一下這個問題，算是拋磚引玉了，大家有好的答案也可以給我們留言進行爭論。

伴侶圈的基本數據結構設計是怎樣的?既能做到完善閱讀權限設置，又能兼顧性能?

關于消息的基礎數據，比如文字、圖片、時間、位置等這些咱就不表了。這些數據基本上與權限和性能沒有多大關系，可以理解為單獨存儲，純技術活。這里只爭論權限與性能相關的數據結構。

而在權限管理上，微信采納了給用戶打"標簽'來進行分組，這個標簽的分組與微信通訊錄全都。在數據上，就是給每個關系增加一個"標簽'標記。

這里需要留意的是，雖然微信的關系在產品使用上給用戶是雙向的(即相互關注)，但是在存儲的時候，是給相互關的兩個用戶分別建立了關系數據，也就是每個人獨有自己的一份"通訊錄'。

這通過刪除了自己的好友之后，自己并不從別人的通訊錄刪除就可以看得出來。標簽分組的基礎數據就是這樣了，這也是后面伴侶圈權限管理的基礎。

對于個人伴侶圈timeline所能看到的消息，根據一般的規(guī)律是先獵取全部伴侶的消息，然后剔除掉沒有授權給自己看的消息、剔除掉自己屏蔽的用戶消息，然后才得到自己當前看到的timeline。

假如是這樣的規(guī)律的話，等于每次刷新伴侶圈，都要跑到全部的消息池里面去找到上述通訊錄中伴侶們的消息，還要對找到的每條消息去推斷用戶是否有權限閱讀。

這明顯是效率低下的方式，更何況微信是這么大的一個訪問量和數據量。所以，這種數據結構設計是行不通的了。

一般規(guī)律下伴侶圈每次讀取的過程：

解決這種性能問題一般的思路就是把需要大計算量的過程分散到平常零散的時間去做。

在這里的思路就是：平常就把每個用戶需要的timeline數據根據權限設置預備好，等到用的時候(刷新伴侶圈)就直接讀取預備好的內容。

那么答案就出來了：除了存儲一份上面講到的文字，圖片等基本信息外，還需要給每個用戶存儲一份timeline數據，留意，是每個用戶一份。

當然，這里的"每份'不需要存儲完整信息，只需要存儲消息的ID和時間(可能需要)。每個人刷新自己的伴侶圈時，讀取自己的那份數據就行了，既不用去消息池子里面篩選，也不用推斷用戶權限。

那是怎么實現權限掌握呢?

當一個用戶發(fā)布一條消息時會根據上面講的標簽設置相關的權限，服務器就會給每個有權限接收這條消息的用戶的timeline中寫入這條消息。

也就是在用戶發(fā)布的這一刻，就做好了權限支配，而不是等到讀取的時候。這樣就自然削減了讀取的時候的計算量，提高了效率。

發(fā)布時進行權限掌握(示意圖，實際比這簡單)

至于分庫分表這些就不綻開了，知道有這么回事就行。有時候這種技術上的設計也是會限制產品的設計。

那怎么證明上面說的合理呢?

感愛好的同學可以去測試下：先發(fā)一條帶閱讀權限的'消息，比如允許某個標簽的人看。然后再給這個標簽添加一個新人。

結果是這個新人是看不到這條消息的，由于權限劃分是在發(fā)布的時候就劃分好了，新人加入標簽的時間是在發(fā)布之后，所以沒法獲得這條消息的權限安排機會，雖然他后來在標簽組中，但是仍舊沒有方法看到這條消息。

這就是上面問題的答案，其實主要考察的是在產品設計時是否能夠考慮到技術方案的限制。

我把上面的答案貼在知乎上，有人就問了：微信產品團隊是在一開頭設計就考慮到了這個問題，還是經過不斷的迭代成現在這樣的?

這是個好問題，好的產品經理應當在設計的時候就考慮到這種狀況，或者至少應當有相應的預案，而不至于在消失問題或者被研發(fā)發(fā)難時束手無策。

在這個案例中，微信是一開頭考慮到了還是迭代過來的并不重要，對于微信"伴侶圈'來說，原來就是一個迭代產品，最早的權限管理是單獨于通訊錄的，那個時候是純插件的模式，現在才與通訊錄共用了分組模式進行權限管理。

假如對于上面的技術對產品設計的影響還不是很清楚的話，那么就再跟兩個問題(好的產品經理除了能回答問題外，還要能提出問題^_^)：

1、伴侶圈的消息為啥不能編輯，只能刪除?

我理解這是產品設計和技術實現平衡的結果。

編輯功能對于主要以發(fā)布照片和即時消息的伴侶圈來說，并不是剛性的需求。但是在上面的技術框架下，編輯功能在技術上，就不好實現。

詳細來說就是：前面我們講了，權限的掌握是在發(fā)布的時候確定了，假如增加編輯功能的話，意味著一旦用戶在編輯的時候調整了閱讀權限的話，就需要將之前寫入到有權限的用戶timeline的數據刪除掉，重新寫入一遍，這對于技術實現來說，也是一個很大的成本，需要更新的數據許多(該條消息全部涉及到的用戶的timeline數據都要更新)。

所以，平衡的結果是寧愿讓用戶刪除了重新發(fā)布，也不供應編輯的功能。

你可能又要問了，刪除時就不用更新相關人的timeline嗎?

首先刪除比寫入簡潔多了，其次個是用戶timeline的數據可能還真不用刪除。詳細緣由就不解釋了，想知道的給我們留言單獨解釋。

2、上述發(fā)布時的權限安排規(guī)章中會考慮屏蔽的人嗎?也就是問，假如一個用戶A屏蔽了某個人B的伴侶圈，B發(fā)布的消息會進入A的timeline的預備數據中嗎(不是指用戶微信里看到的)?

先說一下我的答案：在發(fā)布時的權限掌握是不會考慮屏蔽的人的。前面我們講了，在消息發(fā)布的時候，服務器會依據用戶設置的權限信息，將消息有選擇的放到有權限閱讀人的timeline中。

假如這個時候需要考慮屏蔽的人的話，那就還要去讀取每個有權限閱讀的人的屏蔽人清單，然后依據每個人的清單去打算是不是放到這個人的timeline中，明顯這又會增加多大的計算量。

那么有人就要問了，那怎么實現屏蔽的功能呢?

兩種方法實現，一種是在這個用戶刷新伴侶圈時，將讀取到的自己的那份timeline數據(含屏蔽人的消息)，在服務器端過濾掉屏蔽人的消息。

另外一種則是讀取的時候，服務器端根據原樣下發(fā)給客戶端，客戶端依據存儲的屏蔽清單來過濾，被屏蔽的則不顯示給用戶。

兩種方法在實現效率上幾乎沒有差別，通過對于微信的使用體驗來看，我傾向于這個是由客戶端來過濾的。實際這也可以有方法去驗證，這里就不做了。這種屏蔽方案也是基于上面提到的"把需要大計算量的過程分散到平常零散的時間去做'。

那么怎么驗證上述關于屏蔽的規(guī)律是對的呢?

上面我們在驗證"發(fā)布時進行權限安排'中講到了，后添加標簽分組的人，是看不到之前發(fā)布的分組權限消息的。這里我們也可以通過類似的方法驗證：把用戶屏蔽后，該用戶的消息全部看不到，但是取消屏蔽之后，又馬上能在伴侶圈中看到，包括之前發(fā)布的消息但沒有看過的消息。

最終要說的是，作為一個微信設計的旁觀者，以上答案是作為一個用戶從系統(tǒng)分析的角度去考慮的，并不代表微信的確是這樣的一個設計思路，但答案中的方案已經盡可能做到了可以驗證