Jun 1

大型Web2.0站点构建技术初探 不指定

碟舞飞扬 , 00:30 , 服务器类 , 评论(0) , 引用(0) , 阅读(8500) , Via 本站原创 | |

七、 从LiveJournal后台发展看大规模网站性能优化方法

LiveJournal是99年始于校园中的项目,几个人出于爱好做了这样一个应用,以实现以下功能:

博客,论坛

社会性网络,找到朋友

聚合,把朋友的文章聚合在一起

LiveJournal采用了大量的开源软件,甚至它本身也是一个开源软件。

在上线后,LiveJournal实现了非常快速的增长:

2004年4月份:280万注册用户。

2005年4月份:680万注册用户。

2005年8月份:790万注册用户。

达到了每秒钟上千次的页面请求及处理。

使用了大量MySQL服务器。

使用了大量通用组件。

二、LiveJournal架构现状概况
点击在新窗口中浏览此图片
三、从LiveJournal发展中学习

LiveJournal从1台服务器发展到100台服务器,这其中经历了无数的伤痛,但同时也摸索出了解决这些问题的方法,通过对 LiveJournal的学习,可以让我们避免LJ曾经犯过的错误,并且从一开始就对系统进行良好的设计,以避免后期的痛苦。

下面我们一步一步看LJ发展的脚步。

1、一台服务器

一台别人捐助的服务器,LJ最初就跑在上面,就像Google开始时候用的破服务器一样,值得我们尊敬。这个阶段,LJ的人以惊人的速度熟悉的 Unix的操作管理,服务器性能出现过问题,不过还好,可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。

最终问题出现了,网站越来越慢,已经无法通过优过化来解决的地步,需要更多的服务器,这时LJ开始提供付费服务,可能是想通过这些钱来购买新的服务 器,以解决当时的困境。

毫无疑问,当时LJ存在巨大的单点问题,所有的东西都在那台服务器的铁皮盒子里装着。
点击在新窗口中浏览此图片
2、两台服务器

用付费服务赚来的钱LJ买了两台服务器:一台叫做Kenny的Dell 6U机器用于提供Web服务,一台叫做Cartman的Dell 6U服务器用于提供数据库服务。
点击在新窗口中浏览此图片
LJ有了更大的磁盘,更多的计算资源。但同时网络结构还是非常简单,每台机器两块网卡,Cartman通过内网为Kenny提供MySQL数据库服 务。

暂时解决了负载的问题,新的问题又出现了:

原来的一个单点变成了两个单点。

没有冷备份或热备份。

网站速度慢的问题又开始出现了,没办法,增长太快了。

Web服务器上CPU达到上限,需要更多的Web服务器。

3、四台服务器

又买了两台,Kyle和Stan,这次都是1U的,都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台 Web服务器上进行负载均横。
点击在新窗口中浏览此图片
LJ把Kenny用于外部的网关,使用mod_backhand进行负载均横。

然后问题又出现了:

单点故障。数据库和用于做网关的Web服务器都是单点,一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持 心跳同步迅速切换,但还是无法解决数据库的单点,LJ当时也没做这个。
网站又变慢了,这次是因为IO和数据库的问题,问题是怎么往应用里面添加 数据库呢?

4、五台服务器

又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式),写操作全部针对主数据库(通过 Binlog,主服务器上的写操作可以迅速同步到从服务器上),读操作在两个数据库上同时进行(也算是负载均横的一种吧)。
点击在新窗口中浏览此图片
实现同步时要注意几个事项:

读操作数据库选择算法处理,要选一个当前负载轻一点的数据库。 在从数据库服务器上只能进行读操作。备好应对同步过程中的延迟,处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可,读操作不存在同步问 题。

5、更多服务器

有钱了,当然要多买些服务器。部署后快了没多久,又开始慢了。这次有更多的Web服务器,更多的数据库服务器,存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。
点击在新窗口中浏览此图片
6、现在我们在哪里:
点击在新窗口中浏览此图片
现在服务器基本上够了,但性能还是有问题,原因出在架构上。

数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内,这样唯一的好处就是将读操作分布到了多台机器,但这样带来的后果就 是写操作被大量分发,每台机器都要执行,服务器越多,浪费就越大,随着写操作的增加,用于服务读操作的资源越来越少。
点击在新窗口中浏览此图片
由一台分布到两台
点击在新窗口中浏览此图片
最终效果

现在我们发现,我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID,数据库也进行了备份,这么多的备份完全是对资源的 浪费,属于冗余极端过度。那为什么不把数据分布存储呢?

问题发现了,开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储,以实现数据的分布式存储,让每台机器只为相对固定的 用户服务,以实现平行的架构和良好的可扩展性。

为了实现用户分组,我们需要为每一个用户分配一个组标记,用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个 slave组成,并且slave的数量在2-3台,以实现系统资源的最合理分配,既保证数据读操作分布,又避免数据过度冗余以及同步操作对系统资源的过度 消耗。
点击在新窗口中浏览此图片
由一台(一组)中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上,所有针对用户的操作需要先查询这台机器得到用户的组号,然后再 到相应的数据库组中获取数据。

这样的用户架构与目前LJ的架构已经很相像了。

在具体的实现时需要注意几个问题:

在数据库组内不要使用自增ID,以便于以后在数据库组之间迁移用户,以实现更合理的I/O,磁盘空间及负载分布。

将userid,postid存储在全局服务器上,可以使用自增,数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库 InnoDB。

在数据库组之间迁移用户时要万分小心,当迁移时用户不能有写操作。

7、现在我们在哪里
点击在新窗口中浏览此图片
问题:

一个全局主服务器,挂掉的话所有用户注册及写操作就挂掉。
每个数据库组一个主服务器,挂掉的话这组用户的写操作就挂掉。
数据库 组从服务器挂掉的话会导致其它服务器负载过大。
对于Master-Slave模式的单点问题,LJ采取了Master-Master模式来解 决。所谓Master-Master实际上是人工实现的,并不是由MySQL直接提供的,实际上也就是两台机器同时是Master,也同时是Slave, 互相同步。

Master-Master实现时需要注意:

一个Master出错后恢复同步,最好由服务器自动完成。
数字分配,由于同时在两台机器上写,有些ID可能会冲突。
解决方案:

奇偶数分配ID,一台机器上写奇数,一台机器上写偶数
通过全局服务器进行分配(LJ采用的做法)。
Master-Master 模式还有一种用法,这种方法与前一种相比,仍然保持两台机器的同步,但只有一台机器提供服务(读和写),在每天晚上的时候进行轮换,或者出现问题的时候进 行切换。
内文分页: [1] [2] [3] [4]
Tags: ,
发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]