超群.com的博客

另一种分布式数据中心数据同步方案

本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/10/another-way-of-sync-distributed-data-center/

通过Google Reader好友共享看到这篇文章：横向扩展（Facebook），之前看过英文原文，不过仅粗读了一下未求甚解，感谢译者的辛勤劳动。

看完全文，大意是Facebook为了解决跨地域的网络延迟问题，在东海岸新建了一个数据中心，可新的问题随之而来，MySQL数据库复制延迟、memcache缓存不同步，Facebook的工程师通过改进MySQL复制机制，在传递binlog的同时传递memcache更新指令。这样数据库同步了，memcache也更新了。

• 我将我的名字从”Jason”改为”Monkey”。
• 我将”Monkey”写入加利福尼亚的主数据库并从加利福尼亚的memcache中删除我的名字，但不包括弗吉尼亚的memcache。
• 某个人在弗吉尼亚访问了我信息。在memcache中找到了我的名字，并返回”Jason”。（注意这里，其他用户看到了过时的信息）
• 同步复制到了之后，将从数据库中我的名字更新为”Monkey”。还需要从弗吉尼亚的memcache中删除我的名字因为缓存对象出现在同步复制流中了。
• 另一个人在弗吉尼亚访问了我的信息，没有在memcache中找到我的名字，所以从从数据库读出名字，得到了”Monkey”。

关键的地方就在这里，Facebook有能力对MySQL进行改造，相信一般的公司是不敢的。其实也还有另外一种方式来实现，MySQL引入了一种叫做MySQL UDF(user defined function)的机制，有人也写了个Memcached Functions for MySQL的东东（基于libmemcached，我想应该是稳定高效吧），我们大可以在从服务器上创建触发器，这样一旦有数据更新，调用Memcached Functions for MySQL更新memcached缓存(如果写操作频繁的话，估计触发器也是瓶颈)。

文章的另一个核心是“页面路径选择”，Facebook约定了更新只在主服务器上（西海岸数据中心），东海岸的数据中心数据库服务器全部以slave形式工作，Facebook在最前端有一组负载均衡服务器，更加用户访问的URL来判断是否有写操作，如果有的话直接连接到主服务器上，如果只是页面显示则导向到从服务器上（也许是西海岸服务器），为了解决数据延迟而造成混乱的问题，Facebook在有更新的用户cookie里面加入一个标记，该标记创建后20秒内，都连主服务器（20秒足够对付延迟了吧）。

这是很有意思的一个设计，利用cookie标记用户是否更新过。但问题就是只是自己看到自己最新的数据，其他人有个20秒看到的是过时的数据。

其实是不是可以试试把标记信息放服务器端（如DNS解析部分），比如A用户更新了某些数据，在服务器端做下标记，20秒内请求到这些资源的时候走主服务器。标记大可以用bdb存储，效率就不是问题了。下面是流程：

• 我将我的名字从”Jason”改为”Monkey”。
• 我将”Monkey”写入加利福尼亚的主数据库并从加利福尼亚的memcache中删除我的名字，但不包括弗吉尼亚的memcache。
• 在服务器端标记我的名字改变了。
• 某个人访问了我信息，查出我的信息更改过，走主服务器。
• 同步复制到了之后，将从数据库中我的名字更新为”Monkey”，触发器工作，删除相应memcache缓存。
• 20秒后，负载均衡端标记失效，另一个人在弗吉尼亚访问了我的信息，没有在memcache中找到我的名字，所以从从数据库读出名字，得到了”Monkey”。

也是很折腾的一种方案，我这里没有那样的环境，所以也只是理论上的思考，有条件的可以试试看效果如何。

Tags: memcached, Mysql