一、架构
二、流程解析
1.在zookeeper注册生产者,给生产者分配标识key
注:不同的生产者可以有不同的key,也可以选择使用相同的key。一般是类似功能的生产者分配一个key
2.在zookeeper注册消费者,也给消费者分配key
注:key的
3.消费者拿给生产者分配的key去访问对应的生产者
4.生产者先对消费者分发一些服务器,再对请求的数据进行一系列计算,判断分发到哪个服务器。同时将消费者对应请求分发到的服务器域名记入缓存,下次直接访问。
三、要点解析
zookeeper:ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,它的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。zookeeper中可以会记录可以使用的服务器,可以使用的为绿色,出现问题不能使用的为红色,down掉的会消失
生产者:将接口封装成jar包提供给ZooKeeper,同时ZooKeeper还封装了要访问的各个服务器的域名。
消费者:要使用这些接口的使用者
通信方式:ZooKeeper和生产者消费者之间以RPC协议通信
RPC协议: 一种进程间通信方式。允许像调用本地服务一样调用远程服务。
RPC框架的主要目标:让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式(TCP或者UDP)、序列化方式(XML/JSON/二进制)和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可,并不需要关心底层通信细节和调用过程,所以具体的协议其实是自定义的。
注:生产者同时也可以是消费者,消费者也同时可以是生产者,所以每个消费者或生产者最多拥有两个key
如果生产者有一个服务器出问题了怎么办?
1.消费者第一次请求失败后,一般可以再有一次请求的机会,若此次失败,判断该服务器出问题,会告知消费者此服务器出现问题,请求会往有类似功能的另一个服务器上分配,同时更新缓存(几次请求机会自己设置)
2.该服务器出问题的数据会往ZooKeeper同步,若该服务器修复成功,消费者会再次通过ZooKeeper访问生产者的服务器,访问的域名依旧记录在缓存。
消费者和生产者如何知道这个服务器出问题?
当有一个服务器出问题时,zookeeper会记录该服务器出现问题。
这时候有两种渠道让消费者和生产者知道出现问题:
1.zookeeper实时向各个消费者和生产者发送推送告诉他们出现问题
2.消费者或生产者访问zookeeper时了解到出现问题