手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表分类:PHP

PHP负载均衡

文章的内容写的不错,所以转载一下。
原文:http://xinsync.xju.edu.cn/index.php/archives/2946
内容如下:

XML/HTML代码
  1. 过去当运行一个大的web应用时候意味着运行一个大型的web服务器。因为你的应用吸引了大量的用户,你将不得不在你的服务器里增加更多的内存和处理器。  
  2.   
  3. 今天,’大型服务器’模式已经过去,取而代之的是大量的小服务器,使用各种各样的负载均衡技术。这是一种更可行的方法,将使硬件成本降至最低。  
  4.   
  5. ‘更多小服务器’的优势超过过去的’大型服务器’模式体现在两个方面:  
  6.   
  7.    1. 如果服务器宕机,那么负载均衡系统将停止请求到宕机的服务器,转而分发负载到其他正常运行的服务器上。  
  8.    2. 扩展你的服务器更加容易。你要做的仅仅是加入新的服务器到负载均衡系统。不需要中断你的应用运行。  
  9.   
  10. 所以,把握住这个机会:). 当然,代价就是这要求你的应用开发时增加一点复杂度。这就是本文要覆盖的内容。  
  11.   
  12. 这时你可能对自己说: ‘但是我怎么知道我正在使用负载均衡呢?’。最诚实的回答是,如果你正在问这个问题,那么答案是你多半没有在使用负载均衡系统并且你的系统不需要考虑这个问题。大多数情况,当应用成长足够大的规模时,负载均衡就需要明确提出和设置了。然而,我也偶尔看见虚拟主机公司为客户的应用做这个负载均衡,或者像下面描述的那样要自己来做。  
  13.   
  14. 在继续下面的内容之前,我要指出本文主要描述PHP的负载均衡。将来我可能会写有关数据负载均衡的文字,但是现在你必须等待。  
  15.   
  16. 注意,我一直提“web应用”而不是website,这是想区分’web应用’是那些复杂的站点往往涉及服务器端编程和数据库,而不是website那样只显示简单的静态内容。  
  17. 1. PHP文件  
  18.   
  19. 第一个问题是,如果你有大量的小型服务器,你怎么把你的php文件上传到所有的服务器上?有如下的方法供你参考:  
  20.   
  21.    1. 分别上传所有的文件到每一个服务器 , 这种方法带来的问题是:想像一下你有20个服务器,那么上传过程中这将很容易导致错误,并且更新时极有可能导致不同服务器上有不同版本的文件。  
  22.    2. 使用 ‘rsync ‘ (或类似的软件) . 这样的工具能同步本地目录和多个远程主机目录上的文件。  
  23.    3. 使用版本控制软件(如subversion ) . 这是我最喜欢的方法。用它可以很好地维护我得代码,当发布我的应用时,可以在每一个服务器上运行svn update命令同步。这种方法也使切换服务器得代码到过去的某一个版本更加容易。  
  24.    4. 使用一个文件服务器(你可能发现NFS 非常适合做这件事情). 这种方式是使用一个文件服务器来存放你的web应用. 当然,如果你的文件服务器宕机,那么多所有你的站点将不能使用。这时,你就需要花费更多的开支来恢复它。  
  25.   
  26. 选择哪种方式依赖于你的需求和你掌握的技能。如果你使用版本控制系统,那么你可能得计划一个方法如果同时执行一个更新命令更新所有服务器上的代码。然而,如果使用文件服务器,你就要实现一些失败恢复机制,防止万一服务器宕机导致请求失败。  
  27. 2. 文件上传  
  28.   
  29. 当只有一台服务器时,文件上传不是一个问题。但是当我们有多台服务器时,那么上传的文件应该怎么存放呢?上传文件的问题和跨服务器php文件存储是类似的。下面是几种可能的方案:  
  30.   
  31.    1. 把文件存储到数据库中 。大多数数据允许存储二进制数据。当你请求文件下载时,访问数据把二进制数据和相应的文件名和类型输出给用户。在使用这种方案前应该考虑数据库怎样存储你的文件。该方法的问题在于如果数据库服务器宕机将使文件不可用。  
  32.    2. 在一个文件服务器上存储上传的文件 . 与前面的介绍一样,你要安装一个文件服务器让所有web服务器共享,把所有上传的文件上传到这里,上传后所有的web服务器就都可以使用它。但是,如果文件服务器宕机,那么可能发生图像文件下载中断。  
  33.    3. 设计你自己的上传机制传输文件到服务器到每一个服务器 . 这个方法没有单个文件服务器或者数据库方案的缺陷,但是将增加你代码的复杂度。例如,如果上传到多个服务器过程中,服务器宕机,你要怎么处理?  
  34.   
  35. 用数据库存储上传文件但是设计一个文件缓存机制是一个不错的方案。当服务器接收一个文件下载请求时,首先检查缓存系统中是否有该文件,如果发现那么从缓存系统下载,否则从数据库读取并把它缓存到文件系统中。  
  36. 3. 会话(Sessions)  
  37.   
  38. 如果你熟悉php的session处理,你将可能知道默认情况下,它存储session数据在服务器的临时文件里。而且,这个文件仅仅在你请求处理的那个服务器上,但是接下来的请求可能被另外一个服务器处理,这将在另一个服务器上生成新的session。这导致session频繁地不被识别,如登录用户总是要求重新登录。  
  39.   
  40. 我推荐的方案是,要么重新php内建的session处理机制存储session数据到数据库,或者实现你自己的机制保证发送一个用户的请求到同一台服务器。  
  41. 4. 配置(Configuration)  
  42.   
  43. 尽管这个话题不是和php特别相关,我感觉还是有必要提及。当运行集群服务器时,用某种方法保持服务器之间的配置文件同步是一个好主意。如果配置文件不一致,可能导致一些非常奇怪的断断续续的行为导致很难排查这些问题。  
  44.   
  45. 我推荐使用版本控制系统单独管理他们。这样你可以为不同的项目安装存储不同的php配置文件,也可以保持所有服务器配置文件同步。  
  46. 5. 日志(Logging)  
  47.   
  48. 像配置问题一样,logging不是仅仅和php相关。但是对于保持服务器健康运行它仍然是非常重要的。没有正确的logging系统,你怎么知道如果PHP代码开始产生错误(在系统正式运行时,你总是关闭display_errors 设置,不是吗?)  
  49.   
  50. 有几种方法你可以实现logging:  
  51.   
  52.    1. 在每一个服务器上记录日志。 这是最简单的方法。每一个机器仅仅记录一个文件。好处是简单,可能只要很少的配置。但是,随着服务器数量的增多,监控每台服务器上的日志文件将变得非常困难。  
  53.    2. 记录日志到一个共享 这种方法每一个服务器仍然有这个日志文件,但是他们通过共享机制被存储在一个中央文件服务器上,这将使监控日志变得更简单。该方案的问题在于,如果文件服务器不可用将导致一个简单的日志不能写入问题最终导致整个应用崩溃。  
  54.    3. 记录日志到logging服务器 你可以使用一个logging软件,如syslog 来把所有的日志写到一个中央服务器。尽管这个方法要求更多的配置,但是他也提供了最健壮的方案。  

SVN的机制确实是很多人现在所考虑的,一来这样保证了代码的同步,二来也不需要担心开发版和上线版的区别,更重要的是,每次的update你肯定不会有错。

文件上传其实才是一个大头,当你的服务器过多的时候,你如何保证每一台服务器的上传内容同步?如果你同步了,那么这么多的冗余文件是否是一个浪费?如果你不同步,而采用同一个NFS服务器来存储,那么就象文中说的如果NFS宕机了怎么办?给NFS也来一个负载均衡?

总之,当服务器越来越多的时候,你考虑的就不仅仅是代码的问题,而是架构的问题

Tags: php, server, 负载均衡, 配置

Cookie常识

在制作 网页的时候,不可避免的会用到Cookie,无论是登录也好,保存状态也好,或多或少,你都会在使用Cookie这个小甜饼。

然而甜饼并不是这么好吃的,吃的过多也会有问题的,如果你的网站COOKIE数量过多,或许你的浏览器就直接打不开这个网页(这点好象是和SERVER端有关,apache接受客户端的COOKIE数量和长度也有限制)

对于用户来说,如果没有做限制的话,那么COOKIE过多会导致后一个新的COOKIE会覆盖掉前面的COOKIE。。

那么,究竟应该有多少COOKIE呢?

以下内容来自DBA Notes网站:

Cookie 是个很有趣的话题。根据 RFC 2109 的描述,每个客户端最多保持 300 个 Cookie,针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多,比如 Firefox 是 50 个) ,每个 Cookie 最多 4K,注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了,对于 Cookie 最重要的就是,尽量控制 Cookie 的大小,不要塞入一些无用的信息。

所以,不要把你想知道的用户行为都采用COOKIE来保存,否则造成的后果恐怕是非常大。在一些大型网站,目前对于用户的行为已经开始逐步采用数据库来控制,这样可以记录用户的一些操作,对于用户的行为分析也能够达到的一定的效果,缺点是加大了数据库的压力。而且对于未登录网站的用户来说,他的行为将变得毫无意义

想象:将用户的一些普通行为采用Cookie保存,重要信息记录数据库。比如用户浏览过的网页记入cookie,而用户停留时间最长的网页则考虑记入数据库(当然,对于那种开着网页不关的人就无法对付了,但仍然可以通过客户端的document.scroll的高度来进行判断,再通过ajax提交 )意义不是特别大。对于一些象购物车之类的,确实可以考虑存入数据库,否则一旦网页误关闭了对于用户的体验可能并不是很好(给用户一个可选项:cookie或者数据库,但好象有点傻)。。。。。。

随便谈谈吧。。

Tags: php, web, cookie, rfc2109

Snoopy更新

snoopy是在系统不支持curl的情况下所采用的抓取网络信息最有用的工具之一,因为他可以模拟POST,GET等方法,而无须让你再向以前一样用fsockopen,写上一大堆代码。

这样的一个类库,在目前被PHP的使用者广泛应用着,本来以为他就这样的一直不再更新下去,不料最近还是有了一些改动,当然这些改动都是一些BUG fix,而且是安全方面的,建议下载后更新。

更新情况:

Posted By: mohrt
Date: 2008-10-22 22:54
Summary:
Snoopy 1.2.4 security fix

A security vulnerability was fixed in the latest 1.2.4 version of Snoopy. It was possible to send shell commands through https url fetches that are not properly sanitized by the PHP program using Snoopy.

下载页面为:

http://sourceforge.net/project/showfiles.php?group_id=2091

Tags: snoopy, fsocketopn

haohappy的努力

国内的PHP程序员对于haohappy应该算是比较熟悉的一位吧,很早的PHP手册翻译,他就参与了其中,《Programming PHP》第二版,就是他进行翻译的,而且他在phpchina上开了专版,说是提交了多少个勘误的,可以送一本修订版或者另一本PHP的杂志,然而我在提交了十多个BUG后,因为工作关系被我放弃了。

不过那段时间,我确实是对照了原版和他的翻译版差不多看了一遍。虽然有一些翻译在语义上和我有些区别,但这毕竟是没有办法的事情。每个人对于一件事物的理解都会有偏差,无所谓谁对谁错(当然也可能确实是我理解错了)。

对于PHP的贡献,他不止这一点,他在看到目前PHP手册没人翻译后,终于忍不住了,开始下决心对手册再次进行翻译:http://blog.csdn.net/Haohappy2004/archive/2008/12/13/3511730.aspx,http://blog.csdn.net/Haohappy2004/archive/2008/12/14/3514421.aspx;

想期待他翻译的朋友要等一段时间了,在这段时间内,大家可以去CU找honestQiao的新版本进行下载:http://bbs.chinaunix.net/thread-999247-1-1.html,或者找本站的置顶贴进行下载。

等新版的翻译好了,我也会同步到本地。一来可以自用,二来可以为使用网通的朋友们下载进行提速。哈哈

Tags: php, haohappy, 手册, manual, 翻译

海龙CMS1.1 beta发布

海龙CMS是基于ThinkPHP框架的一个PHP应用,目前看来是相对简陋了一些,但这也紧紧局限于表面,毕竟没有专业的美工,能做到这样也算是不错了,程序支持模版的切换,所以,如果你的美工够好,你一定能够做出比海龙官方更漂亮的网站。

此次更新了以下内容:

1.1 Beta
取消了产品管理
取消了产品搜索
采用Rbac进行权限控制
采用SinaEditor编辑器,支持图片和附件上传
文章分类支持到三级分类
修改了模板变量的处理方式
整合了yhustc工具箱(可到TP论坛搜索yhustc工具箱以查看详细资料
可生成HTML(只需要后台配置一下就好了)


1.0 Final
完成了基本的文章管理、页面管理、产品管理
产品支持多字段模糊查询

演示地址:http://www.hailongol.com/hlcms/
官方下载:http://www.hailongol.com/HailongCMS.rar

本站分流:hailongcms.rar

Tags: 海龙, cms, thinkphp, beta