摘要：
死信队列 消息被消费方否定确认，使用channel.basicNack或channel.basicReject, 并且此时requeue属性被设置为false。 消息在队列的存活时间超过设置的TTL时间 消息队列的消息数量已经超过最大队列长度 那么该消息将成为"死信"。"死信"消息会被RabbitM 阅读全文
摘要：
五个角色 注册中心registry: 服务注册与发现 服务提供者provider: 暴露服务 服务消费者consumer: 调用远程服务 监控中心monitor: 统计服务的调用次数和调用时间 容器container: 服务允许容器 调用流程: container容器负责启动，加载，运行provid 阅读全文
摘要：
Eureka: 服务注册与发现 注册: 每个服务都向Eureka登记自己提供服务的元数据，包括服务的ip地址，端口号，版本号，通信协议等。eureka将各个服务维护在了一个服务清单中（双层Map，第一层key是服务名，第二层key是实例名，value是服务地址加端口）。同时对服务维持心跳，剔除不可用 阅读全文
摘要：
分布式容错框架 阻止故障的连锁反应，实现熔断 快速失败，实现优雅降级 提供实时的监控和警告 实现机制 资源隔离: 线程隔离，信号量隔离 线程隔离: Hystrix会给每一个Command分配一个单独的线程池，这样在进行单个服务调用的时候，就可以在独立的线程池里面进行，而不会对其他线程造成影响。 信号 阅读全文
摘要：
底层协议: Spring Cloud基于http协议，dubbo基于Tcp协议，决定了dubbo的性能相对会比较好 注册中心: Spring Cloud使用eureka，dubbo推荐使用zookeeper 模型定义: dubbo将一个接口定义为一个服务，Spring Cloud则是将一个应用定义为 阅读全文
摘要：
zk CP设计(强一致性)，目标是一个分布式的协调系统，用于进行资的统一管理。 当节点crash后，需要进行leader的选举，在这个期间，zk服务是不可用的。 eureka AP设计(高可用),目标是一个服务注册发现系统，专门用于微服务的服务发现注册。 Eureka各个节点都是平等的，几个节点挂掉 阅读全文
摘要：
客户端，可以通过在znode上设置watch，实现实时监听znode的变化 Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端 父节点的创建，修改，删除都会触发Watcher事件 子节点的创建，删除会触发Watcher事件 阅读全文