[文章作者:张宴 本文版本:v1.0 最后修改:2009.11.01 转载请注明原文链接:http://blog.zyan.cc/dips/]

  2009年10月28日,在金山逍遥技术支持部内部分享会上,介绍了Gearman分布式计算框架与金山逍遥DIPS分布式图片处理平台,以下是PPT图片:

  点击在新窗口中浏览此图片
  点击在新窗口中浏览此图片

  点击在新窗口中浏览此图片
  点击在新窗口中浏览此图片
  点击在新窗口中浏览此图片
  点击在新窗口中浏览此图片
  点击在新窗口中浏览此图片
  点击在新窗口中浏览此图片
  点击在新窗口中浏览此图片

  PDF版本下载:  



  附1:Gearman分布式计算框架网址
  http://gearman.org/



  附2:PHP客户端Gearman扩展安装:
wget http://www.monkey.org/~provos/libevent-1.4.12-stable.tar.gz
tar zxvf libevent-1.4.12-stable.tar.gz
cd libevent-1.4.12-stable/
./configure --prefix=/usr
make && make install
/sbin/ldconfig
cd ../

wget http://launchpad.net/gearmand/trunk/0.9/+download/gearmand-0.9.tar.gz
tar zxvf gearmand-0.9.tar.gz
cd gearmand-0.9/
./configure
make
make install
/sbin/ldconfig
cd ../

wget http://pecl.php.net/get/gearman-0.5.0.tgz
tar zxvf gearman-0.5.0.tgz
cd gearman-0.5.0
/usr/local/webserver/php/bin/phpize
./configure --with-php-config=/usr/local/webserver/php/bin/php-config --with-gearman
make
make install
cd ../


  php.ini文件中增加:
extension = "gearman.so"




  附2:Gearman调度器安装(JOB Server):
wget http://launchpad.net/gearmand/trunk/0.9/+download/gearmand-0.9.tar.gz
tar zxvf gearmand-0.9.tar.gz
cd gearmand-0.9/
./configure
make
make install
/sbin/ldconfig
cd ../


  以守护进程启动:
gearmand -L 192.168.0.1 -p 4730  -u root -d






技术大类 » 其他Unix技术 | 评论(52) | 引用(0) | 阅读(114624)
eric_zhyd Email
2009-11-1 11:46
不错,学习了。认真研究一下才行。

不过为什么在系统负载对比处的对比指标不一样呢?
张宴 回复于 2009-11-1 14:06
对比的指标是一样的。两张图片都是SNMP+Cacti采集显示的24小时内的数据(第一张2009-10-26 14:30~2009-10-27 14:30,第二张2009-10-27 14:30~2009-10-28 14:30),Cacti图片显示的时候,图片纵轴的默认最大值分别为这24小时内的系统负载最大值,一个为150、一个为1,Cacti按照这两个不同的比例显示的图片。
unixhater Homepage
2009-11-1 17:13
学习这种 调度 的思想
cache
2009-11-1 17:32
实时的图片处理采用这种方式挺好的,但密保卡个人认为大可以采用离线生成的方式,每个服务器,采用共享内存的方式,两个进程,一个进程生产,一个进程负责提供图片拉去服务, 出于容灾考虑,最终只需要2台服务器就足够了。
张宴 回复于 2009-11-2 11:35
金山通行证软件、网游都是互通的,通行证总数超过1亿。申请网游密保卡的用户比例相对较小,预先生成大量的密保卡图片不太合适。
有颜色的猫 Email Homepage
2009-11-2 08:01
好文章!还可以考虑把处理图片任务的fastcgi脚本部署到其他机器,这样前端的性能也可以达到极大的分担,拓扑结构也能更简单一些。
kk
2009-11-2 10:56
1 图片服务也可以利用ImageMagick和jmagick做成http接口的图片转换服务,nginx做比较灵活的负载分担
2 使用gearman需要考虑下系统的安全性问题

<kangglmail@163.com>
张宴 回复于 2009-11-3 08:20
老兄的建议不错,为ImageMagick写个HTTP Server接口,也是一个不错的方法。但是gearman的调度比Nginx的纯轮询方式要好,可以针对不同CPU数量的服务器,使用指定数量的CPU。比如8核(4核*2)的服务器,使用其中4核做图片处理,4核(双核*2)的服务器,使用其中2核做图片处理。
int3
2009-11-3 00:58
安全性?
你觉得目前使用gearman有会带来哪些安全隐患呢?
张宴 回复于 2009-11-3 08:16
gearman在内网运行,就和Memcached在内网运行一样,没有多大的安全性隐患。
dodge Email
2009-11-4 11:50
不错,可以借鉴下做一个视频的分布式处理。
虫zi
2009-11-5 14:39
弱弱的问一句,使用 gearman -d 启动守护进程后。怎么把这个进程关掉?使用 gearman -h 貌似没有找到。。。谢谢。
张宴 回复于 2009-11-5 15:45
kill掉即可。
虫zi
2009-11-5 14:42
可不可以理解为gearman,你使用这个,是为了让多个服务器去做同一件事。具体由哪个服务器来做,由job选择的worker决定。这样可以 使CPU比较闲的机器来做这些事情。不知道我理解的是否正确。。
遗失的森林
2009-11-5 22:13
个人觉得gearman在DIPS的架构中的作用不明显,DIPS相对于以前的架构做了如下变动:
1、将生成图片的操作转移到了专用的29台图片处理服务器上,故新架构webserver负载大大降低
2、gearman只是起到了类似LVS的功能,并未体现出其他作用。

替换gearman只需类似如下代码就可实现:
//图片处理服务器列表
$imageHandlerServers = array(
    array('ip' => '', 'port' => 9527),
    ... * n
);
//取随机数
$randomServerId = random(1, count($imageHandlerServers));
$imageHandlerServer = $imageHandlerServers[$randomServerId];
//生成图片
$image = genImage($imageHandlerServer, $data);
张宴 回复于 2009-11-6 07:36
gearman不光只是负载均衡作为:
1、gearman有完善的调度作用。普通的array数组+随机数无法保证负载的均衡,无法根据后端Worker的繁忙程度做调度分发。
2、gearman能够实现故障转移与高可用。如果后端的一台Worker进程有故障,gearman能够不把请求分发到故障服务器。而array数组+随机数,仍然会将请求发送到发生故障的Worker服务器上。
遗失的森林
2009-11-6 09:19
1、数组+随机数肯定是不能做负载均衡,但这个架构中worker的工作相对固定(只是生成图片),无过于复杂的业务逻辑处理(可导致负载增加的不确定因素),故绝大部分时间worker负载平稳,从结果上来看可做到负载均衡。
2、按照DIPS中的程序,我不清楚$image=$dips.do(***),这段代码返回的是图片对象还是图片地址,如果是图片对象,那么是否流量会堆积在job server上?
3、如果某台worker有问题,用数组+随机数方式可改进一下,如果执行失败,可再尝试另一台worker,可在一定程度上实现故障转移。

另外,对于job server,如果访问量巨大,job server是否会成为瓶颈?由于我没有研究过gearman底层负载均衡的方式,这个请博主解答一下~

对于新老架构负载对比图,个人觉得意义不大,新架构只是把高负载的任务由webserver拆到了worker上,并不是由于引进gearman而带来根本上的负载降低,有误导新手的嫌疑
icerain
2009-11-8 12:08
个人觉着整体性能还是一样的。
张宴 回复于 2009-11-8 16:55
实际运营中,一颗CPU同一秒处理一张图片,和一颗CPU同一秒处理10张图片的性能差别是非常大的,分布式处理表现为整体服务器的负载都很低。校内网的图片处理方法也类似。
melec Email
2009-11-11 05:28
这个分布式应用的实践,也可以说这个探索的意义非常大!就如同张宴之前的一些文章,给php找到很多来简单易用的、解决一些大负载、大存储量、大规模计算的方案。闲置的计算资源是已有的,不利用就是浪费的,这个方法再进一步探索,可以利用的空间很大,很容易就变成了php可用的分布式计算服务平台。
melec Email
2009-11-11 05:31
我看到gearman有mysql接口? 有实践过的没?这个还是挺有吸引力的,可以作为容错的解决方案不?
zybingliu Email
2009-11-16 15:48
在处理平台集群的图片上,引用了gearman.org中的一张图片(http://gearman.org/images/gearman_cluster.png),

4台client,分成2组,连接到2台JobServer上,4台Worker分别都连接到2台JobServer上。

有一个问题:
对于worker来说,没有问题,同时为2台JobServer提供服务。
当1台JobServer故障,4台client中,就有2台就服务连接到JobServer了,无法进行服务了。这样必然有相当部分的用户收到了影响。

有没有现成的方式,client也同时连接到2台JobServer上,当一台JobServer故障,可以自动发送给另外一台运行正常的JobServer,这样实现fail over?



这个问题如何处理的?
Ryugi
2009-12-7 10:18
我个人比较赞同 遗失的森林 的看法。这个问题有待商榷。
从整个架构上来看。gearman所起到的作用确实没有完全表现出来。
Seaprince Email Homepage
2009-12-12 00:13
引用
金山通行证软件、网游都是互通的,通行证总数超过1亿。申请网游密保卡的用户比例相对较小,预先生成大量的密保卡图片不太合适。

既然申请网游密保卡的用户比例相对较小,又和1亿用户数有什么关系呢?预先生成大量密保卡只和绝对用户数有关吧?
如果只是申请时生成,何必用上几十台服务器做这个事呢?
fisherman
2010-3-17 15:21
怎么看都没有看出gearman的作用。如果忽略网络传输的开销,整体来看这个系统,负载是一样的,因为总体的计算量是固定的。只不过是用户体验好些了。现在有N个任务(Client),M个Worker,每个任务执行时间为t。如果不是用gearman的话,需要的时间为N*t,平均等待时间为N*t/2。如果使用了gearman的话,并且N<=M,需要的时间为t,平均等待时间为t;如果N>M的话,需要的时间为(N/M)*t or (N/M+1)*t。由于没有什么分布式架构的经验,还请各位大侠指教。
jiming
2010-4-1 11:42
遗失的森林 问的那个问题我也很感兴趣
2、gearman只是起到了类似LVS的功能,并未体现出其他作用
我很想了解一下 gearman 比 lvs 有哪些优势?
654
2010-4-28 12:01
question
分页: 1/3 第一页 1 2 3 下页 最后页
发表评论
表情
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
打开HTML
打开UBB
打开表情
隐藏
记住我
昵称   密码   游客无需密码
网址   电邮   [注册]