张宴的博客

不错，学习了。认真研究一下才行。

不过为什么在系统负载对比处的对比指标不一样呢？

学习这种 调度 的思想

实时的图片处理采用这种方式挺好的，但密保卡个人认为大可以采用离线生成的方式，每个服务器，采用共享内存的方式，两个进程，一个进程生产，一个进程负责提供图片拉去服务， 出于容灾考虑，最终只需要2台服务器就足够了。

好文章！还可以考虑把处理图片任务的fastcgi脚本部署到其他机器，这样前端的性能也可以达到极大的分担，拓扑结构也能更简单一些。

1 图片服务也可以利用ImageMagick和jmagick做成http接口的图片转换服务，nginx做比较灵活的负载分担
2 使用gearman需要考虑下系统的安全性问题

<kangglmail@163.com>

安全性？
你觉得目前使用gearman有会带来哪些安全隐患呢？

不错，可以借鉴下做一个视频的分布式处理。

弱弱的问一句，使用 gearman -d 启动守护进程后。怎么把这个进程关掉？使用 gearman -h 貌似没有找到。。。谢谢。

可不可以理解为gearman，你使用这个，是为了让多个服务器去做同一件事。具体由哪个服务器来做，由job选择的worker决定。这样可以 使CPU比较闲的机器来做这些事情。不知道我理解的是否正确。。

个人觉得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);

1、数组+随机数肯定是不能做负载均衡，但这个架构中worker的工作相对固定（只是生成图片），无过于复杂的业务逻辑处理（可导致负载增加的不确定因素），故绝大部分时间worker负载平稳，从结果上来看可做到负载均衡。
2、按照DIPS中的程序，我不清楚$image=$dips.do(***)，这段代码返回的是图片对象还是图片地址，如果是图片对象，那么是否流量会堆积在job server上？
3、如果某台worker有问题，用数组+随机数方式可改进一下，如果执行失败，可再尝试另一台worker，可在一定程度上实现故障转移。

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

对于新老架构负载对比图，个人觉得意义不大，新架构只是把高负载的任务由webserver拆到了worker上，并不是由于引进gearman而带来根本上的负载降低，有误导新手的嫌疑

个人觉着整体性能还是一样的。

这个分布式应用的实践，也可以说这个探索的意义非常大！就如同张宴之前的一些文章，给php找到很多来简单易用的、解决一些大负载、大存储量、大规模计算的方案。闲置的计算资源是已有的，不利用就是浪费的，这个方法再进一步探索，可以利用的空间很大，很容易就变成了php可用的分布式计算服务平台。

我看到gearman有mysql接口？ 有实践过的没？这个还是挺有吸引力的，可以作为容错的解决方案不？

在处理平台集群的图片上，引用了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？



这个问题如何处理的？

我个人比较赞同 遗失的森林 的看法。这个问题有待商榷。
从整个架构上来看。gearman所起到的作用确实没有完全表现出来。

既然申请网游密保卡的用户比例相对较小，又和1亿用户数有什么关系呢？预先生成大量密保卡只和绝对用户数有关吧？
如果只是申请时生成，何必用上几十台服务器做这个事呢？

怎么看都没有看出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。由于没有什么分布式架构的经验，还请各位大侠指教。

遗失的森林 问的那个问题我也很感兴趣
2、gearman只是起到了类似LVS的功能，并未体现出其他作用
我很想了解一下 gearman 比 lvs 有哪些优势？