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