Facebook如何存储大规模社交图谱(graph)?TAO

2071 2018-09-19T05:50:00.000Z

挑战是什么?

在TAO之前,用 cache-aside pattern

在TAO之前

社交图谱是存储在MySQL和缓存在Memcached里的

3个存在的问题:

  1. 在Memcached中更新社交图谱的边列表操作效率太低。不是在列表的后面加一条边,而是要更新整个列表。
  2. 客户端管理缓存的逻辑很复杂
  3. 很难维持数据库读在写之后这种一致性

为了解决这些问题,我们有3个目标:

  • 面对大规模数据仍然高效的图(graph)存储
  • 优化读操作(读写比是500:1)
    • 降低读操作的时长
    • 提高读操作的可用性(最终一致性)
  • 及时完成写操作 (先写再读)

数据模型

  • 带 unique ID 的对象 (例如用户,地址,评论)
  • 两个ID之间的关联 (例如被标记,点赞,发表)
  • 以上两个数据模型都有键值数据和时间相关数据

解决方案: TAO

  1. 加快读操作,高效处理大规模的读

    • 专门针对图做缓存
    • 在无状态的服务器层和数据库层中间加一层缓存 (参考 业务拆分)
    • 拆分数据中心 (参考 按数据分割)
  2. 及时完成写操作

    • 透写缓存(write-through cache)
    • 用follower/leader缓存去解决惊群问题
    • 异步复制
  3. 提高读操作的可用性

    • 如果读出错,则从其他可读的地方读

TAO 的架构

  • MySQL数据库 → 持久性(durability)
  • Leader缓存 → 协调每个对象的写操作
  • Follower缓存 → 用来读而不是用来写。转移所有的写操作到leader缓存。

Facebook TAO的架构

读操作的容错

Facebook TAO读操作的容错

如果这篇文章对你有帮助

在 Github 上 Follow 我 :)

下载 硅谷io App

关注互联网创业,用移动 App ,随时随地收藏和复习好文章

© 2018 硅谷io
Built with ❤️ in San Francisco