Flier's Sky

Gearman是最早由LiveJournal内部开发并使用的一个通用并行任务调度框架，允许不同语言直接通过非常简单的方式进行互操作。前台提交工作任务(Task)和参数，由后台工作进程(Worker)完成实际工作。 例如前台提交用户需要进行渲染的图片，由Gearman调度到后台提供渲染服务的工作进程，在完成工作后返回结果给前台进行展示。提交工作和完成工作的代码只需要通过预先协商好的参数格式进行交互，具体任务的调度、负载均衡、可靠性等，由Gearman服务器来确保。而针对大规模应用，可以很容易进行多路节点的集群部署。 在正式对外发布后，Danga Interactive用C重写了整个服务器代码，支持PHP, Perl, Python等常见脚本客户端，支持用memcached, sqlite, postgresql, tokyocabinet等作为任务持久化队列，基本上来说是便宜量又足。 线程模型 在大规模使用的时候，需要针对应用类型进行参数设置，以使Gearman的性能达到最优，这首先应该了解Gearman的线程模型。 为确保具备对海量任务调度的支持能力，Gearman毫无悬念的选择libevent作为网络操作支撑库。因此Gearman的服务器Gearmand提供了三类线程角色： 端口监听和管理线程，接受新连接请求并将之交给IO线程，1个 IO线程，完成实际的任务处理，包括命令解析，队列操作等，n个 处理线程，完成内部数据结构的管理，无系统调用尽可能简单，1个 其中第1, 3种线程对全局处理性能没有直接影响，虽然处理线程有可能成为瓶颈，但他的工作足够简单消耗可忽略不计，因此我们的性能调优主要目标是在IO线程的数量。 对每个IO线程来说，它都会有一个libevent的实例；所有Gearman的操作会以异步任务方式提交到处理线程，并由IO线程获取完成实际操作，因此IO线程的数量是与可并行处理任务数成正比。Gearmand 提供 -t 参数调整总IO线程数，需要使用 libevent 1.4 以上版本提供多线程支持。 进程句柄数 另外一个影响大规模部署的是进程句柄数，Gearman会为每一个注册的Worker分配一个fd(文件描述符)，而这个fd的总数是受用户限制的，可以使用 ulimit -n 命令查看当前限制 flier@debian:~$ ulimit -n 1024 flier@debian:~$ ulimit -HSn 4096 // 设置进程句柄数的最大软硬限制 4096 也就是说gearman缺省配置下，最多允许同时有小于1024个worker注册上来，fd用完之后的Worker和Client会出现连接超时或无响应等异常情况。因此，发生类似情况时，我们应首先检查 /proc/[PID]/fd/ 目录下的数量，是否已经超过 ulimit -n 的限制，并根据需要进行调整。而全系统的打开文件设置，可以参考 /proc/sys/fs/file-max 文件，并通过 sysctl -w fs.file-max=[NUM] 进行修改。 flier@debian:~$ cat /proc/sys/fs/file-max [...]

上周给公司同事做了一个函数式编程 (Functional Programming) 的介绍，原以为可以随便到网上找一个ppt讲讲，结果发现居然没有合适的可以直接用，只好根据 wiki 结合 python 示例自己整理了一个培训PPT。大概涵盖了FP的发展历史、基本概念和一些简单例子，回头有空再把它细化一下，看看是否有必要继续深入讲。 说起来函数式编程 (Functional programming) 这个话题基本是个无底洞，属于在常青藤高校也能开几年课挂掉无数人的领域。如何在短短一个多小时的时间内，让听众有一些直观印象，进而有兴趣继续深入学习下去，这是让我最为头疼的事情。因此我基本放弃了对那些较为复杂概念的介绍，甚至连 Closure 都只敢简单提及，跟别提什么 Monad 这种我自己都挠头的概念。 开讲前在几十个听众中做了个简单调查，果然是听说过和使用过 FP 的人基本都是个位数。这基本上可以说是天朝 CS/EE 教育失败的体现，要知道欧美大学第一年就会讲 Structure and Interpretation of Computer Programs 这种被 Joel 视为是否适合就读 CS 专业过滤器的 BT 课程 (在线课程)。 因此在一开始的时间里，基本上都是集中在对 FP 的鼓吹上，基本集中在 (1) 应对复杂性，(2) 降低维护成本和 (3) 增强自信心三个角度。前面两个基本上是洗脑用套话，个人最赞同也最想灌输的是第三点。 如果实际参与开发过代码量上百万行，代码维护历史在5-7年以上，先后参与人数几十上百的产品，最直观的感受是应该就是对其自身复杂性的本能恐惧。因为对绝大多数技术人员来说，我们更倾向于参与具有确定性的工作，也就是说我们潜意识里认为，我们做的事情应该是有可预测结果的。但一旦代码复杂到了一定程度，解耦没有到位过过于到位，我们就会发现所有的修改，都有可能引发不确定的影响。为了缓解这种影响，我们搞出了各种各样的最佳实践，TDD、CI、peer review，blabla；但归根结底我们只是试图用这些尝试来确保，我们有胆量继续修改那些我们自己也逐渐无法控制的代码，就好象在黑夜中无助的抓住一个火把，却又大声喊叫说自己不怕黑暗。 FP 在这方面可以说具有天然的优势，在去除 side effect 和复杂控制逻辑后，我们通过 Pure functions 和 Recursion 表达的是我们真正的计算目的，而非达成目标的方法。这也是声明式语言 (Declarative [...]