中间件

RabbitMQ是一款开源的，使用Erlang语言编写的，基于AMQP协议的消息中间件

AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、 安全

AMQP协议对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次

Connection

Channel

Message

Virtual Host

Exchange

Binding

RoutingKey

Queue

Broker

完全匹配，消息中的路由键(routing key)和Binding中的binding key一致

模糊匹配，两个通配符："#"和"*"，#匹配0个或多个单词，*只匹配一个单词

广播模式，不处理路由键，把所有发送到交换器的消息路由到所有绑定的队列中

忽略路由规则，根据消息中的headers属性来匹配，性能较低（不常用）

引入外部依赖越多，系统越容易挂掉MQ挂了，
也会导致整个系统不可用

如何保证消息没有重复消费？

如何保证消息传递的顺序？

如何保证消息不丢失？

A系统发送完消息直接返回成功，但是BCD系统之
中若有系统写库失败，则会产生数据不一致的问题

生产者发送消息到MQ

MQ中存储的消息丢失

消费者从MQ拉取消息

生产者丢消息

MQ丢消息

消费者丢消息

消息变成死信的原因

死信队列的设置

不推荐

推荐

利用redis的原子递增来实现，使用用户名作为key，每次递增1，返回值大于1则抛异常

Producer：消息的发送者

Consumer：消息接收者

Broker：暂存和传输消息

NameServer：路由中心（管理Broker）
                    类似注册中心

配置环境变量

修改 runserver.sh
修改 runbroker.sh

修改 broker.conf

启动

命令行快速验证

双主双从异步复制

rocketmq控制台

NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步

Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的Brokerld来定义， Brokerld为0表示Master， 非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信 息到所有NameServer

Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。 Producer完全无状态， 可集群部署

Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、Slave建 立长连接，且定时向Master、 Slave发送心跳。 Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定

单Master模式

多Master模式
2m-noslave

多主多从模式（异步）
2m-2s-async

多主多从模式（同步）
2m-2s-sync

Dledger集群

1. 启动NameServer，NameServer起来后监听端口，等待Broker、Producer. Consumer连上来，相当于一个路由控制中心

2. Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息（IP+端口等）以及存储所有Topic信息。注册成功后，
NameServer集群中就有Topic跟Broker的映射关系

3. 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic

4. Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列
列表中选择一个队列， 然后与队列所在的Broker建立长连接从而向Broker发消息

5. Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费

1. 创建消息生产者producer，并制定生产者组名
2. 指定Nameserver地址
3. 启动producer
4. 创建消息对象，指定主题Topic、Tag和消息体
5. 发送消息
6. 关闭生产者producer

1. 创建消费者Consumer，制定消费者组名
2. 指定Nameserver地址
3. 订阅主题Topic和Tag
4. 设置回调函数，处理消息
5. 启动消费者consumer

概念

分区有序的实现原理

集群模式(CLUSTERING)，一条消息在同一个消费者组下，只会有一个消费者来消费（默认模式）

广播模式(BROADCASTING)，不管消费者组的概念，一条消息过来就会推送给所有订阅了该topic的消费者

关键代码

Producer发送消息到Broker后，等待一段时间（可设置）再发送给消费者，可用作定时任务

使用限制

关键代码

Batch机制

使用限制

关键代码

过滤有两种方式

使用限制

关键代码

防止生产者丢消息

防止 Broker 丢消息

防止消费者丢消息

事务消息状态

系统可用性降低

系统复杂度提高

数据一致性问题

优点：吞吐量非常大，性能非常好，集群高可用

缺点：会丢消息（不适合订单系统），功能比较单一

使用场景：日志分析，大数据采集

优点：消息可靠性高，延迟低，功能较全面

缺点：吞吐量比较低，消息积累会严重影响性能，erlang语言不好定制

使用场景：小规模场景

优点：高吞吐，高性能，高可用，功能非常全面

缺点：开源版功能不如商业版，官方文档和周边生态还不够成熟，客户端只支持Java

使用场景：几乎是全场景（后发优势，设计时借鉴前两者的优点）

优点：实时性高

缺点：如果消费者处理能力跟不上，会导致消息堆积，服务崩溃

优点：消费者可根据自己的消费能力进行消费（自己编写消费逻辑）

缺点：实时性较低，拉取消息的间隔不太好设置，间隔太短，对服务
器请求压力过大。间隔时间过长，那么必然会造成一部分数据的延迟

Kafka：消息发送+回调

RocketMQ：事务消息机制
同步发送+多次尝试

RabbitMQ：生产者confirm机制

RocketMQ

RabbitMQ

Kafka

RocketMQ：采用同步刷盘策略

RabbitMQ：将队列配置成持久化队列

RocketMQ：使用默认的方式消费就行，不要采用异步方式

RabbitMQ：关闭消费者自动提交，改为本地事务成功再手动确认

Kafka：手动提交offset

先定位消费慢的原因，检测并处理bug

批量处理的速度比一条一条消费要快

优化完还是慢，则考虑水平扩容，增加队列和消费者数量

调大单个节点的线程数

获取长度

内存分配

缓冲区安全

二进制安全

可以通过 lpush/rpush 写入，rpop/lpop 读取

可以通过使用 brpop/blpop 来实现阻塞队列

可以通过 lrange key 0 -1 查看队列

应用

压缩列表（ziplist）

快速链表（quicklist）

利用交集查看共同粉丝列表

实现微信抽奖小程序

实现微博点赞、收藏、标签

整数集合（intset）

字典（hashtable）

压缩列表（ziplist）

跳跃表（skiplist）

通过 object encoding k1 查看底层实现结构

优点

缺点

压缩列表-ziplist

字典-hashtable

管道就是打包多条无关命令批量执行，以减少多个命令分别执行消
耗的网络交互时间（TCP网络交互），可以显著提升Redis的性能

地理空间，可以录入地理坐标并计算距离

底层实现原理是ZSet

基数统计的算法，根据并集的数量来计数

占用的内存固定，只需要12kb的内存，有0.81%错误率

位图，本质是String，使用二进制记录，只有0和1两种状态

最大长度是512M，可以表示2^32个不同的位

可以用来统计用户信息、点赞、打卡，两个状态的都可以

海量数据统计

批量操作在事务提交前被放入缓存队列，并不会被实际执行

Redis中单条命令是原子性执行的，但事务不保证原子性，且没有回滚

事务中任意命令执行失败，其余的命令仍会被执行

ttl key 返回 key 剩余过期秒数

pttl key 返回 key 剩余过期的毫秒数

为每个key创建一个定时器，对内存友好，对CPU不友好

用到的时候发现过期才删，可能存在大量过期key

redis默认每隔100ms就随机抽取一些过期的key删除

maxmemory <bytes>（配置redis最大使用内存）

config set maxmemory 1GB（动态配置）

如果没有配置，32位OS最多占用3G，64位OS不限制

allkeys-lru：从数据集中挑选最近最少使用的数据淘汰（推荐使用）

allkeys-random：从数据集中任意选择数据淘汰

volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰

volatile-random：从已设置过期时间的数据集中任意选择数据淘汰

volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰

no-enviction：禁止驱逐数据，再写入会报错（默认不回收）

volatile-lfu: 在设置了过期时间的键上，应用LFU策略

allkeys-lfu: 在所有键上，应用LFU策略

LRU

LFU

对比

redis 会单独创建(fork)一个与当前进程一模一样的子进程来进行持久化，
将数据写入到一个临时文件中，待持久化结束后替换上次持久化好的文件

这个持久化文件在哪里呢？

客户端执行 shutdown 命令时，如果没有开启 aof 会触发

配置文件中有快照配置，例如 save 900 1（15分钟内有1次修改）

执行 save 或 bgsave 命令

执行 flushall 命令

优点

缺点

将所有的写命令追加到 AOF 缓冲区中，根据对应的写入策略向硬盘进行同步操作

随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的

这个持久化文件在哪呢？

AOF 为什么要把命令追加到缓冲区，而不直接追加到磁盘？

需手动开启：appendonly yes

写入策略：appendsync everysec

  重写机制
bgrewriteaof

优点

缺点

5.0以后默认开启

重写后新的AOF文件前半段是RDB格式的全量数据，后半段是AOF格式的增量数据

优点

缺点

master 和 slave 都会维护一个 offset 和 run id，slave 每秒都会上报自己的 offect 给 master

master记录在backlog中，这样才能知道双方数据是否一致

slave发送 run id 和 offset 到 master，master 根据自身情况返回相应信息(增量/全量)复制

触发时机

复制过程

耗时原因

master 和 slave 都会维护一个 offset 和 run id，slave 每秒都会上报自己的 offect 给 master（backlog）

master 根据 slave 发送的同步请求中的 offset，在 backlog 中查找到部分丢失的数据，发送给 slave

避免相同票

监控主节点和从节点是否正常运行

检测到服务出现问题会通知其他哨兵

当确认主节点宕机后，在从节点中选一个作为主节点，将
其他从节点连接到新的主节点上，通知客户端最新的地址

一台哨兵发现master宕机了，标记为sdown（主观下线），并通知其他哨兵

其他哨兵去查看，如果超过quorum数量的哨兵认为挂了就标记为odwon（客观下线）

每个哨兵作为参选者和投票者，向哨兵内网发送指令

指令中携带自己的竞选次数和runid，先收到谁的指令就投票给谁

先过滤掉不在线和响应慢的服务器

然后过滤掉与原master断开时间最久的

最后再比较优先级priority、偏移量offset、runid

哨兵向选举出的新master发送指令，断开与旧master的连接

把新master的ip地址同步到其他slave节点

动态扩容和缩容，保证数据不冗余，且吞吐量更大

自动数据分片，每个master节点存放一部分数据

提供内置的高可用支持，允许部分master节点宕机

客户端使用一致性哈希等算法决定键应当分布到哪个节点

将客户端请求发送到代理上，由代理转发请求到正确的节点上

hash slot 算法

计算请求数据的hash值，并按照节点数量取模，再放入对应的master节
点中，如果某台master宕机了，由于master数量少了导致取模方式改变

缺点：会造成大量缓存重建

把请求数据的hash值对应在圆环的各个点上，然后顺时针寻找
离自己最近的master节点，如遇master宕机只会影响部分数据

基于上面的一致性hash算法，再在各个master节点之间创建均
匀分布的虚拟节点，如遇master宕机时就不会涌入同一个节点

优点：自动缓存迁移、自动负载均衡

redis cluster有固定的16384个哈希槽，对每个key计算CRC16的值，
然后对16384取模计算卡槽位置（每个槽位可以存放多个key）

即使有任何一台机器宕机，其他master中的缓存是不受影响的，失效的节点重新分配就可以了

集中式：将元数据（节点信息、故障）存储在某个节点上

 gossip协议

节点间内部通信

高性能的主备切换

这里的单线程是指Redis在处理网络请求的时候只有一个线程来处理

1、基于内存实现，数据都存储在内存里，减少了一些不必要的 I/O 操作

2、redis采用IO多路复用模型，同时监听客户端连接，单线程在执行过程中不需要进行上下文切换，减少了耗时

3、高效的数据结构

4、合理的数据编码

在单个库中不允许存在重复key

用来区分不同的业务逻辑

基于Json序列化存放

基于String的二进制存放

跳跃表的时间复杂度和红黑树一样，而且实现起来更简单

在并发环境下红黑树在插入和删除时需要rebalance，性能不如跳跃表

高频被访问的数据

数据的变化率不高

非敏感数据

简单方案

主流方案：布隆过滤器

简单方案：不给缓存添加超时时间，热点数据不失效

主流方案：分布式锁

给缓存加随机因子，分散失效时间

对redis缓存做高可用，集群部署，增加抗风险能力（前）

设置本地缓存ehcache+限流hystrix，避免数据库被干掉（中）

利用redis的持久化机制，重启redis快速恢复缓存数据（后）

先删缓存再更新数据库，期间有查询呢？

先更新数据库再删缓存，缓存删除失败呢？

最终解决方案

分布式锁

redis-cli --bigkeys命令，找出五大数据类型中最大的key
自定义扫描脚本，python居多，原理与bigkeys命令相似
也可以借助redis分析工具，分析RDB快照找出大key
注意redis是单线程处理任务，直接删除会阻塞

凭借业务经验，进行预估哪些是热key

客户端收集，在操作redis前对数据进行统计

使用redis自带命令：redis-cli 时加上 –hotkeys

打散到多个节点

利用多级缓存

读写分离扩容

设置永不过期