您所在的位置:主页 > 电脑网络 > 互联网 > 横向扩展(Facebook)

横向扩展(Facebook)

更新:2013-12-07    编辑:秀秀    来源:GUPUXIAZAI    人气:加载中...    字号:|

标签:Facebook  扩展  横向  百度搜索

  我在Facebook的第一个项目上投入的要比我预期的多一点点,但是我觉得这是为何我们拥有如此一个非常强大的工程组织的原因;我们还有很多难题有待解决,这里每个人都迫不及待要立刻去解决他们。我开始领会为何我们需要建造一个新的数据中心以及我们需要解决什么问题才干让他正常工作。

  有何必要?

  在东海岸建造一个新的数据中心的主要原因就是“延迟”。在一个高速连接上发送一个包横穿大陆需要大概70微秒的光阴,而对于普通的互联网用户而言,可能会需要的光阴就长得多。通过将服务器放在弗吉尼亚,我们可以大大减少给东海岸和欧洲的用户传送网页的光阴。

  第二个关注点是空间、能源和灾害恢复。在我们位于加利福尼亚的主数据中心中已经没有多少物理空间了,而弗吉尼亚的点可以给我们充沛的空间添加东西。我们还有一个类似问题就是要给予充足的电能驱动所有的服务器。最后,如果把我们限制在某个单独的地方,意味着如果出现灾害事件(断电、地震、怪兽),可能会导致Facebook长光阴无法造访。

  开始构建!

  在我们能处理使用级的问题之前,我们的小组在弗吉尼亚投入了大量的心血构建服务器和物理空间。他们还完成了数据中心之间的网络和低延迟光线通道连接。这些工作是非常巨大的工程,然而我们顶尖的团队使之看上去像是小菜一碟。

  网络和硬件都到位后,我们搭建了标准的3层架构:Web服务器,memcache服务器和MySQL数据库。在弗吉尼亚的MySQL数据库作为西海岸的数据库的从数据库(Slave)运行,所以我们花了几周的光阴复制所有的数据,然后建立同步复制流(replication stream)。

  现在硬件、网络和根基的设备都已经建立好,那现在就要面对两个主要的使用级的挑战:缓存一致性(Cache Consistency)和流量路径选择(traffic routing)。

  缓存一致性

  先说一下我们的缓存模型:当一个用户改动了数据对象后,我们的底层设施会向数据库写入新的值,并且从memcache中删除旧的值(如果存在)。下一次用户请求该用户对象的时候,我们从数据库中取出新的结果并写入memcache。后续的请求就会直接从从memcache中取出数据直到缓存过期或者被另外一次更新删除。

  这种设置在只有一套数据库的时候运行得很好,因为我们只有当数据库完成了新值的写操作之后才删除memcache中的值。这种方式保证了我们能够从数据库中获得新值并且放入memcache中。然而,当在东海岸有一个从数据库后,情况就有些棘手了。

  当我们在西海岸的主数据库中更新了一些数据之后,在东海岸的从数据库能正确反映这些新数值之前,中间有一个同步复制的延迟。通常这个延迟小于一秒钟,但是在高峰时期,它可能会延长到20秒。

  现在我们假设在更新了加利福尼亚的主数据库的同时,我们从弗吉尼亚的memcache层中删除了旧值。然后有一个对弗吉尼亚的从数据库的读操作可能由于复制延迟还是看到的旧数值。然后弗吉尼亚的memcache可能会更新为旧的(不正确)的数值,然后它可能被“困住”直到被删除。如你所见,最差的情况是弗吉尼亚的memcache层可能总是同一个版本而非正确的数据。

  考虑下面的例子:

  我将我的名字从“Jason”改成了“Monkey”

  我们把“Monkey”写入了加利福尼亚的主数据库并且从加利福尼亚和弗吉尼亚的memcache中删除了原来的名字

  有个人在弗吉尼亚造访我的信息

  在memcache中没有找到我的姓名信息,所哟我们从弗吉尼亚的从数据库中读取,由于复制的延迟获得了“Jason”

  我们将姓名“Jason”存入弗吉尼亚的memcache

  同步复制上来了,我们将名字信息在从数据库中更新为“Monkey”

  另一个人在弗吉尼亚造访我的信息

  我们在memcache中找到了名字并返回“Jason”。

  在我再更新我的名字或者数据过期需要再造访数据库之前,我的名字在弗吉尼亚会一直显示为“Jason”,在加利福尼亚显示为“Monkey”。杂乱吧?确凿。欢迎来到分布式系统的世界,在这里一致性确凿是一个难题。

<< 返回首页购买  更多 >>

您可能在找这些