社区系统调研

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. 排序机制

根据知乎产品总监@黄涛的说法，老版知乎回答的排序算法可以简化成：

得分 = 加权赞同数 - 加权反对数

新版算法在此基础上进行了改进，增加了“赞同/反对”这一变量，主要的目的是，使得新增的优质回答能够有机会排到前面，综合起来，可以总结出影响知乎回答排序的主要因素：

获得赞同会使回答的排序上升，获得反对则会下降

获得高权重用户的赞同很关键

“赞同/反对”的值较高能获得更多曝光

注：用户在一系列相关话题下发布的全部回答所得到赞同、反对、没有帮助票数决定用户在该领域下的权重，在知乎上创作了专业、严谨、认真的高质量回答的人，在他擅长的领域里，有更大的判断力（即权重）。

可以看出，用户的参与对知乎回答的排序影响非常大。而简书的排序则以时间轴为主，主要由编辑人工筛选排序。

 

1. https://www.sohu.com/a/231648099_114819

 

 

 

 

 

 

 

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。

这是引入服务化之后整体的架构。