Facebook 的 Scaling Out 经验

最新推荐文章于 2025-11-22 05:53:33 发布

转载最新推荐文章于 2025-11-22 05:53:33 发布 · 1.3k 阅读

文章标签：

#facebook #memcached #数据库 #cache #mysql #网络

大规模系统架构同时被 3 个专栏收录

130 篇文章

订阅专栏

memcached

67 篇文章

订阅专栏

linux性能监控与调整

49 篇文章

订阅专栏

文章介绍了Facebook如何解决跨地域MySQL复制带来的缓存一致性问题。通过调整写操作流程，确保数据更新后首次读取能从数据库获取最新数据并同步缓存，有效避免了因网络延迟造成的业务冲突。

原贴： http://www.dbanotes.net/arch/facebook_scaling_out.html

Facebook 的 Scaling Out 经验

作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/arch/facebook_scaling_out.html

Facebook 其实对待技术的态度其实挺开放的。今天阅读了这篇 Scale Out, 工程师 Jason Sobel 介绍了在对付跨地域 MySQL 复制网络延迟的问题。

Cache 一致性问题解决思路

大量的 MySQL + Memcached 服务器，布署简示：

California (主 Write/Read)............. Virginia (Read Only)

主数据中心在 California ，远程中心在 Virginia 。这两个中心网络延迟就有 70ms，MySQL 数据复制延迟有的时候会达到 20ms. 如果要让只读的信息从 Virginia 端发起，Memcached 的 Cache 数据一致性就是个问题。

    1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主、从两端 Memcached 中的名字值；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中没发现用户名字，从 Virginia  Slave 数据库读取，因为网络延迟，结果读到了 "Jason"；
5 更新 Virginia Memcached 中的该用户名字为 "Jason"；
6 复制追上了，更新名字为 ""Monkey"；
7 又有人读取 Profile 了；
8 在 Memcached 中找到了键值，返回 "Jason" （实际上造成业务冲突了)

解决办法挺有意思，在 SQL 解析层嵌入了针对 Memcached 的操作。

    1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主端 Memcached 中的名字值，但Virginia 端 Memcached 不删；(这地方在 SQL 解析上作了一点手脚，把更新的操作"示意"给远程)；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中找到键值，返回值 "Jason"；
5 复制追上更新 Slave 数据库用户名字为 "Monkey"，删除 Virginia Memcached 中的键值；
6 在 Virginia 有人查看该用户 Profile ；
7 Memcache 中没找到键值，所以从 Slave 中读取，然后得到正确的 "Monkey" 。

这里面的一个简单的原则是: 更新后的数据，用户第一次读取要从数据库读，顺便扔一份到 Cache 里，而不是在写入的时候直接更新 Memcached 。避免写事务过大。

而写操作的原则是：一次写入，到处分发。

第二个问题是关于"Page Routing"的，也很有参考价值。感兴趣的自己读一下吧。

--EOF--

另推荐一下: 分布式系统中的一致性和可用性，该文是上次在支付宝 QClub 活动的总结之二。

这篇【 Facebook 的 Scaling Out 经验】来自 dbanotes.net |