MQ介绍
为什么要使用mq（优点）
应用解耦
将同步调用修改为通过mq发布订阅消息，当增加或减少消费者时，生产者不需要做任改动。减少系统响应时间，如果全部为同步，所有流程走完时各个系统之和，但是修改异步后，即使某个系统出现故障，也能在故障修复后重新消费消息，达到最终一致性的。流量削峰
当qps超过我们数据库的极限时，使用mq在中间作为缓冲，处理消息的速度是由消费者来决定的，虽然qps很大，但是处理请求的速度依然是按部就班，可以避免数据库被压垮。数据分发
将同步调用修改为异步调用，增加或减少消费者不会影响生产者，生产者只需要保证生产消息到mq。
mq的缺点
系统可用性降低，引入外部依赖越多，系统稳定性越差，一旦mq宕机，业务会瘫痪
系统复杂度提高，异步调用问题，重复消费问题，消息丢失问题，消息的顺序性问题。
一致性问题，一个子系统处理失败，如何保证消息处理的一致性。
各种mq比较
activemq（java）、rabbitmq（erlang）、rocketmq（java）、kafka（scala）
kafka、rocketmq单机吞吐量高，10w级
rabbitmq时效性较高us级，erlang性能高
activemq、rabbitmq可以主从架构，较高可用性；rocketmq和kafka可以分布式架构，非常高可用性
rocketmq作为消息队列比较火，kafka在大数据领域比较火
快速入门
启动nameServer和broker，启动生产者消费者demo来测试
nohup sh bin/mqnamesrv &
tailf ~/logs/rocketmqlogs/namesrv.log
nohup sh bin/mqbroker -n localhost:9876 &
tailf ~/logs/rocketmqlogs/broker.log
通过runbroker.sh和runserver.sh可以调整rocketmq的虚拟机内存
rocketmq集群搭建
rocketmq角色介绍
producer：消息的发送者，发信者
consumer：消息的接受者，收信者
broker：暂存和传输消息，邮局
nameserver：管理broker，管理邮局的机构
topic：区分消息的种类，一个发送者可以发送消息给一个或者多个topic；一个息接收者可以接受一个或者多个topic
message queue：相当于topic的分区，用于并行发送和接受消息
集群搭建方式
集群特点
nameserver是无状态的，数据是一样的，没有差异，nameserver集群搭建比较方便，直接启动多个nameserver就可以了，节点之前无任何信息同步，
producer就是我们的应用，也是没有状态的，直接启动多个实例，producer与nameserver集群中的一个节点（随机选择）建立长连接，定期从nameserver中获取topic路由信息，并向提供topic服务的master建立长连接，且定时向master发送心跳。
consumer与nameserver集群中的其中一个节点（随机选择）建立长连接，定期从nameserver取topic路由信息，并向提供topic服务的master和slave建立长连接，且定时向master和slave发送心跳（因为broker可以推送消息，consumer也可以主动去拉消息，需要互相知道是否存活）。consumer既可以从master订阅消息，也可以从slave订阅消息，订阅规则由broker配置决定。
broker每组都有分主从节点，主写从读（可配置），一个master可以对应多个slave，但是一个slave只能对应一个master。master和slave的对应关系通过指定相同的broderName，不同的BrokerID来定义，broker为0代表主节点，非0代表从节点。master可以部署多个，每个broker和nameserver集群中的所有节点建立长连接，定时注册topic信息到所有nameserver。master和slave会进行数据复制，可以是同步的也可以是异步的。
集群模式
单master模式(单机模式)
这种方式风险较大，一旦broker重启或者宕机，会导致整个服务不可用。多master模式
一个集群无slave，全是master，例如两个或3个master，这种模式优缺点如下：
优点： 配置简单，单个master宕机或重启对应用无影响，在磁盘配置为raid10时，即使机器宕机不可恢复的情况下，由于raid10非常可靠，消息也不会丢失（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高。
缺点： 单台机器宕机时，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。多master多slave模式（异步）
每个master配置一个slave，有多个master-slave组合，ha（高可用）采用异步复制方式，主备有短暂的消息延迟（毫秒级），这种模式的优缺点如下：
优点： 即使磁盘损坏，消息丢失的非常少，且消息的实时性不会收到影响，同时master宕机后，消费者仍然可以从slave读取，并且过程对应用透明，不需要人工干预，性能同多master模式几乎一样。
缺点： master宕机，磁盘损坏的情况下，会丢失少量消息。多master多slave模式（同步）
每个master配置一个slave，有多对master-slave，ha采用同步双写方式，等主备都写成功，再返回给应用结果。这种模式的优缺点如下：
优点： 数据与服务都无单点故障，master宕机的情况下，消息无延迟，服务可用性和数据可用性都非常高。
缺点： 性能比同步方式略低（大约10%），发送单个消息的rt会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。
双主双从集群搭建
架构图（同步双写）
工作流程
启动nameserver，nameserver启动监听，等待broker、producer、consumer接，相当于一个路由控制中心
broker启动，跟所有的nameserver建立长连接，定时发送心跳，心跳包中包括当broker的信息（ip、端口号、存储的所有topic信息），注册成功后，nameserver集群就有了broker和topic的映射关系。
收发消息前，先创建topic，创建时要指定该topic要存储到哪些broker上，也可以在送消息时自动创建topic（不安全）
producer启动，和nameserver建立长连接，发送消息时先从nameserver中获取当发送的topic存在在哪些broker上，轮询从队列列表中选择一个队列，然后与队列所在broker建立长连接从而发送消息。
consumer跟producer相似，跟其中一台nameserver建立长连接，获取当前订阅topi存在在哪些broker上，然后直接和broker建立长连接，开始消费消息。
