Dubbo：
微服务框架，底层用的是RPC。zk宕机后，消费者能正确运行。zk会动态的向客户端更新服务列表信息。当zk宕机后，由于之前已经同步了zk的服务列表信息,所以客户端可以按照自己已经缓存的清单进行访问。
dubbo负载均衡策略：在reference标签中配置负载均衡策略；“loadbalance=” random "；四种：Random随机; RoundRobin轮循；LeastActive最少活跃调用数，使慢的提供者收到更少请求；ConsistentHash 一致性Hash，相同参数的请求总是发到同一提供者。
Dubbo通讯协议：采用单一长连接和 NIO 异步通讯，适合小数据量和高并发的服务调用。不适合传送大数据量的服务，比如传文件，传视频等。
Dubbo内置了的服务容器：Spring Container Jetty Container Log4j Container
Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。
Dubbo缺点
性能低：分布式系统是跨进程，跨网络的，性能受网络延迟和带宽的影响。
可靠性差：高度依赖网络，任何一次远程调用都可能失败。
Dubbo里面的节点角色：
Dubbo与httpClient对比，httpClinet用的是http协议，发送的信息的太多，占用太多网络资源。
Dubbo 使用的是 RPC 通信，Spring Cloud 使用的是 HTTP RESTFul 方式。
Zookeeper：
rabbitMQ：
Exchanges: 交换机 作用:将消息发往不同的队列中
Queues:表示消息队列 存储数据的位置是内存。
消息队列模式：简单模式、工作模式、发布订阅模式、路由模式、主题模式
订阅与工作模式区别：订阅模式每个消费者得到的消息是一样的，工作模式每个消费者得到消息是不一样的。
解决高并发用工作模式；同一个消息，多个模块要处理用订阅。
路由模式：通过定义不同的路由key使得程序将消息发送到不同的队列中。
主题模式：可以通过路由key将消息发送到一类相同的key中 使用通配符实现；符号说明:#号:表示任意字符(任意个.)；*号:任意单个字符或者词组(单个.)
原理：当客户端(生产者)将消息写入消息队列中时,消息队列中信息的数量加一。消费者实时监听消息队列,当消息队列中有消息时,则获取消息,之后执行业务逻辑.同时消息队列的数量减一。
数据持久化：队列持久化 + 消息持久化
队列持久化：在生产者和消费者两端设置队列时，设定队列的属性：boolean durable=true
消息持久化：在生产者中为要发送的消息设置属性Properties，实现消息持久化。
BasicProperties.Builder builder = new Builder();
builder.deliveryMode(2); // 把消息保存到硬盘上。
BasicProperties props = builder.build();
消息确认：自动确认和手动确认；
在使用channel链接consumer和队列时，为其设置属性：
boolean autoAck=false; 手动确认
boolean autoAck=true; 自动确认元数据主要分为 Queue 元数据（queue 名字和属性等）、Exchange 元数据（exchange 名字、类型和属性等）、Binding 元数据（存放路由关系的查找表）
vhost内部均含有独立的 queue、exchange 和 binding 等，拥有独立的权限系统，可以做到 vhost 范围的用户控制，可以作为不同权限隔离的手段。
RAM node 和 disk node 的区别：RAM node 仅将 queue、exchange 和 binding等 RabbitMQ基础构件相关元数据保存到内存中，但 disk node 会在内存和磁盘中均进行存储。
routing_key 和 binding_key 的最大长度是255 字节。
死信队列：dead letter queue；当消息被 RabbitMQ server 投递到 consumer 后，但 consumer 却拒绝时（同时设置 requeue=false），那么该消息会被放入“dead letter”queue 中。该 queue 可用于排查 message 被拒绝原因。
