社区系统调研
1、http://www.chinaz.com/web/2017/1108/825814.shtml
知乎回答的動態(tài)排名機制——威爾遜算法
我們在知乎經(jīng)常會看到有的答案有幾萬的贊竟然排在幾百贊答案的后面，這個就是知乎區(qū)別于傳統(tǒng)的論壇、貼吧單純的根據(jù)發(fā)布時間或者點贊數(shù)來排名的特殊機制，那么這個機制就讓時間比較晚的優(yōu)質(zhì)回答有了更多的曝光的機會，那么具體知乎這個排名算法是在怎么計算的呢？這個算法被叫做威爾遜算法，公式的話太復(fù)雜這里不說，只是說一下他是怎樣運作的。
先來看一下知乎的產(chǎn)品設(shè)計師黃濤在知乎產(chǎn)品專欄是怎么說的：
舉個例子的話，比如有一個新的回答，你通過讓朋友點贊，短時間內(nèi)獲得了一個不錯的排名，但是后續(xù)因為質(zhì)量不是很優(yōu)質(zhì)，新看到的用戶不為你的答案買單，點了反對，那么這個答案又會重新計算排名，可能又回到一個比較靠后的位置。
除此之外還加入了更復(fù)雜的用戶擅長話題經(jīng)驗權(quán)重，比如說張君比較擅長互聯(lián)網(wǎng)的話題，在這個話題下方有多個優(yōu)質(zhì)的回答，那么他在互聯(lián)網(wǎng)話題里面的投票的權(quán)重就高于饅頭這種普通用戶的投票，可能他投 1 票就相當(dāng)于饅頭的 100 票（這個數(shù)據(jù)是我腦補的，只是為了方便理解，不要當(dāng)真），所以在知乎有機會的話勾搭下大V有機會讓他幫你點個贊對于你的回答增加曝光是非常有幫助的。
因此未來我們會看到新創(chuàng)作的更受用戶喜歡內(nèi)容有機會獲得更多點贊的機會，快速獲得靠前的排序，低質(zhì)內(nèi)容則會長期保持在底部。對排名有影響的因素有點贊、反對并不是所有的回答最終都會獲得很多投票，大體上獲得投票總數(shù)較多的回答仍然會排在投票較少的回答前面，所以想要做好知乎營銷也得首先保證自己的內(nèi)容是用戶喜歡的才會有更多的曝光機會。
知乎消息機制——類似灰度測試的機制
知乎的消息分為 4 類：分別為關(guān)注的人、問題和專欄有了新回答；新關(guān)注我的人；我獲得的贊與感謝；私信，其他的知乎的EDM郵件、每日精選等這里不討論。
知乎的關(guān)注機制，在一般情況下，知乎的消息都是默認：接收所有人的消息。可以讓用戶關(guān)注到他們感興趣的問題的新的回答，也給了新回答的更多的曝光機會。
關(guān)注的人、問題和專欄：關(guān)注的人、問題或者專欄有了新的回答都會出現(xiàn)在你的消息列表里面，這個其實是經(jīng)過允許的消息通知，推送的都是用戶感興趣的內(nèi)容，這種消息的打開率是比較高的。這里要說一下的就是你關(guān)注的人給其他人點贊的動態(tài)會出現(xiàn)在首頁的信息流里面。
新關(guān)注我的人：所有新關(guān)注我的人都會有消息通知，如果覺得消息太多可以選擇屏蔽掉。
獲得的贊與感謝：就是你的回答、評論有了新的贊或者感謝，這里的感謝對排名沒有影響。
私信：這個包含系統(tǒng)消息，以及站內(nèi)私信，站內(nèi)私信用于知乎的一些系統(tǒng)通知，或者用戶間的私信，知乎把他單獨拿出來也是為了怕重要信息被其他信息淹沒了。
知乎也為了減少用戶不喜歡的低質(zhì)量的回答給用戶推送消息造成的困擾，還有一個類似灰度測試的機制，簡單來說，就是某個問題下方有一個新的回答以后，選擇關(guān)注這個問題的人不會立刻全部收到通知，而是先有一小部分人會收到通知，根據(jù)這一小部分人的投票來決定是否推送消息給更多的人，如果先收到通知的這一小部分人覺得這個回答很贊，選擇了點贊的人更多，那么系統(tǒng)會把這個回答的消息推送給其他的人，如果先收到通知的這一小部分人覺得這個回答很差，選擇無視或者反對的人更多，那么這個回答的消息就不會推送給更多的人。
比如，某個同學(xué)7. 24 日回答了問題《面試的時候，如何做自我介紹》，當(dāng)時他的回答沒有人點贊，所以我沒有收到消息通知。
接下來1- 2 天內(nèi)，他的答案被收到消息提醒的人看到，并選擇了點贊，那么就會推送給更多的人，于是我在7. 25 日收到了他的回答的提醒。
?
- https://www.jianshu.com/p/87d068d79dc7
受眾
1.受眾的特點
《知乎用戶報告》顯示，從性別、年齡以及地域等多個維度看，知乎用戶呈現(xiàn)多元化分布的趨勢。
性別上，知乎男性用戶占比 53.3%，女性用戶占比 46.7%，男女比例正在接近均衡。
年齡上，36-40 歲的用戶在知乎占比 14%，24 歲以下的新新人類和 25-35 歲的社會中堅，則分別占比 22% 和 61% ,后兩類用戶正是知乎的核心群體。
地域上，知乎用戶的分布相對均衡，從一線城市到五線城市都有知乎的用戶，其中一線、新一線、二線城市用戶占比為 41.4%。可以說，新興中產(chǎn)和影響力人群已經(jīng)成為知乎用戶的主流。
關(guān)于簡書的受眾，并沒有公開數(shù)據(jù)。不過，簡書創(chuàng)始人林立 2015 年底在接受 ifanr 網(wǎng)的采訪中曾提到，根據(jù)簡書對用戶的抽樣調(diào)查，發(fā)現(xiàn)簡書的用戶群體高度年輕化，超過 60% 的用戶是 90 后，00 后的比例在 20% 左右，剩下則是 80 后。其中大學(xué)學(xué)歷及以上占 75%，高中學(xué)歷占 15% 左右。
2.受眾的行為動機
《知乎用戶報告》顯示，用戶使用知乎的主要目的是學(xué)習(xí)知識與自我提升，關(guān)注討論興趣話題，提問和查找專業(yè)領(lǐng)域知識，分享自己的知識和經(jīng)驗，追熱點，結(jié)識大牛等等。
簡書最開始是做編輯器，只提供寫作，慢慢才發(fā)展出瀏覽功能，所以，簡書的受眾和傳播者一直是高度重合的，寫作是簡書用戶使用簡書的最重要的動機。
3.受眾的價值
《知乎用戶報告》顯示，知乎高學(xué)歷人群占比達到80.1%，碩士及以上人群比例高于總體水平，近兩成用戶擁有海外留學(xué)經(jīng)歷；從月收入分布來看，占比 76% 的高收入人群和小康人群是使用知乎的主力，月收入 1 萬元以上用戶占比 30%，2 萬元以上家庭月收入用戶占比 41%；可投資資產(chǎn) 10 萬元以上的用戶占比 36% 。
知乎用戶的高學(xué)歷、高收入、高購買力讓其整個受眾群體呈現(xiàn)出高價值特性。在受眾價值上，短期內(nèi)，簡書是無法企及的。
2.平臺引導(dǎo)型
1）平臺認證
知乎的用戶標(biāo)識分為兩部分：「優(yōu)秀回答者」和「個人與機構(gòu)認證」。
「優(yōu)秀回答者」在知乎貢獻了大量專業(yè)內(nèi)容，他們大多數(shù)人深耕于自己的專業(yè)領(lǐng)域，持續(xù)在知乎上分享著知識、經(jīng)驗和見解。知乎通過算法將這些優(yōu)秀回答者識別出來，在他們的個人主頁和用戶名旁邊帶上了橙色的標(biāo)識。
「優(yōu)秀回答者」的計算主要參考用戶在特定領(lǐng)域內(nèi)的話題權(quán)重。高權(quán)重用戶的回答會具有一定的排序優(yōu)勢。其投票會對回答排序有更大的影響。提高自己在知乎某個領(lǐng)域下的權(quán)重只有一個方法：在這個領(lǐng)域下書寫高質(zhì)量的回答。
知乎目前已開放認證的機構(gòu)認證領(lǐng)域有：
有正規(guī)資質(zhì)的組織機構(gòu)
目前已開放認證的個人認證領(lǐng)域有：
公眾人物，包括：知名作家、導(dǎo)演、演員、歌手、運動員等（目前僅接受運營邀請嘉賓開通）；
科研教學(xué)人員，包括國內(nèi)外知名高校的教研人員，博士學(xué)歷、博士在讀；
知名企業(yè)中高層管理人員；
金融領(lǐng)域執(zhí)業(yè)資格證持證人，包括：注冊會計師（CPA）等；
法律服務(wù)業(yè)，包括執(zhí)業(yè)律師、律師事務(wù)所合伙人、專利代理人；
醫(yī)療行業(yè)，包括執(zhí)業(yè)醫(yī)師；
工程師，包括：一級注冊建筑師、一級注冊建造師等。
知乎的身份認證本身并不包含任何差異化的權(quán)限或權(quán)益，只是代表著交流和討論的誠意。
簡書的用戶標(biāo)識主要有：「簽約作者」和「優(yōu)質(zhì)作者」
目前簡書簽約作者下設(shè)兩個方向，出版方向與課程方向，希望申請簽約作者，需通過出版（即簡書版權(quán)作者）和課程（即簡書大學(xué)堂講師）兩個方向來進行申請，純優(yōu)質(zhì)內(nèi)容作者將不再接受申請。
不同于簽約作者致力于版權(quán)及課程領(lǐng)域的開發(fā)合作，內(nèi)容領(lǐng)域優(yōu)質(zhì)作者是從不同領(lǐng)域的內(nèi)容維度，對于簡書作者文章的認可。目前主要是邀請制，也可以自薦。
目前開放認證的領(lǐng)域有：科技、歷史、人文、故事、影視、旅行、生活、觀察、連載小說、漫畫、體育、二次元、經(jīng)管、游戲、兒童故事、程序員、科普等。
和知乎不同的是，簡書內(nèi)容領(lǐng)域優(yōu)質(zhì)作者享有一定的特權(quán)，比如，在投稿專題和首頁時享有無需審核的權(quán)利。
通過對比可以發(fā)現(xiàn)，知乎在商業(yè)化進程上走得更遠，而簡書對于優(yōu)質(zhì)用戶變現(xiàn)的想法則更為成熟。?
2）平臺推薦
知乎在特定專題主頁下，設(shè)置了活躍回答者推薦版塊，官方并未公布具體算法，但通過觀察可以發(fā)現(xiàn)，活躍回答者和優(yōu)秀回答者的重合度非常高。
傳播效果
1.分發(fā)機制
知乎采用“去中心化”的內(nèi)容運營方式，給用戶很高的自由度，也促使用戶更快地獲取社交關(guān)系。知乎的首頁經(jīng)歷了多次改版，但總的來說是“以人為本”的推薦機制，絕大部分內(nèi)容是用戶關(guān)注的人和話題相關(guān)內(nèi)容。
當(dāng)用戶在問題下進行回答后，相關(guān)的回答也會陸續(xù)分發(fā)給問題的關(guān)注者。編輯推薦以及熱門內(nèi)容則顯示在第二個欄目中，曝光量大幅降低。
而簡書采用“中心化”的內(nèi)容運營思路，用戶通過“投稿”機制向?qū)ｎ}或主頁進行投稿，簡書的內(nèi)容運營團隊和相關(guān)專題主編，通過人工篩選的方式，選出合適的稿件投放在首頁。
簡書首頁除了人工篩選推薦的稿件外，由用戶互動產(chǎn)生的熱門內(nèi)容也獲得了很重要的展示位，比如新上榜、7 日熱門、30 日熱門等。
簡書用戶關(guān)注的內(nèi)容則間接顯示在第二個欄目中，曝光量大幅降低。
可以看到，知乎和簡書的分發(fā)邏輯是完全不同的。在知乎上想要獲得更大曝光，最好的辦法是尋找熱門話題和高關(guān)注度的問題進行回答，而簡書上最重要的是迎合各專題及首頁的編輯，獲得上首頁的機會。
2.?排序機制
根據(jù)知乎產(chǎn)品總監(jiān)@黃濤的說法，老版知乎回答的排序算法可以簡化成：
得分 = 加權(quán)贊同數(shù) - 加權(quán)反對數(shù)
新版算法在此基礎(chǔ)上進行了改進，增加了“贊同/反對”這一變量，主要的目的是，使得新增的優(yōu)質(zhì)回答能夠有機會排到前面，綜合起來，可以總結(jié)出影響知乎回答排序的主要因素：
獲得贊同會使回答的排序上升，獲得反對則會下降
獲得高權(quán)重用戶的贊同很關(guān)鍵
“贊同/反對”的值較高能獲得更多曝光
注：用戶在一系列相關(guān)話題下發(fā)布的全部回答所得到贊同、反對、沒有幫助票數(shù)決定用戶在該領(lǐng)域下的權(quán)重，在知乎上創(chuàng)作了專業(yè)、嚴(yán)謹(jǐn)、認真的高質(zhì)量回答的人，在他擅長的領(lǐng)域里，有更大的判斷力（即權(quán)重）。
可以看出，用戶的參與對知乎回答的排序影響非常大。而簡書的排序則以時間軸為主，主要由編輯人工篩選排序。
?
?
?
?
?
?
?
?
http://kb.cnblogs.com/page/512250/ 也許很多人還不知道，知乎在規(guī)模上是僅次于百度貼吧和豆瓣的中文互聯(lián)網(wǎng)最大的UGC(用戶生成內(nèi)容)社區(qū)。知乎創(chuàng)業(yè)三年來，從0開始，到現(xiàn)在已經(jīng)有了100多臺服務(wù)器。目前知乎的注冊用戶超過了1100萬，每個月有超過8000萬人使用；網(wǎng)站每個月的PV超過2.2億，差不多每秒鐘的動態(tài)請求超過2500。
?
在ArchSummit北京2014大會上，知乎聯(lián)合創(chuàng)始人兼 CTO李申申帶來了知乎創(chuàng)業(yè)三年多來的首次全面技術(shù)分享（幻燈片下載）。本文系根據(jù)演講內(nèi)容整理而成。
?
初期架構(gòu)選型
?
在2010年10月真正開始動手做知乎這個產(chǎn)品時，包含李申申在內(nèi)，最初只有兩位工程師；到2010年12月份上線時，工程師是四個。
?
知乎的主力開發(fā)語言是Python。因為Python簡單且強大，能夠快速上手，開發(fā)效率高，而且社區(qū)活躍，團隊成員也比較喜歡。
?
知乎使用的是Tornado框架。因為它支持異步，很適合做實時Comet應(yīng)用，而且簡單輕量，學(xué)習(xí)成本低，再就是有FriendFeed的成熟案例，Facebook的社區(qū)支持。知乎的產(chǎn)品有個特性，就是希望跟瀏覽器端建立一個長連接，便于實時推送Feed和通知，所以Tornado比較合適。
?
最初整個團隊的精力全部放在產(chǎn)品功能的開發(fā)上，而其他方面，基本上能節(jié)約時間、能省的都用最簡單的方法來解決，當(dāng)然這在后期也帶來了一些問題。
?
最初的想法是用云主機，節(jié)省成本。知乎的第一臺服務(wù)器是512MB內(nèi)存的Linode主機。但是網(wǎng)站上線后，內(nèi)測受歡迎程度超出預(yù)期，很多用戶反饋網(wǎng)站很慢。跨國網(wǎng)絡(luò)延遲比想象的要大，特別是國內(nèi)的網(wǎng)絡(luò)不均衡，全國各地用戶訪問的情況都不太一樣。這個問題，再加上當(dāng)時要做域名備案，知乎又回到了自己買機器找機房的老路上。
?
買了機器、找了機房之后又遇到了新的問題，服務(wù)經(jīng)常宕掉。當(dāng)時服務(wù)商的機器內(nèi)存總是出問題，動不動就重啟。終于有一次機器宕掉起不來了，這時知乎就做了Web和數(shù)據(jù)庫的高可用。創(chuàng)業(yè)就是這樣一個情況，永遠不知道明早醒來的時候會面臨什么樣的問題。
這是當(dāng)時那個階段的架構(gòu)圖，Web和數(shù)據(jù)庫都做了主從。當(dāng)時的圖片服務(wù)托管在又拍云上。除了主從，為了性能更好還做了讀寫分離。為解決同步問題，又添加了一個服務(wù)器來跑離線腳本，避免對線上服務(wù)造成響應(yīng)延遲。另外，為改進內(nèi)網(wǎng)的吞吐量延遲，還更換了設(shè)備，使整個內(nèi)網(wǎng)的吞吐量翻了20倍。
?
在2011年上半年時，知乎對Redis已經(jīng)很依賴。除了最開始的隊列、搜索在用，后來像Cache也開始使用，單機存儲成為瓶頸，所以引入了分片，同時做了一致性。
?
知乎團隊是一個很相信工具的團隊，相信工具可以提升效率。工具其實是一個過程，工具并沒有所謂的最好的工具，只有最適合的工具。而且它是在整個過程中，隨著整個狀態(tài)的變化、環(huán)境的變化在不斷發(fā)生變化的。知乎自己開發(fā)或使用過的工具包括Profiling（函數(shù)級追蹤請求，分析調(diào)優(yōu)）、Werkzeug（方便調(diào)試的工具）、Puppet（配置管理）和Shipit（一鍵上線或回滾）等。
?
日志系統(tǒng)
?
知乎最初是邀請制的，2011年下半年，知乎上線了申請注冊，沒有邀請碼的用戶也可以通過填寫一些資料申請注冊知乎。用戶量又上了一個臺階，這時就有了一些發(fā)廣告的賬戶，需要掃除廣告。日志系統(tǒng)的需求提上日程。
?
這個日志系統(tǒng)必須支持分布式收集、集中存儲、實時、可訂閱和簡單等特性。當(dāng)時調(diào)研了一些開源系統(tǒng)，比如Scribe總體不錯，但是不支持訂閱。Kafka是Scala開發(fā)的，但是團隊在Scala方面積累較少，Flume也是類似，而且比較重。所以開發(fā)團隊選擇了自己開發(fā)一個日志系統(tǒng)——Kids（Kids Is Data Stream）。顧名思義，Kids是用來匯集各種數(shù)據(jù)流的。
?
Kids參考了Scribe的思路。Kdis在每臺服務(wù)器上可以配置成Agent或Server。Agent直接接受來自應(yīng)用的消息，把消息匯集之后，可以打給下一個Agent或者直接打給中心Server。訂閱日志時，可以從Server上獲取，也可以從中心節(jié)點的一些Agent上獲取。
?
具體細節(jié)如下圖所示：
知乎還基于Kids做了一個Web小工具（Kids Explorer），支持實時看線上日志，現(xiàn)在已經(jīng)成為調(diào)試線上問題最主要的工具。
?
Kids已經(jīng)開源，放到了Github上。
?
事件驅(qū)動的架構(gòu)
?
知乎這個產(chǎn)品有一個特點，最早在添加一個答案后，后續(xù)的操作其實只有更新通知、更新動態(tài)。但是隨著整個功能的增加，又多出了一些更新索引、更新計數(shù)、內(nèi)容審查等操作，后續(xù)操作五花八門。如果按照傳統(tǒng)方式，維護邏輯會越來越龐大，維護性也會非常差。這種場景很適合事件驅(qū)動方式，所以開發(fā)團隊對整個架構(gòu)做了調(diào)整，做了事件驅(qū)動的架構(gòu)。
?
這時首先需要的是一個消息隊列，它應(yīng)該可以獲取到各種各樣的事件，而且對一致性有很高的要求。針對這個需求，知乎開發(fā)了一個叫Sink的小工具。它拿到消息后，先做本地的保存、持久化，然后再把消息分發(fā)出去。如果那臺機器掛掉了，重啟時可以完整恢復(fù)，確保消息不會丟失。然后它通過Miller開發(fā)框架，把消息放到任務(wù)隊列。Sink更像是串行消息訂閱服務(wù)，但任務(wù)需要并行化處理， Beanstalkd就派上了用場，由其對任務(wù)進行全周期管理。架構(gòu)如下圖所示：
舉例而言，如果現(xiàn)在有用戶回答了問題，首先系統(tǒng)會把問題寫到MySQL里面，把消息塞到Sink，然后把問題返回給用戶。Sink通過Miller把任務(wù)發(fā)給Beanstalkd，Worker自己可以找到任務(wù)并處理。
?
最開始上線時，每秒鐘有10個消息，然后有70個任務(wù)產(chǎn)生。現(xiàn)在每秒鐘有100個事件，有1500個任務(wù)產(chǎn)生，就是通過現(xiàn)在的事件驅(qū)動架構(gòu)支撐的。
?
頁面渲染優(yōu)化
?
知乎在2013年時每天有上百萬的PV，頁面渲染其實是計算密集型的，另外因為要獲取數(shù)據(jù)，所以也有IO密集型的特點。這時開發(fā)團隊就對頁面進行了組件化，還升級了數(shù)據(jù)獲取機制。知乎按照整個頁面組件樹的結(jié)構(gòu)，自上而下分層地獲取數(shù)據(jù)，當(dāng)上層的數(shù)據(jù)已經(jīng)獲取了，下層的數(shù)據(jù)就不需要再下去了，有幾層基本上就有幾次數(shù)據(jù)獲取。
?
結(jié)合這個思路，知乎自己做了一套模板渲染開發(fā)框架——ZhihuNode。
?
經(jīng)歷了一系列改進之后，頁面的性能大幅度提升。問題頁面從500ms 減少到150ms，Feed頁面從1s減少到600ms。
?
面向服務(wù)的架構(gòu)（SOA）
?
隨著知乎的功能越來越龐雜，整個系統(tǒng)也越來越大。知乎是怎么做的服務(wù)化呢？
?
首先需要一個最基本的RPC框架，RPC框架也經(jīng)歷了好幾版演進。
?
第一版是Wish，它是一個嚴(yán)格定義序列化的模型。傳輸層用到了STP，這是自己寫的很簡單的傳輸協(xié)議，跑在TCP上。一開始用的還不錯，因為一開始只寫了一兩個服務(wù)。但是隨著服務(wù)增多，一些問題開始出現(xiàn)，首先是ProtocolBuffer會生成一些描述代碼，很冗長，放到整個庫里顯得很丑陋。另外，嚴(yán)格的定義使其不便使用。這時有位工程師開發(fā)了新的RPC框架——Snow，它使用簡單的JSON做數(shù)據(jù)序列化。但是松散的數(shù)據(jù)定義面對的問題是，比如說服務(wù)要去升級，要改寫數(shù)據(jù)結(jié)構(gòu)，很難知道有哪幾個服務(wù)在使用，也很難通知它們，往往錯誤就發(fā)生了。于是又出了第三個RPC框架，寫RPC框架的工程師，希望結(jié)合前面兩個框架的特點，首先保持Snow簡單，其次需要相對嚴(yán)格的序列化協(xié)議。這一版本引入了Apache Avro。同時加入了特別的機制，在傳輸層和序列化協(xié)議這一層都做成了可插拔的方式，既可以用JSON，也可以用Avro，傳輸層可以用STP，也可以用二進制協(xié)議。
?
再就是搭了一個服務(wù)注冊發(fā)現(xiàn)，只需要簡單的定義服務(wù)的名字就可以找到服務(wù)在哪臺機器上。同時，知乎也有相應(yīng)的調(diào)優(yōu)的工具，基于Zipkin開發(fā)了自己的Tracing系統(tǒng)。
?
按照調(diào)用關(guān)系，知乎的服務(wù)分成了3層：聚合層、內(nèi)容層和基礎(chǔ)層。按屬性又可以分成3類：數(shù)據(jù)服務(wù)、邏輯服務(wù)和通道服務(wù)。數(shù)據(jù)服務(wù)主要是一些要做特殊數(shù)據(jù)類型的存儲，比如圖片服務(wù)。邏輯服務(wù)更多的是CPU密集、計算密集的操作，比如答案格式的定義、解析等。通道服務(wù)的特點是沒有存儲，更多是做一個轉(zhuǎn)發(fā)，比如說Sink。
這是引入服務(wù)化之后整體的架構(gòu)。
總結(jié)
- 上一篇： 罗克韦尔AB PLC RSLogix50
- 下一篇： android 系统秒表,android