APP开发公司 Uber何如使用MySQL + Redis提供4000万/秒的读取央求

栏目分类

热点资讯

APP开发公司 Uber何如使用MySQL + Redis提供4000万/秒的读取央求

发布日期：2024-07-22 05:16 点击次数：79

一、先容

Docstore 是 Uber 里面的散布式数据库，确立在 MySQL 之上。它存储数十PB的数据，每秒处理数千万个央求，是Uber最大的数据库引擎之一，被通盘业务垂直鸿沟的微处事所使用。自 2020 年景立以来，Docstore 用户和用例正在增长，央求量和数据占用量也在增长。业务垂直鸿沟和产物/处事的需求不停增多，引入了复杂的微处事和依赖项调用图。因此，应用要领需要数据库的低蔓延、更高的性能和可推广性，同期会产生更高的职责负载。

1.挑战

Uber 的大多数微处事都使用基于磁盘的存储支持的数据库来抓久化数据。但是，每个数据库都面对着为需要低蔓延读取拜谒和高可伸缩性的应用要领提供处事的挑战。当一个用例需要比咱们现存任何用户都高得多的读取微辞量时将相配具有挑战性。Docstore 不错餍足他们的需求，因为它由 NVMe SSD 提供支持，可提供低蔓延和高微辞量。然则，在上述场景中使用 Docstore 的本钱会过高，况且需要好多推广和运营挑战。在深远探讨挑战之前，让咱们先了解一下 Docstore 的高档架构。

2.Docstore 架构

Docstore 主要分为三层：无气象查询引擎层、有气象存储引擎层和适度面。对于本博客的范围，咱们将接洽其查询层和存储引擎层。无气象查询引擎层厚爱查询筹办、路由、分片、架构料理、节点健康监控、央求领悟、考证和 AuthN/AuthZ。存储引擎层厚爱通过 Raft、复制、事务、并发适度和负载料理来已矣共鸣。分区频繁由NVMe SSD支持的MySQL节点组成，这些节点大约处理勤劳的读取和写入职责负载。此外，使用 Raft 将数据分片到包含一个主节点和两个隶属节点的多个分区中进行共鸣。

目下，让咱们看一下当处事需要大限度低蔓延读取时面对的一些挑战：

从磁盘检索数据的速率有一个阈值：优化应用要领数据模子和查询以改善数据库蔓延和性能的进程是有限的。

垂直推广：分拨更多资源或升级到性能更高的更好主机有其局限性，数据库引擎自己会成为瓶颈。

水平推广：在更多分区中进一步拆分分片有助于在一定进程上处罚挑战，但这么作念在操作上是一个更复杂和漫长的历程。咱们必须确保数据的抓久性和弹性，而不会出现任何停机。此外，此处罚决策并不可都备匡助处罚热键/分区/分片的问题。

央求招架衡：读取央求的传入速率频繁比写入央求高几个数目级。在这种情况下，底层 MySQL 节点将难以跟上勤劳的职责负载并进一步影响蔓延。

本钱：从永久来看，通过垂直和水平推广来改善蔓延的本钱很高。本钱乘以 6 倍，以处理两个区域中的 3 个有气象节点中的每一个。此外，缩放并不可都备处罚问题。

为了克服这个问题，微处事利用了缓存。在优步，咱们提供 Redis 看成散布式缓存处罚决策。微处事的典型瞎想模式是写入数据库顺心存，同期从缓存中读取数据，以改善蔓延。但是这种方法存在以下挑战：

每个团队都必须为各自的处事预置和可贵我方的 Redis 缓存

缓存失效逻辑在每个微处事等分散已矣

在区域故障弯曲的情况下，处事要么必须保抓缓存复制以保抓热度，要么在缓存在其他区域预热时碰到更高的蔓延

各个团队必须破耗大都元气心灵来使用数据库已矣我方的自界说缓存处罚决策。当务之急是找到一种更好、更高效的处罚决策，不仅要以低蔓延处理央求，而且要易于使用并提升开拓东谈主员的职责成果。

3.CacheFront

咱们决定构建一个集成的缓存处罚决策，即 CacheFront for Docstore，并谨记以下所在：

最大行为地减少垂直和/或水平推广的需求，以支持低蔓延读取央求

减少对数据库引擎层的资源分拨;缓存不错从相对低廉的主机构建，因此举座本钱效益得到提升

改善 P50 和 P99 蔓延，并稳当微突发时期的读取蔓延峰值

替换大多数由各个团队构建（或将要）构建的自界说缓存处罚决策，以餍足他们的需求，尤其是在缓存不是团队的中枢业务或材干的情况下

通过重用现存的 Docstore 客户端使其透明，无需任何特殊的处理，从而允许从缓存中受益

提升开拓东谈主员的职责成果，并允许咱们向客户透明地发布新功能或替换底层缓存工夫

将缓存处罚决策从 Docstore 的底层分片决策等永诀出来，幸免热键、分片或分区引起的问题

允许咱们水平横向推广缓存层，闲散于存储引擎

将可贵和调用 Redis 的通盘权从功能团队弯曲到 Docstore 团队

二、CacheFront 瞎想

1.Docstore 查询模式

Docstore 支持通过主键或分区键进行查询的不同格式，并可选拔过滤数据。轮廓地说，主要可分为以下几类：

Key-type / Filter

No Filter

Filter by WHERE clause

Rows

ReadRows

–

Partitions

ReadPartition

QueryRows

咱们但愿以增量格式构建处罚决策，从最常见的查询模式动手。事实发挥，进步 50% 的 Docstore 查询是 ReadRows 央求，而且由于这也偶而是最浅陋的用例——莫得过滤器和点读取——因此很天然地从集成动手。

2.高档体系缚构

由于 Docstore 的查询引擎层厚爱向客户端提供读取和写入处事，因此相配妥贴集成缓存层。它还将缓存与基于磁盘的存储永诀，允许咱们闲散推广其中任何一个。查询引擎层已矣了一个用于存储缓存数据的 Redis 接口，以及一种使缓存条款失效的机制。高档体系缚构如下所示：

Docstore 是一个高度一致的数据库。尽管集成缓存提供了更快的查询响应，但在使用缓存时，每个微处事可能无法袭取研究一致性的某些语义。举例，缓存失效可能会失败或滞后于数据库写入。出于这个原因，咱们将集成缓存看成一项可选功能。处事不错基于每个数据库、每个表以致每个央求建树缓存使用情况。若是某些流需要强一致性（举例在门客购物车中取得商品），则不错绕过缓存，而其他写入微辞量低的流（举例取得餐厅的菜单）将从缓存中受益。

3.缓存读取

CacheFront 使用缓存端计策来已矣缓存读取：

查询引擎层取得再增多一溜的读取央求

若是启用了缓存，请尝试从 Redis 取得行;流式传输对用户的响应

从存储引擎中检索剩余的行（若是有）

使用其余行异步填充 Redis

将剩余行流式传输给用户

三、缓存失效

“计较机科学中唯有两件贫穷的事情：缓存失效和定名。” – Phil Karlton

尽管上一节中的缓存计策可能看起来很浅陋，但必须研究好多细节以确保缓存普通职责，尤其是缓存失效。在莫得任何显式缓存失效的情况下，缓存条款将与建树的 TTL 一谈过期（默许为 5 分钟）。天然这在某些情况下可能是不错的，但大多数用户但愿改换的响应速率比 TTL 快。默许的 TTL 不错镌汰，但这会镌汰咱们的缓存掷中率，而不会特殊念念地提升一致性保证。

1.条件更新

Docstore 支持条件更新，其中不错阐述筛选条件更新一溜或多行。举例，更新指定区域中通盘连锁餐厅的假期时候表。由于给定筛选器的结果可能会改换，因此在数据库引擎中更新本色行之前，咱们的缓存层无法详情哪些即将受到条件更新的影响。因此，咱们无法在无气象查询引擎层的写入旅途中使缓存的行失效并填充条件更新。

2.利用变更数据拿获已矣缓存失效

为了处罚这个问题，咱们利用了 Docstore 的变更数据拿获和流媒体处事 Flux。Flux 追踪存储引擎层中每个集群的 MySQL 二进制日记事件，并将这些事件发布到消费者列表。Flux 为 Docstore CDC（变更数据拿获）、复制、死亡视图、数据湖给与以及考证集群中节点之间的数据一致性提供支持。编写了一个新的使用者，它订阅数据事件，并使 Redis 中的新行失效或更新安设。

目下，使用此失效计策，条件更新将导致受影响行的数据库改换事件，这些事件将用于使缓存中的行失效或填充。因此，咱们大约在数据库改换后的几秒钟内使缓存保抓一致，而不是几分钟。此外，通过使用二进制日记，咱们不会冒着让未提交的事务混浊缓存的风险。缓存失效的最终读取和写入旅途如下所示：

3.在查询引擎和 Flux 之间删除近似缓存写入

但是，上述缓存失效计策存在残障。由于写入操作在读取旅途和写入旅途之间同期发生，因此咱们可能意外中将落伍的行写入缓存，从而隐敝从数据库中检索到的最新值。为了处罚这个问题，咱们阐述 MySQL 中确立的行的时候戳来删除近似的写入，这本色上充任了它的版块。

时候戳是从 Redis 中编码的行值中领悟出来的（请参阅后头研究编解码器的部分）。Redis 支持使用 EVAL 敕令以原子格式本质自界说 Lua 剧本。此剧本选用与 MSET 相通的参数，但是，它还本质近似数据删除逻辑，查验已写入缓存的任何行的时候戳值，并确保要写入的值较新。通过使用 EVAL，通盘这些都不错在单个央求中本质，而不需要在查询引擎层顺心存之间进行屡次走动。

4.为点写入提供更强的一致性保证

天然 Flux 允许咱们比仅依靠 Redis TTL 来使缓存条款过期的速率快得多，但它仍然为咱们提供了最终的一致性语义。然则，某些用例需要更强的一致性，举例读取-我方-写入，因此对于这些场景，咱们在查询引擎中添加了一个专用 API，允许咱们的用户在相应的写入完成后显式地使缓存的行失效。这使咱们大约为点写入提供更强的一致性保证，但不可为条件更新提供一致性保证，因为条件更新仍会被 Flux 失效。

5.表架构

在谨防先容已矣之前，让咱们界说几个关键术语。Docstore 表具有主键和分区键。主键（频繁称为行键）唯独象征 Docstore 表中的行，并强制本质唯独性敛迹。每个表都必须有一个主键，该主键不错由一列或多列组成。分区键是通盘这个词主键的前缀，APP开发公司用于详情即将位于哪个分片中。它们不是都备分开的，相背，分区键仅仅主键的一部分（或即是主键）。

在上头的示例中，person_id 是 person 表的主键和分区键。而对于订单，表 cust_id 是一个分区键，cust_id 和 order_id 一谈组成一个主键。

6.Redis 编解码器

由于咱们主要将缓存行读取，因此咱们不错使用给定的行键唯独象征行值。由于 Redis 键和值存储为字符串，因此咱们需要一个特殊的编解码器以 Redis 袭取的样式对 MySQL 数据进行编码。选拔了以下编解码器，因为它允许不同的数据库分享缓存资源，同期仍保抓数据进击。

7.特征

在完成高档瞎想后，咱们的处罚决策是灵验的。目下是时候研究限度和弹性了：

何照及时考证数据库顺心存之间的一致性

何如容忍区域/区域故障

何如容忍 Redis 故障

8.比拟缓存

通盘这些对于提升一致性的接洽，若是它是不可揣测的，那么它就毫无敬爱，因此咱们添加了一种特殊模式，将读取央求避讳到缓存中。回读时，咱们会比拟缓存数据和数据库数据，并考证它们是否相通。任何不匹配（缓存中存在的落伍行或缓存中存在的行，但数据库中不存在）都会被记载并看成筹办发出。通过使用 Flux 添加缓存失效，缓存的一致性为 99.99%。

9.缓存预热

Docstore 实例会生成两个不同的地舆区域，以确保高可用性和容错材干。部署是主动-主动的，这意味着不错在职何区域中发出和处理央求，况且通盘写入都不错跨区域复制。在区域故障弯曲的情况下，另一个区域必须大约处理通盘央求。此模子对 CacheFront 建议了挑战，因为缓存应耐久跨区域为暖。不然，区域故障弯曲将增多对数据库的央求数，因为启航点在故障区域中提供的流量出现缓存未掷中。这将破损咱们缩减存储引擎并回收任何容量，因为数据库负载将与莫得任何缓存时一样高。

冷缓存问题不错通过跨区域 Redis 复制来处罚，但它会带来一个问题。Docstore 有我方的跨区域复制机制。若是咱们使用 Redis 跨区域复制来复制缓存内容，咱们将有两种闲散的复制机制，这可能会导致缓存与存储引擎不一致。为了幸免 CacheFront 出现缓存不一致问题，咱们通过添加新的缓存预热模式来增强 Redis 跨区域复制组件。为了确保缓存耐久是热缓存，咱们追踪 Redis 写入流并将密钥复制到而已区域。在而已区域，读取央求不是径直更新而已缓存，而是向查询引擎层发出，在缓存未掷中时，该层从数据库读取并写入缓存，如瞎想的“缓存读取”部分所述。

通过仅在缓存未掷中时发出读取央求，咱们还幸免了存储引擎无谓要的过载。来自查询引擎层的读取行的响应流被浅陋地丢弃，因为咱们对结果并不信得过感风趣。通过复制键而不是值，咱们耐久确保缓存中的数据与其各自区域中的数据库一致，况且咱们在两个区域的 Redis 中保抓相通的缓存行职责集，同期还舍弃了使用的跨区域带宽量。

组选类型判断：最近5期排列三开出2次组六号码，本期重点关注组六号码出现。

10.负缓存

在好多读取针对不存在的行的情况下，最佳缓存负结果，而不是每次都缓存未掷中并查询数据库。为了已矣这小数，咱们在 Cachefront 中内置了负缓存。与旧例缓存填充计策类似，从数据库复返的通盘行都写入缓存，咱们还追踪已查询但未从数据库读取的任何行。这些不存在的欺诈用特殊记号写入缓存，在异日的读取中，若是找到该记号，咱们在查询数据库时会忽略该行，况且也不会将该行的任何数据复返给用户。

天然 Redis 莫得受到热分区问题的严重影响，但 Docstore 的一些大客户会产生相配多的读写央求，这在单个 Redis 集群中缓存是具有挑战性的，频繁舍弃在它不错领有的最大节点数上。为了缓解这种情况，咱们允许单个 Docstore 实例映射到多个 Redis 集群。这还不错幸免数据库都备崩溃，在单个 Redis 集群中的多个节点关闭况且缓存不适用于某些范围的密钥的情况下，不错对其发出大都央求。

但是，即使数据跨多个 Redis 集群进行分片，单个 Redis 集群关闭也可能会在数据库上产生热分片问题。为了缓解这种情况，咱们决定通过分区键对 Redis 集群进行分片，这与 Docstore 中的数据库分片决策不同。目下，咱们不错幸免在单个 Redis 集群出现故障时使单个数据库分片过载。来自失败的 Redis 分片的通盘央求都将散布在所稀有据库分片中，如下所示：

11.断路器

若是 Redis 节点出现故障，咱们但愿大约将对该节点的央求短路，以幸免 Redis 取得/确立央求的无谓要的蔓延赔本，咱们相配有信心它会失败。为此，咱们使用滑动窗口断路器。咱们计较每个时候存储桶上每个节点上的不实数，并计较滑动窗口宽度中的不实数。

断路器建树为将一小部分央求短路到该节点，与不实计数成正比。一朝达到允许的最大不实计数，断路器就会跳闸，在滑动窗口通过之前，不可再向节点发出央求。

12.自稳妥超时

咱们坚忍到，有时很难为 Redis 操作确立正确的超络续候。超络续候过短会导致 Redis 央求过早失败，从而浪费 Redis 资源并给数据库引擎带来特殊的负载。超络续候过长会影响 P99.9 和 P99.99 蔓延，在最坏的情况下，央求可能会破钞查询中传递的通盘这个词超时。

天然不错通过建树大肆较低的默许超时来缓解这些问题，但咱们可能会将超时确立得太低，因为好多央求绕过缓存并转到数据库，或者将超时确立得太高，这会导致咱们回到原始问题。咱们需要自动动态地休养央求超时，以便对 Redis 的央求的 P99 在分拨的超时内成效，同期都备减少蔓延的长尾。

建树自稳妥超时意味着允许动态休养 Redis 取得/确立超时值。通过允许自稳妥超时，咱们不错确立一个杰出于缓存央求的 P99.99 蔓延的超时，从而让 99.99% 的央求以快速响应插足缓存。剩余的 0.01% 的央求原本会破耗太万古候，但不错更快地取消并从数据库中提供处事。启用自稳妥超时后，咱们不再需要手动休养超时以匹配所需的 P99 蔓延，而只可确立最大可袭取的超时舍弃，进步该舍弃，框架就不允许进步该舍弃（因为最大超时岂论何如都是由客户端央求确立的）。