消息队列

RabbitMQ集群架构模式 那么对于Rabbitmq是单点应用来说，如果rabbitmq整个消息mq都会摊掉，所有在mq的消息高可用部分，就显得尤为重要了，那么在mq中提供了四种集群架构方案： 1、主备模式 （Warren) 2、镜像模式 （Mirror) 3、远程模式 (Shovel) 4、多活模式 （Federation) 在我们开发中最直接的模式就是主备模式：主要实现RabbitMQ的高可用集群，一般在并发和数据量不高的情况下，这种模型非常的好用且简单，主备模式也称为Warren模式 也就是一主一备，对于集群来说至少有两台服务器，那么这两台服务器一台在工作，一台在闲置，注意，这个的主备和我们之前的主从是不一样的，主从的话是一台作为主服务器，一台作为从服务器，虽然这两台是数据同步，主负责读写，而从只负责只读，而主备是一台工作一台闲着，如果一台服务器宕机了，那么备服务器切换过来，可能的话，这种对于负载均衡的话一台只忙着干活，一台只闲着，这种的生产中用的也很少，这种会造成我们资源的一个浪费。 镜像模式：集群模式非常经典的就是Mirror镜像模式，保证100%数据不丢失，在实际工作中也是用的最多的，而且实现集群也非常简单，一般互联网大厂都会构建这种镜像集群模式，原理主要是在主备的基础上进行了扩展，集群中所有的节点设备都是同步的，每一个队列，交换机里面的配置信息和我们的数据都是同步的

介绍 延迟队列，顾名思义它是一种带有延迟功能的消息队列。 那么，是在什么场景下我才需要这样的队列呢？ 很多时候我们会有延时处理一个任务的需求，比如说： 2个小时后给用户发送短信。 15分钟后关闭网络连接。 2分钟后再次尝试回调。 下面我们来分别探讨一下几种实现方案： 1、Java中的DelayQueue Java中的DelayQueue位于java.util.concurrent包下，本质是由PriorityQueue和BlockingQueue实现的阻塞优先级队列。 见《 延时队列：Java中的DelayQueue 》 2、使用Redis实现 前文我们看到，可以通过优先级队列来实现延迟队列的功能。Redis提供了很多数据结构，其中的zset是一种有序的数据结构；我们可以通过Redis中的zset来实现一个延迟队列。 基本的方法就是使用时间戳作为元素的score存入zset。 redis> ZADD delayqueue <future_timestamp> "messsage" 获取所有已经“就绪”的message，并且删除message。 redis> MULTI redis> ZRANGEBYSCORE delayqueue 0 <current_timestamp> redis> ZREMRANGEBYSCORE delayqueue 0 <current

目录 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 如何解决ResourceManager单点问题，实现高可用？ 6.2.3 Kafka 术语介绍 问题 Kafka与Zookeeper Broker注册管理 Topic注册管理 生产者负载均衡 消费者负载均衡 消费分区与消费者关系 消息消费进度Offset记录 消费者注册 负载均衡 1）Range策略 2）RoundRobin策略 资料 6.3 Zookeeper在阿里巴巴的实践与应用 6.3.2 案例二 RPC服务框架：Dubbo 服务提供者 服务消费者 监控中心 6.3.3 案例三 基于MySQL Binlog的增量订阅和消费组件：Canal Canal基本工作原理 Canal Server主备切换设计 Canal Client的HA设计 6.3.4 案例四 分布式数据库同步系统：Otter 分布式SEDA模型 数据模型 任务处理流程(多阶段任务协调处理) 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 YARN是Hadoop为了提高计算节点的扩展性，同时为了支持多计算模型和提供资源的细粒度调度而引入的全新一代分布式协调框架。 核心为ResourceManager，资源管理中心，负责集群中所有资源的统一管理和分配。 （可理解为YARN的大脑

3 月，跳不动了？>>> 1.安装 scala 1.1 解压缩(/opt) tar -zxvf scala-2.11.4.tgz mv scala-2.11.4 scala 1.2 配置环境变量 vi ~/.bashrc export SCALA_HOME=/usr/local/scala export PATH=$SCALA_HOME/bin source ~/.bashrc 1.3 验证 scala 是否安装成功 scala -version 1.4 二三节点安装 scala 复制scala scp -r scala 192.168.252.165:/opt scp -r scala 192.168.252.166:/opt 复制环境变量 scp ~/.bashrc 192.168.252.165:~ scp ~/.bashrc 192.168.252.166:~ 2.安装 kafka 2.1 解压缩 tar -zxvf kafka_2.9.2-0.8.1.tgz mv kafka_2.9.2-0.8.1 kafka 2.2 配置 kafka vi /opt/kafka/config/server.properties 修改 broker.id=0 //依次增长的整数，0、1、2、3、4 zookeeper.connect=192.168.252.164:2181,192

3 月，跳不动了？>>> 一、先扔一张图 说明: 本文涵盖了关于RabbitMQ很多方面的知识点, 如: 消息发送确认机制 消费确认机制 消息的重新投递 消费幂等性, 等等 这些都是围绕上面那张整体流程图展开的, 所以有必要先贴出来, 见图知意 二、实现思路 简略介绍163邮箱授权码的获取 编写发送邮件工具类 编写RabbitMQ配置文件 生产者发起调用 消费者发送邮件 定时任务定时拉取投递失败的消息, 重新投递 各种异常情况的测试验证 拓展: 使用动态代理实现消费端幂等性验证和消息确认(ack) 三、项目介绍 springboot版本2.1.5.RELEASE, 旧版本可能有些配置属性不能使用, 需要以代码形式进行配置 RabbitMQ版本3.7.15 MailUtil: 发送邮件工具类 RabbitConfig: rabbitmq相关配置 TestServiceImpl: 生产者, 发送消息 MailConsumer: 消费者, 消费消息, 发送邮件 ResendMsg: 定时任务, 重新投递发送失败的消息 说明: 上面是核心代码, MsgLogService mapper xml等均未贴出, 完整代码可以参考GitHub上的源码，地址在文末。 四、代码实现 1、163邮箱授权码的获取, 如图: 该授权码就是配置文件spring.mail.password需要的密码 2、pom

Kafka【第一篇】Kafka集群搭建 Kafka初识 1、Kafka使用背景 在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题： 我们想分析下用户行为（pageviews），以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计，分析出当前的流行趋势 有些数据，存储数据库浪费，直接存储硬盘效率又低 这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！ 2、Kafka的定义 What is Kafka：它是一个分布式消息系统，由linkedin使用scala编写，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。 3、Kafka和其他主流分布式消息系统的对比 定义解释： 1、Java 和 scala都是运行在JVM上的语言。 2、erlang和最近比较火的和go语言一样是从代码级别就支持高并发的一种语言，所以RabbitMQ天生就有很高的并发性能，但是 有RabbitMQ严格按照AMQP进行实现，受到了很多限制。kafka的设计目标是高吞吐量，所以kafka自己设计了一套高性能但是不通用的协议，他也是仿照AMQP（ Advanced Message Queuing

1 为什么需要kafka （1）在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题： 我们想分析下用户行为（pageviews），以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计，分析出当前的流行趋势 有些数据，存储数据库浪费，直接存储硬盘效率又低 这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！ （2）具有高水平扩展和高吞吐量。 （3）动态扩容 （4）zk完美结合，分布式调用，应用于soa架构 2 kafka概念 Broker Kafka集群包含一个或多个服务器，这种服务器被称为broker [5] Topic 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处） Partition Partition是物理上的概念，每个Topic包含一个或多个Partition. Producer 负责发布消息到Kafka broker Consumer 消息消费者，向Kafka broker读取消息的客户端。 Consumer Group

1 zookeeper如何实现高可用 1 zookeeper 多台构成集群实现高可用，有三种角色群首（leader），追随者（follower），观察者（observer）。 Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO Follower的逻辑就比较简单了。除了响应本服务器上的读请求外，follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交。，leader和follower构成ZooKeeper集群的法定人数，也就是说，只有他们才参与新leader的选举、响应leader的提议。 如果ZooKeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：首先observer不属于法定人数，即不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。 2 zookeeper如何实现负载均衡？ 以前接触的负载均衡是通过VIP调度到各个节点。如：nginx+keepalived实现负载均衡和高可用

介绍 RabbitMQ是一个在AMQP基础上完整的，可复用的企业消息系统。他遵循Mozilla Public License开源协议。 MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消 息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 应用场景： RabbitMQ无疑是目前最流行的消息队列之一，对各种语言环境的支持也很丰富，作为一个.NET developer有必要学习和了解这一工具。消息队列的使用场景大概有3种： 1、系统集成，分布式系统的设计。各种子系统通过消息来对接，这种解决方案也逐步发展成一种架构风格，即“通过消息传递的架构”。 2、当系统中的同步处理方式严重影响了吞吐量，比如日志记录。假如需要记录系统中所有的用户行为日志，如果通过同步的方式记录日志势必会影响系统的响应速度，当我们将日志消息发送到消息队列，记录日志的子系统就会通过异步的方式去消费日志消息。 3、系统的高可用性，比如电商的秒杀场景。当某一时刻应用服务器或数据库服务器收到大量请求，将会出现系统宕机

前言...... 前面简单介绍了Solace来自于哪家公司, 主要能做哪些事情. 本篇主要进一步介绍Solace作为消息传递的中间件如何工作的. 传统意义上来讲, 每当我们谈到消息中间件时, 首先想到的是基于Message Queue,有Apache的 Active MQ, IBM的Webshere的 MQ, Rabbit MQ都是基于内存/持久化到磁盘来实现的. 还有一种Oracle Advance MQ, 这是一种基于oracle数据库实现的Queue.天然支持基于数据库的操作.相当好用,只是了解的人不多,使用的也少,没有被广泛应用. 近些年,大数据的兴起, 使得对消息中间件的要求变得更高, 要求稳定,高效,可追溯,分布式的支持,实效性, 如Kafka , Redis. Solace是不同于以上的消息队列及缓存的机制, 它是完全基于硬件实现的消息队列中间件 .速度,效率,吞吐量,可靠性都高于以上几种消息中间件, 不同的是它是收费的,而且对于中小型企业控制成本来讲, 基本不是首选. 但是它在世界范围内的金融企业得到了广泛的认可和使用. Solace提供两种设备模型: PubSub+ 3530 : 从成本和提供的性能上有效地满足了中型企业的需求. PubSub+ 3560 : 从成本和所提供的性能上能够满足超大型公司重要数据, 云和物联网的要求. 下图为Solace的基本结构: