知乎

春天是适宜思考的节令 梳理繁冗的知识点成为常识链， 分享你的所知、所学 【华为云知乎金牌答题官】第2期正式上线！ 咱们精选了知乎热门探讨的计算机前沿技术、云服务产品、程序员生存等话题 就等博闻强识的你来作答 让分享成为一种习惯，用常识传递力量 但凡你的答复失去用户的认可与青睐，咱们将授予相应处分 “华为云金牌答题官”流动将继续推出， 期待你成为官网认证的【最强金牌答题官】！ 01．工作介绍从华为云社区所给出的每期热门问题中抉择本人善于的进行答案撰写。 （1）泛技术畛域问题。大家能够依据本人把握的常识，施展各自的特长对用户提出的问题给出解答。参考案例： 1） VIM这么难用，为啥这么多人热衷？ 2） 在做程序员的路线上，你把握了什么概念或技术使你感觉自我晋升突飞猛进？ 3） 作为一名程序员，如何能力码出优质代码？ 4） 如果从新设计 它会是什么样的？ 5） CPython有GIL是因为当年设计CPython的人偷懒吗？ （2）华为云技术及产品相干话题。能够联合华为云相干技术及产品对用户问题进行解答。参考案例： 1） 有什么工具能帮忙程序员写代码（开发）？ 2） 中 台和微服务有什么区别？ 3） 如何对待小程序云开发把程序员的准入门槛升高？那怎么掂量一个程序员的价值？ 4） 什么是 DDoS 攻打？ （3）列表中没有给出，然而和程序员关怀的技术高度相干的问题。此类问题在提交答案时须要附带问题链接。 02．参加流程① 从公布的题库中抉择本人想要答复的问题进行答案撰写 ② 实现答案创作后提交给华为云社区小编，邮箱songli14@huawei.com（问题链接+答案） ③ 华为云社区小编对提报者上交的内容进行优化编辑 ④ 华为云社区小编在华为云官网知乎账号【华为云开发者社区】铺发答案 ⑤ 数据统计，并于次月评比发放处分 ⑥ 本期问题库公布后10日内交稿 03．内容要求所有提交的内容答案默认受权华为云社区官网自在应用，且其中不得蕴含攻击性或不实信息。以Word文档模式输入。 ① 文字简练：通过谨严和业余的文字进行答案撰写，所有内容为原创不可剽窃，字数500-1500为佳； ② 思路清晰：整篇内容逻辑清晰，观点输入精确，语句通顺； ③ 构造工整：构造明显，排版工整，文中须要适当用小标题进行宰割； ④ 图文并茂：可能在文中精确的配图，让答案内容更加丰盛易于了解； ⑤ 引人入胜：答案内容具备吸引力——抓人眼球，文采好，为加分项。 04．处分答案公布后华为云社区编辑部将会依据所取得的浏览量、点赞量、珍藏评论数等进行综合考核，给予处分，50~500元/篇（以等值社区礼品模式进行发放） 05．报名形式实现答案创作后提交给华为云社区小编，邮箱songli14@huawei.com 问题数量无限，以提交先后为准！反复提交则依照单条答案的浏览量、点赞量、珍藏评论数进行处分评比 点此查看本期热门选题，期待你的大作哦！

作者：孙晓光，知乎搜索后端负责人，目前承担知乎搜索后端架构设计以及工程团队的管理工作。曾多年从事私有云相关产品开发工作关注云原生技术，TiKV 项目 Committer。 本文根据孙晓光老师在 TiDB TechDay 2019 北京站上的演讲整理。 本次分享首先将从宏观的角度介绍知乎已读服务的业务场景中的挑战、架构设计思路，然后将从微观的角度介绍其中的关键组件的实现，最后分享在整个过程中 TiDB 帮助我们解决了什么样的问题，以及 TiDB 是如何帮助我们将庞大的系统全面云化，并推进到一个非常理想的状态的。 一、业务场景知乎从问答起步，在过去的 8 年中逐步成长为一个大规模的综合性知识内容平台，目前，知乎上有多达 3000 万个问题，共收获了超过 1.3 亿个回答，同时知乎还沉淀了数量众多的文章、电子书以及其他付费内容，目前注册用户数是 2.2 亿，这几个数字还是蛮惊人的。我们有 1.3 亿个回答，还有更多的专栏文章，所以如何高效的把用户最感兴趣的优质内容分发他们，就是非常重要的问题。 <center>图 1</center> 知乎首页是解决流量分发的一个关键的入口，而已读服务想要帮助知乎首页解决的问题是，如何在首页中给用户推荐感兴趣的内容，同时避免给用户推荐曾经看过的内容。已读服务会将所有知乎站上用户深入阅读或快速掠过的内容记录下来长期保存，并将这些数据应用于首页推荐信息流和个性化推送的已读过滤。图 2 是一个典型的流程： <center>图 2</center> 当用户打开知乎进入推荐页的时候，系统向首页服务发起请求拉取“用户感兴趣的新内容”，首页根据用户画像，去多个召回队列召回新的候选内容，这些召回的新内容中可能有部分是用户曾经看到过的，所以在分发给用户之前，首页会先把这些内容发给已读服务过滤，然后做进一步加工并最终返回给客户端，其实这个业务流程是非常简单的。 <center>图 3</center> 这个业务第一个的特点是可用性要求非常高，因为首页可能是知乎最重要的流量分发渠道。第二个特点是写入量非常大，峰值每秒写入 40k+ 条记录，每日新增记录近 30 亿条。并且我们保存数据的时间比较长，按照现在产品设计需要保存三年。整个产品迭代到现在，已经保存了约一万三千亿条记录，按照每月近一千亿条的记录增长速度，大概两年之后，可能要膨胀到三万亿的数据规模。 <center>图 4</center> 这个业务的查询端要求也很高。首先，产品吞吐高。用户在线上每次刷新首页，至少要查一次，并且因为有多个召回源和并发的存在，查询吞吐量还可能放大。峰值时间首页每秒大概产生 3 万次独立的已读查询，每次查询平均要查 400 个文档，长尾部分大概 1000 个文档，也就是说，整个系统峰值平均每秒大概处理 1200 万份文档的已读查询。在这样一个吞吐量级下，要求的响应时间还比较严格，要求整个查询响应时间（端到端超时）是 90ms，也就意味着最慢的长尾查询都不能超过 90ms。还有一个特点是，它可以容忍 false positive，意味着有些内容被我们过滤掉了，但是系统仍然能为用户召回足够多的他们可能感兴趣的内容，只要 false positive rate 被控制在可接受的范围就可以了。 二、架构设计由于知乎首页的重要性，我们在设计这个系统的时候，考虑了三个设计目标：高可用、高性能、易扩展。首先，如果用户打开知乎首页刷到大量已经看过的内容，这肯定不可接受，所以对已读服务的第一个要求是「高可用」。第二个要求是「性能高」，因为业务吞吐高，并且对响应时间要求也非常高。第三点是这个系统在不断演进和发展，业务也在不断的更新迭代，所以系统的「扩展性」非常重要，不能说今天能支撑，明天就支撑不下来了，这是没法接受的。 接下来从这三个方面来介绍我们具体是如何设计系统架构的。 2.1 高可用 ...