Facebook 的 Scaling Out 经验

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"的 ,也很有参考价值。感兴趣的自己读一下吧。

你可能感兴趣的:(Facebook 的 Scaling Out 经验)