gopush-cluster 架构

bhtfg538 · · 5040 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

前言

gopush-cluster是一套golang开发的实时消息推送集群,主要分享一下开发这套系统的想法和思路。

架构

主要分为三个模块来开发,comet/web/message。

comet

主要负责消息排队、消息推送以及和客户端的连接维护;整套系统依据是消息ID顺序原则获取消息(客户端本地获取最大的消息是1,那么之后获取的消息就是大于1的,获取离线消息的时候也要从上次最大消息ID来获取),因此消息推送以后需要在comet中排队然后发起RPC给message实现存储。

message 

主要负责消息的存储和读写;接受来自comet模块的消息进行持久化,或者接受web模块的读取消息请求获取离线消息。message是可以部署多个节点来负载来自大量comet的推送压力,比如不同的comet使用不同的message节点(节点无状态),之后在comet也会做多message节点的负载均衡RPC调用和故障转移(TODO)。

web

主要负责节点询问,以及离线消息获取和后台节点管理等;节点询问主要依据客户端的订阅Key一致性hash计算出连接的comet节点地址,因此海量客户端连接的时候可以打散到多个comet来服务;另外离线消息也是通过web接口返回给客户端的,但是消息的读取是通过RPC发送给message模块的,尽量的职责单一。web节点因为无状态,可以部署多个web,来实现负载均衡和故障转移。

thrid-part

消息存储现在主要依赖Redis进行消息读写(Sorted Set),因为Sorted Set不支持int64类型的Score(我们也开发了一个支持int64 Score的分支但是因为时间原因没有大量测试上线),之后可能会使用HBase集群代替Redis的使用,已提供更安全的离线消息存储(TODO)。

另外使用了Zookeeper来实现的同一个comet的故障转移,例如comet 节点1可以有一个备选节点节点2,当节点1注册到zookeeper之后,因为机器或者其他原因宕了,这时候会在web层触发zookeeper的选举选中节点2来服务。

结束语

gopush-cluster大致的架构就说到这了,之后会写其他模块细节以及优化和遇到的问题。


有疑问加站长微信联系(非本文作者)

本文来自:博客园

感谢作者:bhtfg538

查看原文:gopush-cluster 架构

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

5040 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传