一、MySQL集群
1、集群原理
MySQL-MMM 是 Master-Master Replication Manager for MySQL（mysql 主主复制管理器）的简称。脚本）。MMM 基于 MySQL Replication 做的扩展架构，主要用来监控 mysql 主主复制并做失败转移。其原理是将真实数据库节点的 IP（RIP）映射为虚拟 IP（VIP）集。 mysql-mmm 的监管端会提供多个 虚拟 IP（VIP），包括一个可写 VIP， 多个可读 VIP，通过监管的管理，这些 IP 会绑定在可用 mysql 之上，当 某一台 mysql 宕机时，监管会将 VIP 迁移至其他 mysql。在整个监管过 程中，需要在 mysql 中添加相关授权用户，以便让 mysql 可以支持监理机的维护。授权的用户包括一个 mmm_monitor 用户和一个 mmm_agent 用户，如果想使用 mmm 的备份工具则还要添加一个 mmm_tools 用户。
二、Redis集群
1、集群形式
1.1客户端分区
客户端分区方案的代表为 Redis Sharding，Redis Sharding 是 Redis Cluster 出来之前，业 界普遍使用的 Redis 多实例集群方法。Java 的 Redis 客户端驱动库 Jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及结合缓存池的 ShardedJedisPool。
优点
不使用第三方中间件，分区逻辑可控，配置简单，节点之间无关联，容易线性扩展，灵活性强。
缺点
客户端无法动态增删服务节点，客户端需要自行维护分发逻辑，客户端之间无连接共享， 会造成连接浪费。
1.2代理分区
2、高可用方式
2.1、Sentinel（ 哨兵机制）支持高可用
哨兵的作用就是监控 Redis 系统的运行状况，哨兵机制可解决主从复制的主节点出问题后更新繁琐的问题，使用集群可解决主节点读写能力有限的问题。其功能主要是包括以下三个：
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的 Master 和 Slave 是否运作正常。
提醒(Notification): 当被监控的某个 Redis 出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover): 当主数据库出现故障时自动将从数据库转换为主数据库。
哨兵的原理
Redis 哨兵的三个定时任务，Redis 哨兵判定一个 Redis 节点故障不可达主要就是通过三个定 时监控任务来完成的：
1、每隔 10 秒每个哨兵节点会向主节点和从节点发送"info replication" 命令来获取最新的拓扑结构。
2、每隔 2 秒每个哨兵节点会向 Redis 节点的_sentinel_:hello 频道发送自己对主节点是否故 障的判断以及自身的节点信息，并且其他的哨兵节点也会订阅这个频道来了解其他哨兵节点的信息以及对主节点的判断。
3、每隔 1 秒每个哨兵会向主节点、从节点、其他的哨兵节点发送一个 “ping” 命令来做心 跳检测。
如果定时任务3监测不到节点的心跳，会判断“主观下线”，如果该节点是主节点那么会通知其他哨兵对该主节点进行心跳检测，如果主观下线的票数大于设置值，则认为此主节点故障，成为客观下线。
故障转移和 Leader 选举
如果主节点被判定为客观下线之后，就要选取一个哨兵节点来完成后面的故障转移工作，选 举出一个 leader，这里面采用的选举算法为 Raft。选举出来的哨兵 leader 就要来完成故障转移工作，也就是在从节点中选出一个节点来当新的主节点。
3、Redis-Cluster
官方多机部署方案，。一组 Redis Cluster 是由多个 Redis 实例组成，推荐使用 6 实例，其中 3 个为主节点，3 个为从结点。一旦有主节点发生故障的时候， Redis Cluster 可以选举出对应的从结点成为新的主节点，继续对外服务，从而保证服务的高可用性。Redis Cluster 把所有的数据划分为 16384 个不同的槽位，可以根据机器的性能把不同的槽位分配给不同的 Redis 实例，对于 Redis 实例来说，他们只会存储部分的 Redis 数据，槽的数据是可以迁移的，不同的实例之间，可以通过一定的协议进行数据迁移。
一致性哈希可以很好的解决稳定性问题，可以将所有的存储节点排列在收尾相接的 Hash 环上，每个 key 在计算 Hash 后会顺时针找到临接的存储节点存放。而当有节点加入或退出时，仅影响该节点在 Hash 环上顺时针相邻的后续节点。
Hash倾斜：如果节点很少，容易出现倾斜，负载不均衡问题。一致性哈希算法，引入了虚拟节点，在整个环上，均衡增加若干个节点。
三、RabbitMQ集群
RabbitMQ 集群中节点包括内存节点(RAM)、磁盘节点(Disk，消息持久化)，集群中至少有 一个 Disk 节点。
普通模式(默认)
对于普通模式，集群中各节点有相同的队列结构，但消息只会存在于集群中的一个节点。对于消费者来说，若消息进入 A 节点的 Queue 中，当从 B 节点拉取时，RabbitMQ 会将消息从 A 中取出，并经过 B 发送给消费者。 应用场景：该模式各适合于消息无需持久化的场合，如日志队列。当队列非持久化，且 创建该队列的节点宕机，客户端才可以重连集群其他节点，并重新创建队列。若为持久化， 只能等故障节点恢复。
镜像模式
与普通模式不同之处是消息实体会主动在镜像节点间同步，而不是在取数据时临时拉取，高可用；该模式下，mirror queue 有一套选举算法，即 1 个 master、n 个 slaver，生产者、消费者的请求都会转至 master。
