1、看gatewayworker 源码,似乎每个客户端消息都存在一个内存变量大概10MB, 如果发送速度过快,新来的消息不就丢失了? 2、这种一般用什么样的技术来做,更加合适?
聊天业务,单个客户短时间内不会收到10M的文字消息,10M的聊天内容相当于350万汉字,远超过四大名著总文字量,阅读完可能需要个把月(图片 文件下载走的是http,不走gatewayWorker)。 一个客户峰值每秒收到的信息量也就几K,一天累加起来一般不会超过1M。
不知道你说的大型是指多大型,如果是微信的体量肯定不是靠gatewayWorker这一个框架就能支持的,如果是的话就没有架构师什么事了。gatewayWorker支持数万在线有不少开发者验证过的,数十万在线应该也问题不大。
推荐只把gatewayWorker当作推送通道,除了上下线事件处理,GatewayWorker里不做业务相关的东西。业务全部走http处理,比如消息发送先走http服务,http服务里判断权限等,然后调用GatewayClient调用gatewayWorer接口发送消息。
如果你的业务对消息送达比较敏感,应该在http服务里将每条消息存到数据库,加上是否送达标记。有了送达标记,即使客户不在线,消息也不会丢失。 客户上线时ajax获取最近未读消息,这样即使没有gatewayWorker服务,离线的消息都能读到。
GatewayWorker是即时的,有很多不可抗拒因素导致消息发不到,例如客户端根本没在线,最小化js暂停,网络断开,网络故障,甚至服务器死机,你不能指望gatewayWorker给你100%送达,需要有一个像上面说的消息保存+标记+拉取机制。
感谢大佬解答
聊天业务,单个客户短时间内不会收到10M的文字消息,10M的聊天内容相当于350万汉字,远超过四大名著总文字量,阅读完可能需要个把月(图片 文件下载走的是http,不走gatewayWorker)。
一个客户峰值每秒收到的信息量也就几K,一天累加起来一般不会超过1M。
不知道你说的大型是指多大型,如果是微信的体量肯定不是靠gatewayWorker这一个框架就能支持的,如果是的话就没有架构师什么事了。gatewayWorker支持数万在线有不少开发者验证过的,数十万在线应该也问题不大。
推荐只把gatewayWorker当作推送通道,除了上下线事件处理,GatewayWorker里不做业务相关的东西。业务全部走http处理,比如消息发送先走http服务,http服务里判断权限等,然后调用GatewayClient调用gatewayWorer接口发送消息。
如果你的业务对消息送达比较敏感,应该在http服务里将每条消息存到数据库,加上是否送达标记。有了送达标记,即使客户不在线,消息也不会丢失。
客户上线时ajax获取最近未读消息,这样即使没有gatewayWorker服务,离线的消息都能读到。
GatewayWorker是即时的,有很多不可抗拒因素导致消息发不到,例如客户端根本没在线,最小化js暂停,网络断开,网络故障,甚至服务器死机,你不能指望gatewayWorker给你100%送达,需要有一个像上面说的消息保存+标记+拉取机制。
感谢大佬解答