月度归档:2015年01月

yaaf_server的几种结构

总结下不同业务场景下yaaf(yaaf框架是个基于zmq的线程池框架写后台server)server不同的内部结构,大体有以下几种形式:

yaaf框架server结构

 

1. 单一zmq接口的dispatcher+worker(server_1)
早期,部门几乎绝大部分是web业务,中心绝大部分也是cgi+业务server这种形式,当时后台几乎都是面向cgi的,所有逻辑落在worker中,此时业务server的结构是单个zmq_dispatcher + 一组worker的形式。

2.支持多种接口的dispatcher+workerserver_2)
随着业务的增长,与外部门的合作增多,后台server除了给cgi调用之外,还会给诸如客户端提供服务接口 - 原生的udp/tcp/http等,此时框架封装了更多的dispacher负责对接不同来源的调用方,worker仍然保持尽可能的只关注业务逻辑,所以业务server的结构是多个worker_dispatcher + 一组worker的形式。

3.woker_dispatcher+client_dispatcher+worker(server_3)
随着部门越来越大,所做的业务也越来越复杂,后台存在较多的调用更底层服务的情况。此时在server中用框架封装更多的client_dispatcher,用于向后端发请求。worker继续保持尽可能的只关注业务逻辑,这时业务server的结构是worker_dispatcher + client_dispatcher + 一组worker的形式。

4.多组dispatcher+多组worker(server_4)
随着参与业务的增多,越来越多的业务场景出现。当逻辑复杂到一定程度的时候,可能会将dispatcher-worker分组,来方便编写/维护不同的逻辑代码,不同分组内的worker负责模块内相对独立的逻辑,此时的业务server结构是多个dispatcher+ 多组worker。

5.去dispatcher(server_5)
当遇到请求量巨大或者cpu密集型的业务时,dispatcher本身可能成为瓶颈,虽然框架可以平行扩展,但为了榨干单机性能实现上会去掉dispatcher让worker直接对外提供服务,此时的server结构是一组worker。

zmq自连接问题

【背景】
最近的项目过程中偶然的被同一个问题骚扰:一个基础server挂了(基于zmq的服务),自动拉起的脚本不能成功重启server,查询后发现是监听的端口被绑定了,且是被一个client绑定了,每次都得kill掉那个client然后再重启。

【认知】
经过多方查阅发现是linux的自连接问题,linux允许发生自连接,而zeromq官网也有人提出了这个bug – LIBZMQ-549。那么为神马现网环境的server从来没出现过这个问题呢?因为只有在同一台机器上,client和server五元组才有可能完全相等。

【解决】
1. 保证随机分配的端口与server绑定的端口不重合(/proc/sys/net/ipv4/ip_local_port_range)
2. hack代码,发现ip/port相等立马断开