• 1. Rabbitmq技术培训 2015-8-5
  • 2. 内容 – 基础篇 · 基本概念 · 开发实战 · 集群搭建 2
  • 3. 内容 – 进阶篇 · 典型使用场景 · Rabbitmq与Erlang · Rabbitmq的分布式 · 高可用队列3
  • 4. 基础篇 – 基本概念2015/8/11
  • 5. · 同步转异步,提高吞吐量,提高系统的吞吐· 实现现实中消息的传播我们需要消息中间件吗? · 一切的变化都可以看做是一系列独立事件的 变化的组合 · 将峰值熨平,减少对系统的冲击 同步转异步,提高吞吐量, 量,平换系统的压力 · 解决事件的重发(回放) 实现现实中消息的传播方式 · 充当简单的ETL功能,数据流的分发和汇总, 通过pipeline的方法处理数据
  • 6. 典型消息中间件的使用场景
  • 7. 消息中间件==broker · 生产者和消费者失败互 不影响 · 两端的性能互不影响 · 生产者和消费者两端的 实例的增减只对各端的 负载有影响 · 生产者和消费者不关心 对方采用的技术
  • 8. AMQP(Advance Message Queuing Protocol) · 应用层开放协议(二进制协议) – 实现无关、语言无关 · AQM协议分层(三层)
  • 9. AMQP支持的消息场景 · 存储转发(多个消息发送者,单个消息接收者) · 分布式事务(多个消息发送者,多个消息接收者) · 发布订阅(单个消息发送者,多个消息接收者) · 基于内容的路由(多个消息发送者,多个消息接收者) · 文件传输队列(多个消息发送者,多个消息接收者) · 点对点连接(单个消息发送者,单个消息接收者)
  • 10. JMS VS AMQP JMS AMQP 定义 Java api Wire-protocol 跨语言 否 是Mode Peer-2-Peer Pub/sub 支持消息类型 TextMessage MapMessage BytesMessage StreamMessage ObjectMessage 2015/8/11direct exchange fanout exchange topic change headers exchange system exchange byte[] 当实际应用时,有复杂的 消息,可以将消息序列化 后发送。
  • 11. 开源消息中间件 Rabbitmq Activemq Kafka Nsq zeroQ 2015/8/11
  • 12. 我们的选择 Rabbitmq Kafka 2015/8/11
  • 13. Rabbitmq技术特点 · 可靠性 · 性能 · 灵活的路由 · 集群 · 联合 · 高可用的队列 · 多协议 · 广泛的客户端 · 可视化管理工具 · 追踪 · 插件系统 2015/8/11
  • 14. Rabbitmq生态圈
  • 15. 技术术语 · Connection/Channel · Publisher, Consumer · Broker · Exchange, Binding, Routing Key, Queue · Vhost
  • 16. channel · 应用和broker之间的连接 · 发布和定义之前都要进行连接(TCP连接) · 存在TCP连接中的虚拟链接 · 具有唯一的ID · 只能被一个线程使用
  • 17. 消息 2015/8/11
  • 18. Virtual Host · 虚拟broker,默认”/” · 有各自的exchange,binds,queue,permission · 权限控制、应用隔离 · command – Rabbitmqctl add_vhost [vhost_name] – rabbitmqctl delete_vhost [vhost_name] – rabbitmqctl list_vhosts
  • 19. Exchange消息分发机制
  • 20. Rabbitmq如何保证HA · Erlang的基本机制 · 分布式集群 · 持久化 · 确认机制 2015/8/11
  • 21. Erlang高并发的秘密 · 成千上万轻量细粒度进程 · 公平调度到CPU多核 · Actor模型,进程间消息传递通信
  • 22. Erlang处处维稳 · Erlang 9个9的稳定性 · Let it crash,关键是要重新起来 · Supervisor行为模式,构建进程监控树 · 代码热更新
  • 23. Erlang自我保护 · AMQP协议级别流控 · Erlang VM层面内存 cpu过载保护 · 集群层面容灾 · 预先报警
  • 24. 持久化 · 元数据持久化 · 消息持久化的三个条件
  • 25. 元数据的管理 · 元数据的 申明是幂等,不同参数申明失败 · 如果没有申明bind的queue,默认情况下,消 息被丢弃 2015/8/11
  • 26. 元数据的持久化 · Exchange的持久化,在声明时指定 durable=>1 · Queue的持久化,在声明时指定durable=>1 消息的持久化,在投递时指定 delievery_mode=>2(1是非持久化) · 如果exchange和queue是持久化的,则 binding也是持久化的。如果有一个不是持久 化的不允许建立连接 2015/8/11
  • 27. 消息的持久化 · 消息的组成: Payload:你想要传输的数据 Label:主要用于routing(路由)(exchange名字和 可选的topic tag) 用于描述payload,用于决定给谁一份拷贝 当消息到达consumer,消息不带label · 默认queue和exchange的属性durable为false · 持久化的三个条件 设定消息的delivery mode:2 持久化 发布到持久化的exchange 到达持久化的queue · 是否需要需要镜像队列 2015/8/11
  • 28. · 消息确认确认机制 · 生产者 · publisher confirms · 确保消息妥投到各个队列 · Confirm.SelectOk · 消费者考虑 消息确认(一个很容易犯的错误就是忘了basic_ack, 后果很严重。消息在你的程序退出之后就会重新发 送,如果它不能够释放没响应的消息,RabbitMQ 就会占用越来越多的内存) 2015/8/11
  • 29. 集群2015/8/11
  • 30. 三种不同等级的部署 · 单实例 · Clustering – LAN 内单逻辑broker – 共享user,exchange,queue · Federation/Sholve – WAN内多broker – Fed. 从一个交换机镜像消息到另一个交换机 – Sho.更低层次,消息从队列到队列
  • 31. 元数据 · 在性能和可恢复性之间考虑 · 选择disk节点和ram节点 · 在创建queue是只有在连接的那个节点上创建
  • 32. 2015/8/11
  • 33. 2015/8/11
  • 34. RAM,DISK node 2015/8/11
  • 35. 部署 2015/8/11
  • 36. 集群更多介绍 · 集群无中心节点,方便4层和7层流量切分 · 集群各节点通过Erlang消息传递来通信 · Erlang cookie,erlang及rabbitmq版本必须相同 · 节点可分为disk节点或ram节点,至少需要一个disk节 点 · 除消息队列,元数据信息(vhost, exchange, binding) 会复制到其他节点 · 如果只有一个磁盘节点,如果crash,能路由但是不 能创建queues, exchanges等 · 队列各节点可见,默认不复制;如需复制,需要使用 镜像队列(Mirrored Queue)机制
  • 37. 集群的考虑点 · 存储空间(Storage space) · 性能(Performance) 典型设置: 30 RabbitMQ RAM nodes 1 RabbitMQ Disc node 1 RabbitMQ Stats node(管理)
  • 38. Mirror queue 2015/8/11
  • 39. Mirror queueha-modeha-paramsall(absent)exactlycountnodesnode names1)用policy来声明 2)如果slave有问题,消息发布者确认会有问题 2015/8/11
  • 40. Mirrored Queue内部细节(一) · 一个master,多个slave,消息以master为主 · Pulisher可选择任意节点连接,消息转发到master · Master 本地处理后组播复制消息到其他节点存储 · Consumer可选择任意节点连接,请求转发给master · Consumer消费消息后ack · Master收到ack后,才会删除消息,ack消息会同步( 默认异步)到slave,slave删除消息 · Master失效情况下,ack同步可能丢失,消息会重发
  • 41. Mirrored Queue内部细节(二) · Cluster方式下的HA机制 · Master失效,内部选举消息队列最长的slave为 master · 镜像队列支持消费者确认和事务 · 可能存在不同步的slave,可自动同步或手动同步
  • 42. 集群视图 · 节点共享users,vhosts,exchanges, queues · 不能很好的处理分区容忍,作用于LAN · 前端可用Haproxy/Nginx 做load balance · 提高系统可用性及吞吐量