我运行中的博客

2007年9月27日星期四

[转贴文章]使用memcached进行内存缓存: 一个藏袍

使用memcached进行内存缓存: 一个藏袍

使用memcached进行内存缓存

旧文重发
2005.8.9

通常的网页缓存方式有动态缓存和静态缓存等几种,在ASP.NET中已经可以实现对页面局部进行缓存,而使用memcached的缓存比 ASP.NET的局部缓存更加灵活,可以缓存任意的对象,不管是否在页面上输出。而memcached最大的优点是可以分布式的部署,这对于大规模应用来 说也是必不可少的要求。
LiveJournal.com使用了memcached在前端进行缓存,取得了良好的效果,而像wikipedia,sourceforge等也采用了或即将采用memcached作为缓存工具。memcached可以大规模网站应用发挥巨大的作用。

Memcached是什么?
Memcached是高性能的,分布式的内存对象缓存系统,用于在动态应用中减少数据库负载,提升访问速度。
Memcached由Danga Interactive开发,用于提升LiveJournal.com访问速度的。LJ每秒动态页面访问量几千次,用户700万。Memcached将数据库负载大幅度降低,更好的分配资源,更快速访问。

如何使用memcached-Server端?
在服务端运行:
# ./memcached -d -m 2048 -l 10.0.0.40 -p 11211
这将会启动一个占用2G内存的进程,并打开11211端口用于接收请求。由于32位系统只能处理4G内存的寻址,所以在大于4G内存使用PAE的32位服务器上可以运行2-3个进程,并在不同端口进行监听。

如何使用memcached-Client端?
在应用端包含一个用于描述Client的Class后,就可以直接使用,非常简单。
PHP Example:
$options["servers"] = array("192.168.1.41:11211", "192.168.1.42:11212");
$options["debug"] = false;
$memc = new MemCachedClient($options);
$myarr = array("one","two", 3);
$memc->set("key_one", $myarr);
$val = $memc->get("key_one");
print $val[0]."\n"; // prints 'one‘
print $val[1]."\n"; // prints 'two‘
print $val[2]."\n"; // prints 3

为什么不使用数据库做这些?

暂且不考虑使用什么样的数据库(MS-SQL, Oracle, Postgres, MysQL-InnoDB, etc..), 实现事务(ACID,Atomicity, Consistency, Isolation, and Durability )需要大量开销,特别当使用到硬盘的时候,这就意味着查询可能会阻塞。当使用不包含事务的数据库(例如Mysql-MyISAM),上面的开销不存在,但 读线程又可能会被写线程阻塞。
Memcached从不阻塞,速度非常快。

为什么不使用共享内存?
最初的缓存做法是在线程内对对象进行缓存,但这样进程间就无法共享缓存,命中率非常低,导致缓存效率极低。后来出现了共享内存的缓存,多个进程或者线程共享同一块缓存,但毕竟还是只能局限在一台机器上,多台机器做相同的缓存同样是一种资源的浪费,而且命中率也比较低。
Memcached Server和Clients共同工作,实现跨服务器分布式的全局的缓存。并且可以与Web Server共同工作,Web Server对CPU要求高,对内存要求低,Memcached Server对CPU要求低,对内存要求高,所以可以搭配使用。

Mysql 4.x的缓存怎么样?
Mysql查询缓存不是很理想,因为以下几点:
当指定的表发生更新后,查询缓存会被清空。在一个大负载的系统上这样的事情发生的非常频繁,导致查询缓存效率非常低,有的情况下甚至还不如不开,因为它对cache的管理还是会有开销。
在32位机器上,Mysql对内存的操作还是被限制在4G以内,但memcached可以分布开,内存规模理论上不受限制。
Mysql上的是查询缓存,而不是对象缓存,如果在查询后还需要大量其它操作,查询缓存就帮不上忙了。
如果要缓存的数据不大,并且查询的不是非常频繁,这样的情况下可以用Mysql 查询缓存,不然的话memcached更好。

数据库同步怎么样?
这里的数据库同步是指的类似Mysql Master-Slave模式的靠日志同步实现数据库同步的机制。
你可以分布读操作,但无法分布写操作,但写操作的同步需要消耗大量的资源,而且这个开销是随着slave服务器的增长而不断增长的。
下一步是要对数据库进行水平切分,从而让不同的数据分布到不同的数据库服务器组上,从而实现分布的读写,这需要在应用中实现根据不同的数据连接不同的数据库。
当这一模式工作后(我们也推荐这样做),更多的数据库导致更多的让人头疼的硬件错误。
Memcached可以有效的降低对数据库的访问,让数据库用主要的精力来做不频繁的写操作,而这是数据库自己控制的,很少会自己阻塞 自己。

Memcached快吗?

非常快,它使用libevent,可以应付任意数量打开的连接(使用epoll,而非poll),使用非阻塞网络IO,分布式散列对象到不同的服务器,查询复杂度是O(1)。

参考资料:
Distributed Caching with Memcached | Linux Journal
http://www.danga.com/
http://www.linuxjournal.com/article/7451


Blogged with Flock

转贴文章 从LiveJournal后台发展看大规模网站性能优化方法: 一个藏袍

从LiveJournal后台发展看大规模网站性能优化方法: 一个藏袍

一、LiveJournal发展历程



LiveJournal
是99年始于校园中的项目,几个人出于爱好做了这样一个应用,以实现以下功能:
  • 博客,论坛
  • 社会性网络,找到朋友
  • 聚合,把朋友的文章聚合在一起

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

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



  • 2004年4月份:280万注册用户。
  • 2005年4月份:680万注册用户。
  • 2005年8月份:790万注册用户。
  • 达到了每秒钟上千次的页面请求及处理。
  • 使用了大量MySQL服务器。
  • 使用了大量通用组件。


二、LiveJournal架构现状概况



livejournal_backend.png



三、从LiveJournal发展中学习



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



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




1、一台服务器



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



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

毫无疑问,当时LJ存在巨大的单点问题,所有的东西都在那台服务器的铁皮盒子里装着。



LJ-backend-7.png



2、两台服务器



用付费服务赚来的钱LJ买了两台服务器:一台叫做Kenny的Dell 6U机器用于提供Web服务,一台叫做Cartman的Dell 6U服务器用于提供数据库服务。



LJ-backend-8.png



LJ有了更大的磁盘,更多的计算资源。但同时网络结构还是非常简单,每台机器两块网卡,Cartman通过内网为Kenny提供MySQL数据库服务。



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



  • 原来的一个单点变成了两个单点。
  • 没有冷备份或热备份。
  • 网站速度慢的问题又开始出现了,没办法,增长太快了。
  • Web服务器上CPU达到上限,需要更多的Web服务器。


3、四台服务器



又买了两台,Kyle和Stan,这次都是1U的,都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。



LJ-backend-9.png



LJ把Kenny用于外部的网关,使用mod_backhand进行负载均横。



然后问题又出现了:



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


4、五台服务器



又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式),写操作全部针对主数据库(通过Binlog,主服务器上的写操作可以迅速同步到从服务器上),读操作在两个数据库上同时进行(也算是负载均横的一种吧)。



LJ-backend-10.png



实现同步时要注意几个事项:



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


5、更多服务器



有钱了,当然要多买些服务器。部署后快了没多久,又开始慢了。这次有更多的Web服务器,更多的数据库服务器,存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。



LJ-backend-11.png



6、现在我们在哪里:



LJ-backend-1.png



现在服务器基本上够了,但性能还是有问题,原因出在架构上。



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



LJ-backend-2.png



由一台分布到两台



LJ-backend-3.png



最终效果



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



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



为了实现用户分组,我们需要为每一个用户分配一个组标记,用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个
slave组成,并且slave的数量在2-3台,以实现系统资源的最合理分配,既保证数据读操作分布,又避免数据过度冗余以及同步操作对系统资源的过度
消耗。



LJ-backend-4.png



由一台(一组)中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上,所有针对用户的操作需要先查询这台机器得到用户的组号,然后再到相应的数据库组中获取数据。



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



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



  • 在数据库组内不要使用自增ID,以便于以后在数据库组之间迁移用户,以实现更合理的I/O,磁盘空间及负载分布。
  • 将userid,postid存储在全局服务器上,可以使用自增,数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。
  • 在数据库组之间迁移用户时要万分小心,当迁移时用户不能有写操作。


7、现在我们在哪里



LJ-backend-5.png



问题:



  • 一个全局主服务器,挂掉的话所有用户注册及写操作就挂掉。
  • 每个数据库组一个主服务器,挂掉的话这组用户的写操作就挂掉。
  • 数据库组从服务器挂掉的话会导致其它服务器负载过大。


对于Master-Slave模式的单点问题,LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的,并不是由MySQL直接提供的,实际上也就是两台机器同时是Master,也同时是Slave,互相同步。



Master-Master实现时需要注意:



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


解决方案:

  • 奇偶数分配ID,一台机器上写奇数,一台机器上写偶数
  • 通过全局服务器进行分配(LJ采用的做法)。


Master-Master模式还有一种用法,这种方法与前一种相比,仍然保持两台机器的同步,但只有一台机器提供服务(读和写),在每天晚上的时候进行轮换,或者出现问题的时候进行切换。



8、现在我们在哪里



LJ-backend-6.png



现在插播一条广告,MyISAM VS InnoDB。



使用InnoDB:



  • 支持事务
  • 需要做更多的配置,不过值得,可以更安全的存储数据,以及得到更快的速度。


使用MyISAM:



  • 记录日志(LJ用它来记网络访问日志)
  • 存储只读静态数据,足够快。
  • 并发性很差,无法同时读写数据(添加数据可以)
  • MySQL非正常关闭或死机时会导致索引错误,需要使用myisamchk修复,而且当访问量大时出现非常频繁。


9、缓存



去年我写过一篇文章介绍memcached,它就是由LJ的团队开发的一款缓存工具,以key-value的方式将数据存储到分布的内存中。LJ缓存的数据:



  • 12台独立服务器(不是捐赠的)
  • 28个实例
  • 30GB总容量
  • 90-93%的命中率(用过squid的人可能知道,squid内存加磁盘的命中率大概在70-80%)


如何建立缓存策略?



想缓存所有的东西?那是不可能的,我们只需要缓存已经或者可能导致系统瓶颈的地方,最大程度的提交系统运行效率。通过对MySQL的日志的分析我们可以找到缓存的对象。



缓存的缺点?



  • 没有完美的事物,缓存也有缺点:
  • 增大开发量,需要针对缓存处理编写特殊的代码。
  • 管理难度增加,需要更多人参与系统维护。
  • 当然大内存也需要钱。


10、Web访问负载均衡



在数据包级别使用BIG-IP,但BIG-IP并不知道我们内部的处理机制,无法判断由哪台服务器对这些请求进行处理。反向代理并不能很好的起到作用,不是已经够快了,就是达不到我们想要的效果。



所以,LJ又开发了Perlbal。特点:



  • 快,小,可管理的http web 服务器/代理
  • 可以在内部进行转发
  • 使用Perl开发
  • 单线程,异步,基于事件,使用epoll , kqueue
  • 支持Console管理与http远程管理,支持动态配置加载
  • 多种模式:web服务器,反向代理,插件
  • 支持插件:GIF/PNG互换?


11、MogileFS



LJ使用开源的MogileFS作为分布式文件存储系统。MogileFS使用非常简单,它的主要设计思想是:



  • 文件属于类(类是最小的复制单位)
  • 跟踪文件存储位置
  • 在不同主机上存储
  • 使用MySQL集群统一存储分布信息
  • 大容易廉价磁盘


到目前为止就这么多了,更多文档可以在http://www.danga.com/words/找到。Danga.comLiveJournal.com
同学们拿这个文档参加了两次MySQL Con,两次OS
Con,以及众多的其它会议,无私的把他们的经验分享出来,值得我们学习。在web2.0时代快速开发得到大家越来越多的重视,但良好的设计仍是每一个应
用的基础,希望web2.0们在成长为Top500网站的路上,不要因为架构阻碍了网站的发展。



参考资料:http://www.danga.com/words/2005_oscon/oscon-2005.pdf


Blogged with Flock

2007年4月2日星期一

[转贴]IT业加班现象深度分析(下)

原文网站:http://blog.sina.com.cn/duki

被动加班者应该是一个更庞大的群体,他们不仅因加班劳其筋骨,而且更背负着沉重的怨恨和无奈(提倡、强迫员工加班的老板们,你们是不是经常觉得后脖颈子发凉啊?那就是员工的怨气啊!)

既然是被动加班,自然是被老板们(包括经理们及其他高管们)强迫的啦!那么老板们为什么喜欢强迫员工加班呢,原因当然也是多种多样了。

剩余价值派

这些老板初一政治课第一学期估计挺认真听讲,到了下学期就不认真学了,所以光记得延长劳动时间,能够获取更多剩余价值。全然没看到下一章写着,延长劳动时间的结果,就是工人消极怠工,破坏生产设备什么的,最终吃亏的还是老板。这类老板算帐很在行,同样2000元月薪,买8小时/日的劳动时间,比较亏,买16小时/日才赚!但是他忘了,劳动时间不等于产品,更不等于利润。开公司的目的是赚钱,不是占员工便宜。



牧羊女派


这些老板通常是外行,根本不知道设计一个界面需要多少时间,完成一个论坛功能需要多少时间,做出游戏的聊天系统需要多少时间……其实不知道没关系,公司里肯定有内行啊,问就好了,但是他们或者拉不下脸来问,或者根本不信任任何人,他们害怕手下怠工,又不知道怎么评估他们是否怠工,于是,他们只能让大家加班,多花时间拼命做,反正做就是了,只有员工一天到晚在他眼皮子底下忙忙碌碌,他们才能心安。至于员工在忙什么,他不懂,也不关心,就算想关心,也不知道从何入手。

他们就像牧羊女,只要羊在眼前,他们就很放心,羊到底有没有吃草,有没有长膘,他们的脑容量太小,没有那个判断力,至于里面有没有披着羊皮的狼,他们就更分辨不出了。

光荣传统派

这类老板通常很成功,但是不知道为什么很成功,一没技术,二没管理,只因为祖坟冒了青烟,天上掉下狗头金,他们成功了。既然成功了,就要总结经验,可他们思来想去,也没有从自己身上发现什么优点,只好认定,自己的成功都是努力拼命的结果,天道酬勤嘛!要不是当年拼命加班,哪有今天的成功?未来要守住成功,并获得更大成功,自然更要加班,不仅自己加班,全公司都要加班,不能让俺一个人战斗啊!这就是俺们的公司文化,光荣传统不能丢嘛!



夜猫子派


这类老板是属夜猫子的,一到晚上就精神,通常每天午饭后施施然来上班,下午处理上午积压的公事,到了下班的点儿,就跟打了鸡血似的,兴奋起来,开会、布置工作、检查成果……把员工指使得团团转,自然也就回不了家,到了半夜,再开个总结会,必胜客、星巴克伺候着!自以为非常体恤员工了,可后半夜他开着宝马回家睡觉到中午去了,员工打着摩的回家没睡一会,还得9点上班打卡,怎不让员工恨得牙根痒痒?

苦劳派

这类老板能力是没有的,事情是一搞就砸的,做开发是经常拖期的,做市场是经常没效果的,但是他们有一样本事,就是欺上瞒下,报喜不报忧,敷衍上头的本事还是一流的。但是纸包不住火,丑媳妇总要见公婆,上头迟早会知道事情根本没办好,怎么办?加班啊!咱是没办好事情,但是咱没有功劳还有苦劳呢!您没看我一周7天,一天24小时都待在公司吗?事情没办好,不是我能力问题,更不是我态度问题,而是天时、地利都没有,我已经尽了最大努力,这事情根本没法办啊,就是神仙来了也办不好啊,“你说我容易吗?上辈子欠你的,我都快累死了,还要硬挺着,还不依不饶啊,还嫌不够吗,真够可以的,就这样算了吧……”他是过关了,员工何处诉苦它就不管了。

中华崛起派

这类老板入错了行,如果混入党、政、军的圈子,肯定会取得更大成就。他们提倡加班、鼓励加班,决不是为了私欲、私利,而是为了中华IT业的崛起。什么起步晚、底子薄、基础差、技术落后啦,什么赶超世界先进水平啦,什么落后就要挨打啦,不把一天当两天用怎么可能超日赶美捏?虽然这个调调有点过时,但是说出来还是慷慨激昂,掷地有声的,员工们明知道这是大跃进,可以不信,但是不好辩驳,万一有个把脑子不太清楚的,相信了这个,老板们的政治宣传公司就算有效果了,《动物庄园》中不就是有一匹这样脑子不太清楚的老马吗?

Technorati Tags: ,







Powered by ScribeFire.

[转贴]IT业加班现象深度分析(上)

原文网站:http://blog.sina.com.cn/duki

IT业加班多,地球人都知道,但为什么加班多,未必地球人都知道。包括你!对!就是你!现在正在加班并且偷懒看这篇文章的你。

加班分为两种,一种是主动的,一种是被动的。其成因、发展、现状截然不同,必须分别论述。

在主动加班者当中,分为三个流派。

少壮派

既然是少壮派,当然岁数不大,职位不高,大学毕业没两年。多数独自在大城市打拼,属于典型的三无青年:无钱、无房、无女友(男友)。下班回家,租屋环境脏乱差,漫漫长夜不知道怎么打发。相比之下,公司的环境要好很多,上有冷气,下有地毯,中间有键盘,窗明几净,24小时热水供应。下班之后滞留公司不走也是正常,上上网,听听音乐,打打游戏,下载点东西,开个小店……反正用的都是公司的资源,业余生活也算丰富多彩。

少壮派最大的特征就是具有强烈的“公司-电脑依赖症”。如果公司强制不允许加班,一下班就锁门,他们会非常失落,而他们的业余生活,则转为上网吧或睡觉。总之一句话,他们需要电脑,需要网络,但是他们没有,而加班,可以免费提供给他们这些,所以他们加班着并快乐着。

大叔派

所谓大叔派,也没多老,一般是30左右或以上,大小是个主管,有家有口的IT精英。他们加班,也是比较之下的自主选择。这些大叔,多半家庭不那么幸福,回到家里,等待他的是漏了的马桶,待洗的衣服,老婆的唠叨,孩子的哭……在家上个网?玩个游戏?在老婆看来,那是对家庭天大的犯罪。同家务活比起来,加班当然是比较轻松,和让老婆满意比起来,让老板满意会比较轻松。而且,老婆比老板精明,保险丝换了就是换了,没换就是没换,老婆清楚的很,而老板常常只看人在不在公司,人在就是好同志,不管你是不是在干活。



就像《中国式离婚》中的那个丈夫,号称加班,其实是在单位玩《侍魂》,顺便跟单位的小红颜知己贫两句,意淫一下,也算“眼睛吃冰淇淋,灵魂做沙发椅”,给自己找个乐儿。

平心而论,加班的大叔们还算好丈夫,至少没有拿上工资卡,直奔风月场所去者,或者干脆来个狡兔三窟,金屋藏娇,养个小情人。

无差别派

以上两个派别,都是通过比较“加班”和“回家”两种行为的结果,判断出加班比较有利,千好万好,不如公司好,正所谓趋利避害,大家自然纷纷选择加班,而无差别派,更看重的则是加班带来的好处。

一个很明显的好处就是加班费,虽然很多公司加班纯属自愿,并无任何报酬,但是还有少部分公司,保留着加班能拿加班费或补贴的光荣传统。在多赚几个钱的利益趋势下,仗着自己年轻,身体好,反正回家也没什么有意思的事,自然能加班就加班,能多加班就多加班,赚得一文是一文了。这倒是跟血汗工厂的工人们的加班热情有异曲同工之妙。

有些公司,虽然没有加班费,公司也没有明文强迫加班,但是上头是按照加班多少评定绩效的,加班越多,工资涨得越多,职位升得越快。于是乎,广大胸怀大志的有为青年就纷纷走上了加班这条不归路。加班也是可以成瘾的,大家加啊加啊加习惯了,无形中为公司创造了更多价值,薪水也涨了些,但其实按工作时间一平均不涨反降,而且高阶职位却没有那么多,升上去的毕竟是少数。最终,身体垮了,人傻了,女友跑了……这些结果反而比当上中高层更容易获得。



其他自愿加班还有:老板爱加班,为了跟老板有更多接触,为了给老板一个好印象,而加班;利用办公用品,创造美好生活,以公司为家,将刷牙、洗脚等行为都在公司解决,节省生活成本而加班(此行为网上有专文详细论述);利用公司资源,经营自己的生意而加班……等等。



Powered by ScribeFire.