分类目录归档:创业

关于两个机房的讨论

如何最大限度的提升中国的网站速度,今天发信给我信任的朋友们,老冒回复如下:我朝Internet南北不畅通的解决方案(老旧方案)(需要翻墙。可以在Google Reader里面订阅http://robertmao.com/feeds/latest/访问)。很多要点老冒几乎都提到了,我在此列出我的一些问题和思考,共有用样需求的各位讨论。

1. MySQL跨越广域网的复制(Replication of MySQL)是否稳定可靠

除了老冒写到的基于页面或者部分页面的缓存方案(Squid as cache),还有一种更加冒险,但是实时性更好的方案就是在异地的数据中心建立MySQL的slave节点,进行主数据中心和附属数据中心的Master-slave replication. 按说MySQL复制本身已经是一个非常健壮和成熟的解决方案,但是跨越广域网的效果如何,尚待验证。我觉得,只要延迟平均在秒级别,偶尔出现分钟级别的延迟也可以接受,毕竟整体已经好于缓存+通知过期。

如果通过VPN+SSH在两个机房建立稳定的链路连接,把两个机房可以当成一个网络延迟稍微长一点,稍微不稳定一点的局域网来用,至少比cache方案有一个优点:可以在大动态数据量的时候,获得更好的秒级别的实时性。

同理,基于这种链路的Solr (Lucene)复制,也是一个可以考虑的架构,但是一个未知数。具体情况如何,如小马过河,只有各家自己试过才知道。

如果实现,就可以在系统级别,而非在应用代码级别实现异地的数据的自动cache, validations, rebuild。看起来很美。

2. MySQL master-master复制

除了主从方案,还有一种多中心方案。数据中心A和数据中心B各自有自己的数据库,但为了避免命名冲突,一个中心的数据采用奇数编号,另外一个采用偶数(或者等中心数大于2的时候,对某一大于中心总数的数字取模)。如果从MySQL以及绝大多数的数据库角度,这个操作非常方便。简述如下:

假设A和B在初始时候的数据是一样的,最大编号(auto_increment的上一次给出值)是401。这个时候,只要简单的把两个数据库的auto_increment_increment设成2,

auto_increment_increment = 2

并且把A的数据库的表的AUTO_INCREMENT值设成一个比现在大得多的一个奇数,比如501,B设成502就好了。跳一下的好处是,可以不用停机,在一个机房操作完成的时候有足够的时间去操作第二个机房(只要那个机房的ID增长不要碰到502就好了)。从此A的id就按照503,505向上增长,而B的id开始按照502,504增长。

另外有一种直接使用GUID作为id的方案,个人觉得太重了。

这个方案做ID切分以后,就为master-master replication做好了准备。之后两个中心可以相互实时互相复制了。开起来也很美。

但问题是,在大型系统里面,就算有再成熟的技术,简单的永远胜过复杂的方案。对于master-master的复制,我现在依然心有余悸。我的心理障碍就是因为以前技术支持的时候做过一个case,就是因为Windows 2000里面的Domain Controller可以master-master的复制,原理上是一个有问题,其他的可以把好的信息传过来,但实际上,一个小bug或者一个不小心的配置,可以让一台主域控制器的错误拖垮其他的所有控制器。master-master的方案在多于2个节点的时候,也需要额外的设计。

3. 关于cache

基于文件静态化的方案的好处显而易见,但是过期永远是心头的痛。对于像带有翻页这样的操作,除了第一页,其他页面的cache几乎不可能,因为谁都不愿意因为一条信息的更新,让后面的无穷无尽的翻页页面的cache重建。

对于链路层的动态加速,觉得在现在的CND提供商无法获取真正优势网络资源的实际情况下,好似概念多于实际。

所以,如果需要实时,或者准实时的加速,权衡所有方案,我觉得在异地放置Smart CDN是一个比较可行的解决方案。Smart CDN(抱歉,是我新造的词),就是前端部署的不仅仅是页面缓存,而是包括MySQL,搜索,Memcached等等一系列的服务,然后通过第一条提到的方式进行同步。这。。。。。。不是100%确信,只是一种想法。不过我相信这么做的人应该不在少数。

我这里抛砖引玉,希望有过经验的同学分享你的好主意,尤其是成功的案例。在此谢过。