luabus是一个为LUA RPC服务集群提供网络支持的基础库,主要分为网络库和路由支持两块功能.
主要特性:
- 方便的在服务进程间进行RPC调用.
- 方便搭建高可用集群,支持: 定点发送,哈希转发,随机转发,组内广播,主从备份.
目前支持Windows, Linux, MacOS三平台,编译器必须支持C++14.
- Windows: Visual studio 2015以上版本,需要自行编译lua的dll库,或者用win64目录下的库文件.
- MacOS: 需要自行编译安装lua.
- Linux: 需要自行编译安装lua.
目前尚未专门为性能做测试及优化,只是为了简单好用.
首先需要一个socket_mgr对象:
lbus = require("lbus");
socket_mgr = lbus.create_socket_mgr(最大句柄数);
--用户需要在主循环中调用wait函数,比如:
--其参数为最大阻塞时长(实际是传给epoll_wait之类函数),单位ms.
socket_mgr.wait(50);
监听端口:
--注意保持listener的生存期,一旦被gc,则端口就自动关了
listener = mgr.listen("127.0.0.1", 8080);
--设置accept回调
listener.on_accept = function(stream)
stream.on_call = function(msg, ...)
-- ...
end
stream.on_error = function(err)
-- ...
end
end
发起连接:
--注意保持stream对象生存期,被gc的话,连接会自动关闭
--连接都是异步进行的,一直要stream上面触发'on_connect'事件后,连接才可用
--connect(ip, port, timeout)
stream = mgr.connect("127.0.0.1", 8080, 2000);
--设置连接事件回调:
stream.on_connect = function(result)
--如果连接成功,result为"ok"
--否则,result表明具体的错误
end
向对端发送消息:
stream.call("on_login", acc, password);
响应消息:
stream.on_error = function (err)
--发生任何错误时触发
end
stream.on_call = function (msg, ...)
--收到对端消息时触发.
--通常这里是以...为参数调用msg对应的函数过程.
end
其他方法:
--设置多久没收到消息就超时,默认不超时
stream.set_timeout(2000);
--设置nodelay属性,默认设置为true
stream.set_nodelay(true);
--设置收发缓冲区,至少应该可以容纳一条消息,默认64K
stream.set_recv_buffer_size(1024 * 64);
stream.set_send_buffer_size(1024 * 64);
主动断开:
--调用close即可:
stream.close();
路由转发目前针对星型架构设计,它以转发器(router)为中心,构成一个高可用集群,其中的所有服务进程(包括router)都被设计成多活的.
这个跟路由转发其实没什么关系,token是属于socket stream的,类似于文件描述符的概念,与stream对象一一对应.
它是服务进程在集群中的唯一标识,一般可以在进程的命令行参数(或配置文件)中指定. 它是一个32位整数,其高16位表示服务类型(如,邮件服务,聊天服务等等),服务类型的取值范围为[0, 255],而低16位表示进程的实例编号. 比如我们把邮件服务定义为2,并同时运行了3个邮件服务实例,那么他们的服务ID就分别是: 2.1, 2.2, 2.3,类似于IP地址.
这里主要指服务不因单个进程失效而不可用;单个进程失效时,负载自动被切换到同一功能组的其他进程. 根据服务进程的业务特点,可以把它们按照主从,哈希,随机,广播等方式组织. 故障切换是用来提高服务的可用性,并非说切换是无损的,在切换期间,势必会有一些业务消息丢失.
这里的一致性,主要涉及哈希,随机,主从三个方式. 其中哈希和随机能够多机一致,是因为路由模块内部对service_id做了排序. 当然,是否存在某些极其特殊的场景,使得多个router之间的哈希数组不一致呢? 这显然是可以构造出来的,所以说,这里的'高可用'只是提高可用性,而不是绝对保障. 至于master/slave的仲裁,这里推荐的方式是采用租约的方式,并将租约写入数据库. 所有进程都不断尝试取得租约(或续约),比如每秒一次,租约一旦超时(比如10秒),那么其他进程就能够取得租约,从而切换为master. 发生主从切换后,这个主从信息会同步到具体的服务进程,以及所有的router.
服务进程同时连接所有的router,但只会随机的选择一个router来做消息转发的. 一般可以在router连接成功/连接丢失时,随机选择一个router. 切勿在每次发送消息的时候进行随机,这样可能会带来消息之间的时序问题.
路由转发是按功能组控制的,每组路由主要包含两个信息:
- 实例数组(即连接的token数组),它用于做哈希转发或随机转发.
- master,即主进程的连接token. 通过socket_mgr.register接口可以控制内部的路由表.
--id,服务进程的id,即service_id,32位整数
--token,连接的唯一标识(stream.token),传入0表示保留空位,传入nil表示从路由表删除
--is_master,是否master
socket_mgr.register(id, token, is_master);
'高可用'当然离不开业务逻辑设计上的支持. 比如邮件服务,实现邮件服务的开发者当然应该它是按哈希分布,还是按主从分布,如果是哈希分布,那用什么做KEY. 而调用邮件服务的人,当然也应该知道邮件服务是怎么分布的,如果是哈希分布,还得提供KEY. 但这些都是可以简单封装的,比如我们把邮件服务按照玩家账号(acc)来做哈希分布,那么可以这样封装:
--my_router: 当前首选router
--mailsvr_group,服务分组编号,预定义的常量
function call_mailsvr(key, msg, ...)
my_router.forward_hash(key, mailsvr_group, msg, ...);
end
--业务调用:
call_mailsvr(player.acc, "send_mail", player.acc, receiver, "hello", "balabala...");