產品助理的面試題

騰訊微信產品經理面試題

其中第二題是一道偏技術的問題，出現在產品經理的面試中確實有點意外，但這題不失為一道很好的產品設計與系統分析的題目。系統分析也是我們“產品經理學技術”系列文章規劃中的一個部分，也是將我們所講的技術進行“昇華”的一部分內容。

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

朋友圈的基本數據結構設計是怎樣的?既能做到完美閲讀權限設置，又能兼顧性能?

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

而在權限管理上，微信採用了給用户打“標籤”來進行分組，這個標籤的分組與微信通訊錄一致。在數據上，就是給每個關係增加一個“標籤”標記。這裏需要注意的是，雖然微信的關係在產品使用上給用户是雙向的(即互相關注)，但是在存儲的時候，是給互相關的兩個用户分別建立了關係數據，也就是每個人獨有自己的一份“通訊錄”。這通過刪除了自己的好友之後，自己並不從別人的通訊錄刪除就可以看得出來。標籤分組的基礎數據就是這樣了，這也是後面朋友圈權限管理的基礎。

對於個人朋友圈timeline所能看到的消息，按照一般的邏輯是先獲取所有朋友的消息，然後剔除掉沒有授權給自己看的消息、剔除掉自己屏蔽的用户消息，然後才得到自己當前看到的timeline。如果是這樣的邏輯的話，等於每次刷新朋友圈，都要跑到所有的消息池裏面去找到上述通訊錄中朋友們的消息，還要對找到的每條消息去判斷用户是否有權限閲讀。這顯然是效率低下的方式，更何況微信是這麼大的一個訪問量和數據量。所以，這種數據結構設計是行不通的了。

一般邏輯下朋友圈每次讀取的過程

解決這種性能問題一般的思路就是把需要大計算量的過程分散到平時零散的時間去做。在這裏的思路就是：平時就把每個用户需要的timeline數據按照權限設置準備好，等到用的時候(刷新朋友圈)就直接讀取準備好的內容。那麼答案就出來了：除了存儲一份上面講到的文字，圖片等基本信息外，還需要給每個用户存儲一份timeline數據，注意，是每個用户一份。當然，這裏的“每份”不需要存儲完整信息，只需要存儲消息的ID和時間(可能需要)。每個人刷新自己的朋友圈時，讀取自己的那份數據就行了，既不用去消息池子裏面篩選，也不用判斷用户權限。

那是怎麼實現權限控制呢?

當一個用户發佈一條消息時會按照上面講的標籤設置相關的權限，服務器就會給每個有權限接收這條消息的用户的timeline中寫入這條消息。也就是在用户發佈的這一刻，就做好了權限安排，而不是等到讀取的時候。這樣就自然減少了讀取的時候的計算量，提高了效率。

發佈時進行權限控制(示意圖，實際比這複雜)

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

那怎麼證明上面説的合理呢?

感興趣的同學可以去測試下：先發一條帶閲讀權限的消息，比如允許某個標籤的人看。然後再給這個標籤添加一個新人。結果是這個新人是看不到這條消息的，因為權限劃分是在發佈的時候就劃分好了，新人加入標籤的時間是在發佈之後，所以沒法獲得這條消息的權限分配機會，雖然他後來在標籤組中，但是仍然沒有辦法看到這條消息。

這就是上面問題的答案，其實主要考察的是在產品設計時是否能夠考慮到技術方案的限制。我把上面的答案貼在知乎上，有人就問了：微信產品團隊是在一開始設計就考慮到了這個問題，還是經過不斷的迭代成現在這樣的?這是個好問題，好的產品經理應該在設計的時候就考慮到這種情況，或者至少應該有相應的預案，而不至於在出現問題或者被研發發難時束手無策。在這個案例中，微信是一開始考慮到了還是迭代過來的並不重要，對於微信“朋友圈”來説，本來就是一個迭代產品，最早的權限管理是單獨於通訊錄的，那個時候是純插件的模式，現在才與通訊錄共用了分組模式進行權限管理。

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

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

我理解這是產品設計和技術實現平衡的結果。編輯功能對於主要以發佈照片和即時消息的朋友圈來説，並不是剛性的需求。但是在上面的技術框架下，編輯功能在技術上，就不好實現。具體來説就是：前面我們講了，權限的控制是在發佈的時候確定了，如果增加編輯功能的話，意味着一旦用户在編輯的時候調整了閲讀權限的話，就需要將之前寫入到有權限的用户timeline的數據刪除掉，重新寫入一遍，這對於技術實現來説，也是一個很大的成本，需要更新的數據很多(該條消息所有涉及到的用户的timeline數據都要更新)。所以，平衡的結果是寧願讓用户刪除了重新發布，也不提供編輯的功能。你可能又要問了，刪除時就不用更新相關人的timeline嗎?首先刪除比寫入簡單多了，第二個是用户timeline的數據可能還真不用刪除。具體原因就不解釋了，想知道的給我們留言單獨解釋。

2、上述發佈時的權限分配規則中會考慮屏蔽的人嗎?也就是問，如果一個用户A屏蔽了某個人B的朋友圈，B發佈的消息會進入A的timeline的準備數據中嗎(不是指用户微信裏看到的)?

先説一下我的答案：在發佈時的.權限控制是不會考慮屏蔽的人的。前面我們講了，在消息發佈的時候，服務器會根據用户設置的權限信息，將消息有選擇的放到有權限閲讀人的timeline中。如果這個時候需要考慮屏蔽的人的話，那就還要去讀取每個有權限閲讀的人的屏蔽人清單，然後根據每個人的清單去決定是不是放到這個人的timeline中，顯然這又會增加多大的計算量。那麼有人就要問了，那怎麼實現屏蔽的功能呢?兩種方法實現，一種是在這個用户刷新朋友圈時，將讀取到的自己的那份timeline數據(含屏蔽人的消息)，在服務器端過濾掉屏蔽人的消息;另外一種則是讀取的時候，服務器端按照原樣下發給客户端，客户端根據存儲的屏蔽清單來過濾，被屏蔽的則不顯示給用户。兩種方法在實現效率上幾乎沒有差別，通過對於微信的使用體驗來看，我傾向於這個是由客户端來過濾的。實際這也可以有方法去驗證，這裏就不做了。這種屏蔽方案也是基於上面提到的“把需要大計算量的過程分散到平時零散的時間去做”。

那麼怎麼驗證上述關於屏蔽的邏輯是對的呢?上面我們在驗證“發佈時進行權限分配”中講到了，後添加標籤分組的人，是看不到之前發佈的分組權限消息的。這裏我們也可以通過類似的方法驗證：把用户屏蔽後，該用户的消息全部看不到，但是取消屏蔽之後，又立即能在朋友圈中看到，包括之前發佈的消息但沒有看過的消息。

最後要説的是，作為一個微信設計的旁觀者，以上答案是作為一個用户從系統分析的角度去考慮的，並不代表微信確實是這樣的一個設計思路，但答案中的方案已經儘可能做到了可以驗證。答案中也沒有涉及到具體的技術，僅僅是一個系統分析的思路。

很高興看到越來越多的產品經理招聘開始注重技術能力了。前段時間各大互聯網公司的產品經理校招也出現了不少“技術”相關的試題，説明業內開始意識到技術能力對於產品設計的輔助作用。還是那句話，技術並不是產品設計必須的，但是能有的話效率會提升很多。