一 Redis集群部署

在新浪微博、淘宝、京东等大型企业应用中，Redis集群规模可以达到几千个节点，下面介绍一下Redis集群的几种常用方案。

1 Master Slave Replication

使用一个Redis实例作为主机，其余的作为备份机。主机和备份机的数据完全一致，主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取。

由于主从数几乎是一致的，因而可以将写入数据的命令发送给主机执行，而读取数据的命令发送给不同的从机执行，从而达到读写分离的目的（如图7-45所示）。

Redis主从复制（Master-Slave Replication）的工作原理为：Slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。

而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master主节点继续将所有已经收集到的修改命令和新的修改命令依次传送给Slave，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。

2 哨兵模式

从Redis 2.8版本开始引入哨兵模式，它是在主从复制的基础上，用哨兵实现了自动化的故障恢复。通俗来说哨兵模式的出现就是为了解决主从复制模式中需要人为操作的东西，全部变为自动操作（如图7-46所示）。

· 监控（monitoring）：哨兵会不断检查主节点和从节点是否正常工作。

· 自动故障转移（automatic failover）：当主节点不能正常工作时，哨兵会执行自动故障转移操作，它会选择一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点中的数据。

· 配置提供者（configuration provider）：客户端在初始化时，通过连接哨兵来获取当前Redis服务的地址。

· 通知（notification）：哨兵可以将故障转移的结果发送给客户端。

3 Redis Cluster

Redis早期版本使用主从模式做集群，但是Master宕机后需要手动配置Slave转为Master。Redis 2.8版本开始引入哨兵模式，该模式下有一个哨兵监视Master和Slave，若Master宕机可自动将Slave转为Master。但哨兵模式也有一个问题，就是Redis节点不能动态扩充，所以从Redis 3.x提出了Cluster集群模式。

Redis Cluster为整个集群定义了一共16 384个哈希槽（slot），并通过crc16的hash函数来对key进行取模，将结果路由到预先分配过哈希槽的相应节点上（如图7-47所示）。

Redis Cluster自动将数据进行分片，每个Master上放一部分数据提供内置的高可用支持，部分Master不可用时，仍然可以继续工作。Redis Cluster架构下的每个服务器都要开放两个端口号，比如一个是6379，另一个就是加10000的端口号16379。6379端口号就是Redis服务器入口（客户端访问端口），16379端口号用来进行节点间通信。

Cluster Bus（集群总线）用来进行通知实例的IP地址、缓存分片的slot信息、新节点加入、故障检测、配置更新、故障转移授权等。Cluster Bus用的是一种叫Gossip协议的二进制协议，用于节点间高效的数据交换，占用更少的网络带宽和处理时间。

Gossip算法如其名，灵感来自办公室八卦，只要一个人八卦一下，在有限的时间内所有的人都会知道该八卦的信息，这种方式也与病毒传播类似，因此Gossip有众多的别名——“闲话算法”“八卦算法”“病毒感染算法”。

Gossip过程是由种子节点发起，当一个种子节点有状态需要更新到网络中的其他节点时，它会随机地选择周围几个节点散播消息，收到消息的节点也会重复该过程，直至最终网络中所有的节点都收到了消息。这个过程可能需要一定的时间，由于虽然不能保证某个时刻所有节点都收到消息，但是理论上最终所有节点都会收到消息，因此它是一个最终一致性协议。

Gossip协议的最大的好处是，即使集群节点的数量暴增，每个节点的负载也变化不大。这就允许Redis Cluster或者Consul集群管理的节点规模能横向扩展到数千个。Redis Cluster中的每个节点都维护一份自己视角下的当前整个集群的状态，主要包括如下状态。

·　集群中各节点所负责的哈希槽信息及其迁移状态。

·　集群中各节点的Master-Slave状态。

·　集群中各节点的存活状态及怀疑失败状态。Gossip主要消息类型如下。

· MEET：通过cluster meet ip port命令，已有集群的节点会向新的节点发送邀请，加入现有集群，然后新节点就会开始与其他节点进行通信。

· PING：节点按照配置的时间间隔向集群中其他节点发送PING消息，消息中带有自己的状态，还有自己维护的集群元数据和部分其他节点的元数据。

· PONG：节点用于回应PING和MEET的消息，结构和PING消息类似，也包含自己的状态和其他信息，也可以用于信息广播和更新。

· FAIL：节点PING不通某节点后，会向集群所有节点广播该节点挂掉的消息，其他节点收到消息后标记已下线。

二 MongoDB集群部署

MySQL处理数据的规模一般在千万级，而MongoDB在阿里云、58同城、滴滴出行等很多平台，都有了百亿级数据的成熟应用经验。

MongoDB典型的集群部署有主从集群模式、副本集模式和分片集群模式。

1 主从集群

主从集群模式一般采用一主多从方式部署，主（Master）用于接收数据写入，从（Slave）用于接收数据查询（如图7-48所示）。

在主从复制的集群中，当主节点出现故障时，只能人工介入，指定新的主节点，从节点不会自动升级为主节点。同时，在这段时间内，该集群架构只能处于只读状态。

MongoDB的主从模式应用较少，一般不推荐。MongoDB官方建议用副本集模式替代主从复制。

2 副本集

副本集（Replica Set）拥有一个主节点和多个从节点，这一点与主从复制模式类似，而且与主从节点所负责的工作也类似。副本集与主从复制的主要区别在于：当集群中主节点发生故障时，副本集可以自动投票，选举出新的主节点，并引导其余的从节点连接新的主节点，而且这个过程对应用是完全透明的（如图7-49所示）。

副本集提供了数据冗余存储，同时提高了集群可靠性。通过在不同的机器上保存副本来保证数据不会因为单点损坏而丢失；而且副本集能够随时应对数据丢失、机器损坏、网络异常等带来的风险，大大提高了集群的可靠性。

主服务器很重要，包含了所有的数据变更的日志。但是副本服务器集群包含所有的主服务器数据，因此当主服务器挂掉了，就会在副本服务器上重新选取一个成为主服务器。

1．副本集节点角色

MongoDB的复制至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。MongoDB各个节点常见的搭配方式为：一主一从、一主多从。主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。

MongoDB副本集中的节点，分为如下几种角色。

· 主节点（Primary）：接收所有的写请求，然后把修改同步到所有Secondary。一个副本集只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。

默认读请求也是发到Primary节点处理的，可以通过修改客户端连接配置以支持读取Secondary节点。

· 副本节点（Secondary）：与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。

· 仲裁者（Arbiter）：不保有数据，不参与选主，只进行选主投票。

使用Arbiter可以降低数据存储的硬件需求，Arbiter几乎没什么大的硬件资源需求，但需要注意一点，在生产环境下它和其他数据节点不应部署在同一台机器上。

2．副本集架构模式

副本集可以采用两种架构模式，分别为PSS架构（如图7-50所示）和PSA架构（如图7-51所示）。在PSS（Primary + Secondary + Secondary）模式下，副本集的节点总数应该为奇数，目的是选主（Primary）投票的时候要出现大多数才能执行选举决策。PSA（Primary + Secondary + Arbiter）模式需要一个裁判节点，这个节点不参与选举，也不从Primary同步数据。在PSA模式下，要求数据节点的数量为偶数。

3 分片集群

MongoDB副本集模式可以在主节点发生故障后，通过自动选举机制，让某个从节点自动升级为主，从而提高了集群的可用性。

但是如果业务系统需要处理海量数据，那么数据节点就会需要几百台甚至几千台，副本集模式中一个Primary根本没法应付大量的高并发数据写入（数据吞吐量不足），Primary成为系统的性能瓶颈和安全隐患。

这时，就需要用到MongoDB的分片（Sharding）技术了，这也是MongoDB的大集群部署模式（如图7-52所示）。

1．分片集的角色

如图7-52所示，构建一个MongoDB的分片集群，需要三个重要的组件，分别是分片服务器（Shard Server）、配置服务器（Config Server）和路由服务器（Route Server）。

· Route Server：这是一个独立的Mongos进程，Mongos是数据库集群请求的入口，所有的请求都通过Mongos进行协调，不需要再添加额外的路由选择器，Mongos自己就是一个请求分发中心，它负责把对应的数据请求转发到对应的分片服务器上。

在生产环境通常有多Mongos作为请求的入口，防止其中一个挂掉所有的Mongos请求都没有办法操作。Mongos服务器本身不保存数据，启动时从ConfigServer加载集群信息到缓存中，并将客户端的请求路由给每个ShardServer，在各Shard Server返回结果后进行聚合并返回客户端。

· Shard Server：分片（Sharding）是指将数据库拆分，将其分散在不同的机器上的过程。将数据分散到不同的机器上，不需要功能强大的服务器就可以存储更多的数据和处理更大的负载。基本思想就是将集合切成小块，这些块分散到若干片里，每个片只负责总数据的一部分，最后通过一个均衡器来对各个分片进行均衡。

每个ShardServer都是一个MongoDB数据库实例，用于存储实际的数据块。整个数据库集合分成多个块存储在不同的Shard Server中。

在实际生产中，一个Shard Server可由几台机器组成一个副本集来承担，防止因主节点单点故障导致整个系统崩溃（如图7-53所示）。

· Config Server：配置服务器存储所有数据库元信息（路由、分片）的配置。Mongos本身没有物理存储分片服务器和数据路由信息，只是缓存在内存里，配置服务器则实际存储这些数据。

Mongos第一次启动或者关掉重启就会从Config Server加载配置信息，以后如果配置服务器信息变化会通知到所有的Mongos更新自己的状态，这样Mongos就能继续准确路由。在实际生产中通常有多个Config Server配置服务器，因为它存储了分片路由的元数据，可以防止数据丢失。

2．如何分片

集合分片是为应对高吞吐量与大数据量提供的解决思路。使用分片减少了每个分片需要处理的请求数（并发压力减少）。通过水平扩展，集群还可以提高自己的存储容量和数据吞吐量。

例如，如果数据库有1TB的数据集，并有4个分片，则每个分片可能仅持有256GB的数据（如图7-54所示）。如果有40个分片，那么每个切分可能只有约25GB的数据。

将MongoDB的分片和复制功能结合使用，在确保数据分片到多台服务器的同时，也确保了每份数据都有相应的备份，这样就可以确保某台服务器宕掉时，其他的从库可以立即接替坏掉的部分继续工作。

在一个Shard Server内部，MongoDB还是会把数据分为chunk（块），每个chunk代表这个Shard Server内部的一部分数据。chunk的产生，会有以下两个用途。

· Splitting（分裂）：当一个chunk的大小超过配置中的chunk size（默认为64MB）时，MongoDB的后台进程会把这个chunk切分成更小的chunk，从而避免chunk过大的情况（如图7-55所示）。

· Balancing（平衡）：在MongoDB中，balancer是一个后台进程，负责chunk的迁移，从而均衡各个Shard Server的负载。chunk size默认为64MB，在生产库上选择适合业务的chunk size是最好的（如128MB或256MB）。MongoDB会自动拆分和迁移chunk（如图7-56所示）。