Web2.0系统若干要处理的问题

 

Web2.0系统的负载均衡问题

1.基于硬件的负载均衡可以采用北电的Alton，F5的BIG-IP等。

2.基于软件的负载均衡根据环境不同而不同。
Linux下可以用LVS（Linux Virtual Server）
Windows 2003下可用NLB（网络负载均衡器）
Apache有自己的负载均衡器
WebSphere Edge Server Load Balancer

3. 典型的负载均衡的策略
   LVS+Squid集群
   BIG-IP+Squid
   BIG-IP+Perlbal（LiveJournal采用的方式）
   Windows 2003 Server +IIS6

 

Web2.0系统的文件存储问题

 

假设你有大量的文件（图片，视频等）需要访问。如果仅仅是少量的页面风格图片，那就不要看下去了。

1.图片能小则小，尽量使用JPEG，GIF，PNG的图片格式，切忌使用BMP格式。
如果提供了图片上传功能，一定要限制用户上传BMP格式的图片，除非BMP是必要的。

2.图片尽量放在不同的磁盘上，提前规划好图片的存储策略：比如按照时间分段存储，提高IO性能。

3.可能的话设定图片服务器，为图片服务器提供独立的域名。这样可以降低页面访问服务器的压力，又能
避免因图片下载失败导致的页面失败。

4.如果你有能力部署MogileFS分布式文件系统，那是最好不过的了。

5.适当的缓存，可以极大的提高性能。类似Squid的web代理服务器都有较好的cache能力。

6.选择好磁盘，要知道15000转的SCSI硬盘比10000的吞吐率高近30%。

 

Web2.0系统处理海量数据问题

面对海量数据，数据库系统该做怎样的存储策略、访问策略来应对？假设你有不止一台数据库服务器，
你的网站数据增长迅速且庞大。

1.如果用户量非常大，考虑单独拿出一台服务器来做用户信息存储、认证。可以根据用户量来拆分 用户表，比如每10万用户放在一个表上，或根据用户的地区等分类来存在不同的表上。数据库文件同样要考虑放在不同的磁盘上，以提高IO性能。一种可能的方案是：一台数据库存放所有的用户注册信息，负责用户的登录认证、用户信息更新；业务数据按用户数量定量拆分，如每200万用户的所有数据放在一台服务器上，用户登录后即可将其他的操作导向到指定的服务器上。

2.按数据性质拆分数据。比如论坛主题数据放在一台服务器上，主题评论信息放在一台服务器上。

3.按模块拆分数据。比如论坛数据放在一台服务器上，产品数据放在另外一台服务器上。不同的业务功能
被不同的数据库服务器服务，MySpace等网站在特定时期都采取过类似的做法。其问题是可能会有很多冗余的数据，比如用户信息可能会在每个数据库服务器上都存在，一个用户注册后，其注册信息必须写入多个数据库。用户信息是相对比较独立的，冗余在不同的服务器上影响不大。但是有的业务数据存在关联，被写入不同的服务器后可能会存在问题。所以这种方式也存在一些问题。

4.根据实际情况开确定是基于数据库本身的分区还是基于业务的分区。

5.多台数据库服务器并行使用时，考虑使用一些缓存系统来降低数据库的访问压力，如MemCached。
在web服务器和DB服务器间架cache服务器能大量降低DB的读操作，相同的数据从cache里拿要比从DB里
拿快的多。

6.区分读和写操作，使用独立的服务器分别应对读写操作。当然前提是能做好数据的同步。比如MySpace 初期曾经使用3台ms sql server数据库服务器，一台master处理所有的新增数据，然后master再将新增的 的数据同步到另外2台slave上，2台slave来应对大量的读操作（如显示blog数据，用户留言等），当然， master也可以同时进行读操作。如果slave太多的话，同步就需要付出更多的代价，同步都是写操作， 写占据了太多的IO后，读就会受到影响。所以slave要根据实际情况而定，不能一味的增加slave，这样 会得不偿失的。通常2-3个slave就足够了，如果还不能解决问题的话，就要考虑更改架构了。 MySQL也支持master-slave模式。

7.避免太多slave的一种方案就是slave分组。如下：
一台控制服务器，管理所有用户的注册信息，用户的其他数据被分放在不同的数据服务器组上。
一个数据服务器组由一台master和2-3台slave组成。用户注册后，应用程序负责将该用户分配到指定的数据服务器组上，这样以后用户登录后，就从第一次指定的数据服务器组上读写数据了。
要注意的是：
      在数据服务器组内的table上最好不要用自增加的ID，这样不利于以后可能的数据迁移。
      控制服务器上的用户ID可以用自增加ID。
如果控制服务器是一台的话，它挂掉了，整个系统就挂了，所以必须考虑控制服务器的单点问题。
对于Master-Slave模式的单点问题，LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的，并不是由MySQL直接提供的，实际上也就是两台机器同时是Master，也同时是Slave，互相同步。  

8.涉及到数据库集群的问题，不同的数据库都有自己的机制，实际使用时根据文档操作就是了。