话题通信机制
话题通信的实现依赖于三个角色的设立:
- 订阅者(Subscriber)
- 发布者(Publisher)
- 管理者(Master)
简单来说,Master负责保管发布者和订阅者注册的信息,帮助匹配话题相同的发布者和订阅者 ,实现话题通信。
这样的连接建立之后,发布者可以发布消息,且发布的消息会被订阅者订阅。
2.1 话题通信的概念
2.1.1 发布者的注册
发布者启动之后,会通过RPC在Masterzhub注册自己,同时会注册自己发布的话题(名称)。Master会将节点的注册信息加入注册表。
2.1.2 订阅者的注册
订阅者启动之后,也会通过RPC在Masterzhub注册自己,同时会注册自己订阅的话题(名称)。Master会将节点的注册信息加入注册表。
2.1.3 Master实现匹配
Master会定时扫描注册表,将注册表内的节点信息进行匹配(并通过RPC向订阅者发送发布者的RPC地址),将匹配成功的节点信息加入匹配表。
2.1.4 Subscriber向Pubilsher发送连接请求
订阅者根据接受的RPC地址,通过RPC向发布者发布连接请求(订阅的话题名称、消息类型以及通信协议)。
通信协议有TCP和UDP两种。
2.1.5 Publisher确认请求
Publisher收到请求,通过RPC返回一个信息确认,发送自己的地址信息。
2.1.6 连接建立
Subscriber根据上一步返回的消息,拿到确认了拿到地址了,这样就可以建立连接了。
2.1.7 发送消息
连接建立后,由发布者发送消息,订阅者收到消息。
我感觉这个协议很像TCP的那套握手挥手,事实上前五步都是在使用RPC协议,最后两步使用了TCP协议。
需要注意的是发布者和订阅者之间没有“先有鸡后有蛋”的讲究,也就是不考虑启动顺序;发布者和订阅者都可以有多个;连接建立之后,Master就不再重要(做了个媒),关闭Master也可以照常通信。