消息中间件

1、RabbitMQ原理

image.png

• vhost（虚拟主机）：每个虚拟主机其实都是mini版的RabbitMQ，拥有自己的队列，交换器和绑定，拥有自己的权限机制；
• Channel（信道）：消息推送使用的通道，信道是生产消费者与rabbit通信的渠道，生产者publish或是消费者subscribe一个队列都是通过信道来通信的。信道是建立在TCP连接上的虚拟连接，什么意思呢？就是说rabbitmq在一条TCP上建立成百上千个信道来达到多个线程处理，这个TCP被多个线程共享，每个线程对应一个信道，信道在rabbit都有唯一的ID ,保证了信道私有性，对应上唯一的线程使用。
• Exchange（交换机）:Exchange 用于转发消息，但是它不会做存储，如果没有 Queue bind 到 Exchange 的话，它会直接丢弃掉 Producer 发送过来的消息；
• RoutingKey（路由键）:用于把生成者的数据分配到交换器上；
• BindingKey（绑定键）:用于把交换器的消息绑定到队列上；
• Queue（队列）：用于存储生产者的消息；
  总结：信道才是rabbit通信本质，生产者和消费者都是通过信道完成消息生产消费的；交换器本质是一张路由查询表（名称和队列id，类似于hash表），这是一个虚拟出来的东西，并不存在真实的交换器。
  消息的生命周期：生产者生产消息A 交由信道，信道通过消息（消息由载体和标签）的标签（路由键）放到交换器发送到队列上（其实就是查询匹配，一旦匹配到了规则，信道就直接和队列产生连接，然后将消息发送过去）

2、RabbitMQ交换机的种类

• Direct: 1:1类似完全匹配，direct 类型的行为是"先匹配, 再投送"，即在绑定时设定一个routing_key, 消息的routing_key匹配时, 才会被交换器投送到绑定的队列中去；
  

  image.png
• Topic： N:1，按规则转发消息（最灵活），多个交换器可以路由消息到同一个队列。根据模糊匹配，比如一个队列的routing key 为*.test ，那么凡是到达交换器的消息中的routing key 后缀.test都被路由到这个队列上；
  

  image.png
• Fanout：1:N，：实际上就是广播，发送到fanout交换器的消息，会被转发给所有和这个交换器绑定的队列；
  

  image.png
• Headers：设置header attribute参数类型的交换机。

3、Rabbit消息丢失问题

image.png

• 生产者丢失数据：
  生产者发送数据之前开启 RabbitMQ 事务channel.txSelect，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务channel.txRollback，然后重试发送消息；如果收到了消息，那么可以提交事务channel.txCommit。
  开启 confirm 模式，在生产者那里设置开启 confirm 模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个 ack 消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你的一个** nack 接口**，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
  事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是 confirm 机制是异步的，你发送个消息之后就可以发送下一个消息，
• RabbitMQ丢失数据：
  开启 RabbitMQ 的持久化，就是消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，RabbitMQ 还没持久化，自己就挂了，可能导致少量数据丢失。
  设置持久化有两个步骤：
  创建 queue 的时候将其设置为持久化，这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是它是不会持久化 queue 里的数据的。
  发送消息的时候将消息的 deliveryMode 设置为 2
  持久化可以跟生产者那边的 confirm 机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者 ack 了，所以哪怕是在持久化到磁盘之前，RabbitMQ 挂了，数据丢了，生产者收不到 ack，你也是可以自己重发的。
• 消费端弄丢了数据：
  关闭 RabbitMQ 的自动 ack，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里 ack 一把
  

  image.png

4、 如何避免消息重复投递或重复消费

在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重和幂等的依据（消息投递失败并重传），避免重复的消息进入队列；在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重和幂等的依据，避免同一条消息被重复消费。

5、ActiveMQ工作模式:

image.png

6、Redis

6.1概念

redis是一个开源的使用C语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的API。和Memcached类似，它支持存储的value类型相对更多，包括string，list，set(集合)，zset(有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。与memcached一样，为了保证效率，数据都是缓存在内存中。区别是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave（主从）同步。

6.2reids事务(redis不支持回滚操作)

• MULTI：用于标记事务块的开始。Redis会将后续的命令逐个放入队列中，然后才能使用EXEC命令原子化地执行这个命令序列。
• EXEC：在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。
  当使用WATCH命令时，只有当受监控的键没有被修改时，EXEC命令才会执行事务中的命令，这种方式利用了检查再设置（CAS）的机制。这个命令的返回值是一个数组，其中的每个元素分别是原子化事务中的每个命令的返回值。当使用WATCH命令时，如果事务执行中止，那么EXEC命令就会返回一个Null值。
• DISCARD：清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。如果使用了WATCH命令，那么DISCARD命令就会将当前连接监控的所有键取消监控。
• WATCH：当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的。
• UNWATCH：清除所有先前为一个事务监控的键。如果你调用了EXEC或DISCARD命令，那么就不需要手动调用UNWATCH命令。

6.3 Redis持久化

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
  fork一个进程，遍历hash table，利用copy on write，把整个db dump保存下来。
  save, shutdown, slave 命令会触发这个操作。
  粒度比较大，如果save, shutdown, slave 之前crash了，则中间的操作没办法恢复。
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
  把写操作指令，持续的写到一个类似日志文件里。（类似于从postgresql等数据库导出sql一样，只记录写操作）
  粒度较小，crash之后，只有crash之前没有来得及做日志的操作没办法恢复。

两种区别就是，一个是持续的用日志记录写操作，crash后利用日志恢复；一个是平时写操作的时候不触发写，只有手动提交save命令，或者是关闭命令时，才触发备份操作。
选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

6.4 mySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略（回收策略）。redis 提供 6种数据淘汰策略：

• volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
• allkeys-random：（（从数据集（server.db[i].dict）中任意选择数据淘汰
• no-enviction（驱逐）：禁止驱逐数据

6.5 redis应用

• String：缓存、限流、计数器、分布式锁、分布式Session
• Hash：存储用户信息、用户主页访问量、组合查询
• List：微博关注人时间轴列表、简单队列
• Set：赞、踩、标签、好友关系
• Zset：排行榜

6.6 redis数据模型

redis数据结构

Redis用到的主要数据结构包括：简单动态字符串、链表(双端链表)、字典、跳跃表、 整数集合、压缩列表(后面再了解)。Redis没有直接使用这些数据结构来实现键值对数据库，而是基于这些数据结构创建一个对象系统，这个系统对象包括:字符串对象、列表对象、哈希对象(散列)、集合对象、有序集合对象这五种类型，每种类型对象都用到了至少一种前面所介绍的数据结构。

typeof struct redisObject{
            //类型
            unsigned type:4;
            //编码
            unsigned encoding:4;
            //指向底层实现数据结构的指针
            void *ptr;
            //...
        }robj;

• 对象的type属性记录了对象的类型，对于键来说它总是一个字符串对象，而值可以是五种类型

  
  
  

  type取值

• 对象的ptr指针指向对象的底层实现数据结构，而这些数据结构由对象的encoding属性决定，encoding记录了对象所使用的编码。

  
  
  

  底层数据结构与encoding编码的对应关系
  
  
  

  五种对象类型与encoding编码的对应关系
  
  

  字符串对象：

• 使用set命令创建一个int编码的字符串对象

    127.0.0.1:6379> set num1 10086
    OK
    127.0.0.1:6379> object encoding num1
    "int"

RedisObject结构中ptr指向一个long值

int

• 使用set命令，创建一个raw编码的字符串对象。这个字符串值的长度大于32字节。

    127.0.0.1:6379> set story3 "long long long long long long long long long ..."
    OK
    127.0.0.1:6379> strlen story3
    (integer) 48
    127.0.0.1:6379> object encoding story3
    "raw"

RedisObject结构中ptr指向SDS的sdshdr结构

raw

• 使用set命令，创建一个embstr编码的字符串对象, 这个字符串值的长度小于等于32字节。

    127.0.0.1:6379> set story4 "long long long long long lon"
    OK
    127.0.0.1:6379> strlen story4
    (integer) 28
    127.0.0.1:6379> object encoding story4
    "embstr"

embstr编码是专门用于保存短字符串的一种优化编码方式，这种编码和raw编码一样，都使用RedisObject结构和sdshdr结构来表示字符串对象。使用embstr编码的字符串对象来保存短字符串值有以下好处：　
(1) embstr编码将创建字符串对象所需的内存分配次数从raw编码的两次降低为一次。
(2) 释放embstr编码的字符串对象只需要调用一次内存释放函数。而raw编码的为二次。
(3) embstr编码的字符串对象的所有数据都保存在一块连续的内存中，能更好的带来缓存优势。

6.7 为什么redis这么快

• 纯内存访问Redis将所有数据放在内存中，内存的相应时长大约为100ns，这是Redis达到每秒万级别访问的重要基础。
• 非阻塞I/O，Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。
• 单线程避免了线程切换和竞态产生的消耗。

6.8 redis三种集群方式

6.8.1主从复制

原理：

• 从服务器连接主服务器，发送SYNC命令；
• 主服务器接收SYNC命令后，开始执行BGSAVE命令生成RDB快照文件并使用缓冲区记录此后执行的所有写命令；
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的所有写命令；
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
• 主服务器快照发送完毕后，开始向从服务器发送缓存区的写命令；
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）
• 主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

优点：

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
• Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
• Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

• Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

6.8.2 哨兵模式

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工作方式：

• 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
• 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
• 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
• 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
• 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
• 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
• 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

优点：
哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
主从可以自动切换，系统更健壮，可用性更高。

缺点：
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

6.8.3 Redis-Cluster集群

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：

• 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
• 节点的fail是通过集群中超过半数的节点检测失效时才生效。
• 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式：
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

7、kafka

7.1 kafka分区与消费者的关系

生产者发送消息到主题，消费者订阅主题（以消费者组的名义订阅），而主题下是分区，消息是存储在分区中的，所以事实上生产者发送消息到分区，消费者则从分区读取消息。
在server.properties配置文件中可以指定一个全局的分区数设置，这是对每个主题下的分区数的默认设置，默认是1。每个主题也可以设置自己的分区数量。

生产者将消息投递到分区的规律，默认的分区策略：

• 如果在发消息的时候指定了分区，则消息投递到指定的分区
• 如果没有指定分区，但是消息的key不为空，则基于key的哈希值来选择一个分区
• 如果既没有指定分区，且消息的key也是空，则用轮询的方式选择一个分区

7.2 kafka工作方式

Consumer Group：这是kafka用来实现一个topic消息的广播和单播的手段，一个topic可以有多个group，topic的消息会发送给所有的group，但每个group只会把消息发给该group中的一个consumer。

• 如果要实现消息广播，每个consumer需要有一个独立的group；
• 如果要实现单播只要所有的consumer在同一个group；