TiDB 在知乎万亿量级业务数据下的实践和挑战.docxVIP

TiDB 在知乎万亿量级业务数据下的实践和挑战 知乎从问答起步，在过去的 8 年中逐渐成长为一个大规模的综合性学问内容平台，目前，知乎上有多达 3000 万个问题，共收获了超过 1.3 亿个回答，同时知乎还沉淀了数量众多的文章、电子书以及其他付费内容，目前注册用户数是 2.2 亿，这几个数字还是蛮惊人的。我们有 1.3 亿个回答，还有更多的专栏文章，所以如何高效的把用户最感爱好的优质内容分发他们，就是格外重要的问题。 图 1 知乎首页是处理流量分发的一个关键的入口，而已读服务想要挂念知乎首页处理的问题是，如何在首页中给用户推举感爱好的内容，同时避开给用户推举已经看过的内容。已读服务会将全部知乎站上用户深化阅读或快速拂过的内容记录下来长期保存，并将这些数据应用于首页推举信息流和共性化推送的已读过滤。图 2 是一个典型的流程： 图 2 当用户打开知乎进入推举页的时候，系统向首页服务发起恳求拉取“用户感爱好的新内容”，首页依据用户画像，去多个召回队列召回新的候选内容，这些召回的新内容中可能有部分是用户已经看到过的，所以在分发给用户之前，首页会先把这些内容发给已读服务过滤，然后做进一步加工并最终前往给客户端，其实这个业务流程是格外简约的。 图 3 这个业务第一个的特点是可用性要求格外高，由于首页可能是知乎最重要的流量分发渠道。其次个特点是写入量格外大，峰值每秒写入 40k+ 条记录，每日新增记录近 30 亿条。并且我们保存数据的时间比较长，依据现在产品设计需要保存三年。整个产品迭代到现在，已经保存了约一万三千亿条记录，依据每月近一千亿条的记录增长速度，或许两年之后，可能要膨胀到三万亿的数据规模。 图 4 这个业务的查询端要求也很高。首先，产品吞吐高。用户在线上每次刷新首页，至少要查一次，并且由于有多个召回源和并发的存在，查询吞吐量还可能放大。峰值时间首页每秒或许产生 3 万次独立的已读查询，每次查询平均要查 400 个文档，长尾部分或许 1000 个文档，也就是说，整个系统峰值平均每秒或许处理 1200 万份文档的已读查询。在这样一个吞吐量级下，要求的响应时间还比较严格，要求整个查询响应时间（端到端超时）是 90ms，也就意味着最慢的长尾查询都不能超过 90ms。还有一个特点是，它可以容忍 false positive，意味着有些内容被我们过滤掉了，但是系统仍旧能为用户召回足够多的他们可能感爱好的内容，只需 false positive rate 被把握在可接受的范围就可以了。 二、架构设计 由于知乎首页的重要性，我们在设计这个系统的时候，考虑了三个设计目标：高可用、高功能、易扩展。首先，假如用户打开知乎首页刷到大量已经看过的内容，这确定不行接受，所以对已读服务的第一个要求是「高可用」。其次个要求是「功能高」，由于业务吞吐高，并且对响应时间要求也格外高。第三点是这个系统在不断演进和进展，业务也在不断的更新迭代，所以系统的「扩展性」格外重要，不能说今日能支撑，明天就支撑不下来了，这是没法接受的。 接下来从这三个方面来引见我们具体是如何设计系统架构的。 2.1 高可用 图 5 当我们争辩高可用的时候，也意味着我们已经意识到毛病是无时无刻都在发生的，想让系统做到高可用，首先就要有系统化的毛病探测机制，检测组件的健康情况，然后设计好每一个组件的自愈机制，让它们在毛病发生之后可以自动恢复，无需人工干涉。最终我们期望用肯定的机制把这些毛病所产生的变化隔离起来，让业务侧尽可能对毛病的发生和恢复无感知。 2.2 高功能 图 6 对常见的系统来说，越核心的组件往往形态越重扩展的代价也越大，层层拦截快速降低需要深化到核心组件的恳求量对提高功能是格外有效的手段。首先我们通过缓冲分 Slot 的方式来扩展集群所能缓冲的数据规模。接着进一步在 Slot 内通过多副本的方式提升单个 Slot 缓冲数据集的读取吞吐，将大量的恳求拦截在系统的缓冲层进行消化。假如恳求不行避开的走到了最终的数据库组件上，我们还可以利用效率较高的压缩来连续降低落到物理设备上的 I/O 压力。 2.3 易扩展 图 7 提升系统扩展性的关键在于削减无形态组件的范围。在路由和服务发觉组件的挂念下，系统中的无形态组件可以格外轻松的扩展扩容，所以通过扩大无形态服务的范围，收缩重形态服务的比例，可以显著的挂念我们提升整个系统的可扩展性。除此之外，假如我们能够设计一些可以从外部系统恢复形态的弱形态服务，部分替代重形态组件，这样可以压缩重形态组件的比例。随着弱形态组件的扩大和重形态组件的收缩，整个系统的可扩展性可以得到进一步的提升。 2.4 已读服务最终架构 在高可用、高功能和易扩展的设计理念下，我们设计实现了已读服务的架构，图 8 是已读服务的最终架构。 图 8 首先，上层的客户端 API 和 Pro