开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第32天，点击查看活动详情

引子2:Facebook使用FlightTracker获得RYW@Tao

第38篇，本文仍是引子，讨论了FT的必要性的解决了什么痛点。PPT来自：www.usenix.org/conference/…

用户设备向Facebook网络服务器发送网络请求，每个服务器向TAO发送许多读写查询。如下图：

此外，社交图谱的生态系统随着时间的推移而扩大。产品从直接访问TAO转移到用表达式查询语言发出更复杂的读取查询，如过滤、跨多条边的排名或边列表交集。单靠TAO来服务所有复杂的查询是低效的，甚至是不可能的。因此，FB建立了全局二级索引服务，以优化复杂的查询。该索引系统利用异步复制来实现低延迟、高可用性。然而，它并没有提供 "RYW "的一致性。缺乏RYW一致性使得采用新的索引用例或透明地优化查询具有挑战性。

可以看看我的前面翻译的Tao论文，其实我们自己也深刻体会到，单纯的NOSQL，或TAO系统往往不能满足业务复杂查询的需要，为此他们需要全局二级索引，重点是，这套索引是异步构建的（为了不拖慢主线性能，以及，我觉得是为了解耦，不敢再去碰上线很久的稳定了很久的Tao），那么没有RYW一致性保证的全局Index系统是不可想象的！非常难用！

为了克服这一挑战，我们开发了FlightTracker：一套管理整个社会图的一致性的API和服务。FlightTracker为TAO和全球二级索引提供统一的RYW保证。FlightTracker独立于数据存储而运作。它促进了服务的解耦和简化，同时保留了效率、延迟和可用性优势。

一个假设性的例子

为了理解在没有统一的RYW一致性的情况下所面临的挑战，考虑一个由USER节点和SONG节点组成的假想图。歌曲可能有流派或标题等属性。用户可能与歌曲有关联（如<用户Luna，ENJOYS，歌曲D>）。

图2. 一个假想的应用程序的子图。

一个假想的应用程序可能希望过滤用户的朋友喜欢的某一类型的歌曲。或者，显示一个给定的用户对某一类型的歌曲的喜爱。对于一个小的歌曲列表，我们可以通过首先从TAO中获取所有的ENJOYS关联和它们附带的SONG对象，然后根据所需的属性进行过滤来天真地回答后一个查询。对于分布在许多数据库碎片中的较大的歌曲列表，一个专门的全局索引服务可以更有效地回答这种查询。

如果独立的索引服务不提供与TAO相同的一致性语义，那么在将查询卸载到独立的索引服务时必须小心。考虑到一个用户，Luna，她最近标记说她喜欢《200首歌》。从TAO查询歌曲列表将确保查询结果反映出最近的写法。一个没有 "RYW"保证的索引可能是陈旧的，并且在查询时省略了新喜欢的歌曲。这可能会导致开发人员和用户观察到陈旧的结果而产生混乱的行为。更重要的是，它限制了我们透明地优化查询的能力。

FlightTracker通过跟踪最近的、_飞行中的_写入的元数据，解决了潜在的陈旧的读取问题。当从数据存储中读取时，该元数据指定了要检索或包含的新鲜结果。我们将一组写元数据称为票据，并为每个数据存储实现一个票据的读取API**：一个确保读取反映票据中写的效果的契约。结合起来，这些基元可以在任何能够提供包含票据的读取API的后端中提供统一的 "你写 "一致性。