集群专题

十二、集群专题

0.项目仓库

https://github.com/gongluck/CVIP.git

1.Redis集群

1.1 主从复制

主从模式的一个作用是备份数据，这样当一个节点损坏时，数据因为有备份，可以方便恢复。另一个作用是负载均衡，所有客户端都访问一个节点肯定会影响Redis工作效率，有了主从以后，查询操作就可以通过查询从节点来完成。
默认配置下，master节点可以进行读和写，slave节点只能进行读操作，写操作被禁止。
不要修改配置让slave节点支持写操作，没有意义，原因一，写入的数据不会被同步到其他节点；原因二，当master节点修改同一条数据后，slave节点的数据会被覆盖掉。
slave节点挂了不影响其他slave节点的读和master节点的读和写，重新启动后会将数据从master节点同步过来。master节点挂了以后，不影响slave节点的读，Redis将不再提供写服务，master节点启动后Redis将重新对外提供写服务。master节点挂了以后，slave节点重新不会选一个master。

1.2 Sentinel模式

Sentinel的主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换。由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
Redis的Sentinel最小配置是一主一从。Redis的Sentinel系统可以用来管理多个Redis服务器，该系统可以执行以下四个任务：
- 监控
  - Sentinel会不断的检查主服务器和从服务器是否正常运行。
- 通知
  - 当被监控的某个Redis服务器出现问题，Sentinel通过API脚本向管理员或者其他的应用程序发送通知。
- 自动故障转移
  - 当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点。
- 配置提供者
  - 在Redis Sentinel模式下，客户端应用在初始化时连接的是 Sentinel节点集合，从中获取主节点的信息。

1.3 Cluster模式

redis cluster是 Redis的分布式解决方案，在3.0版本推出后有效地解决了redis分布式方面的需求。自动将数据进行分片，每个master上放一部分数据。提供内置的高可用支持，部分master不可用时，还是可以继续工作的支撑N个redis master node，每个master node都可以挂载多个slave node高可用，因为每个master都有salve节点，那么如果mater挂掉，redis cluster这套机制，就会自动将某个slave切换成master。

2.去中心化技术

2.1 去中心化网络

去中心化网络

2.2 网络地址映射

服务器发送数据与路由器公网IP时，能够将数据映射到私网中的机器；私网内的机器发送数据给服务器，路由器也能够映射为公网IP地址的过程，成为网络地址映射。

3.Docker

3.1 镜像、容器、仓库

Docker镜像（Image），就相当于是一个root文件系统。比如官方镜像ubuntu:16.04就包含了完整的一套Ubuntu16.04最小系统的root文件系统。
容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
仓库可看着一个代码控制中心，用来保存镜像。Docker使用客户端-服务器(C/S)架构模式，使用远程API来管理和创建Docker容器。 Docker容器通过Docker镜像来创建。

3.2 Docker安装

sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
curl -fsSL https://mirrors.ustc.edu.cn/docker-ce/linux/ubuntu/gpg | sudo apt-key add -
sudo apt-key fingerprint 0EBFCD88
sudo add-apt-repository "deb [arch=amd64] https://mirrors.ustc.edu.cn/docker-ce/linux/ubuntu/ $(lsb_release -cs)  stable"

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

3.3 Docker命令

# 启动docker
sudo service docker start
# 停止docker
sudo service docker stop
# 重启docker
sudo service docker restart

4.MySQL集群

4.1 Replication

主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令，那么在从库同样的执行一遍，从而达到主从复制的效果。
在这个过程中，master对数据的写操作记入二进制日志文件中(binlog)，生成一个log dump线程，用来给从库的i/o线程传binlog。而从库的i/o线程去请求主库的binlog，并将得到的binlog日志写到中继日志（relaylog）中，从库的sql线程，会读取relaylog文件中的日志，并解析成具体操作，通过主从的操作一致，而达到最终数据一致。

4.2 Fabirc

在MySQL Replication的基础上，增加了故障检测与转移，自动数据分片功能。
依旧是一主多从的结构，MySQL Fabirc只有一个主节点，区别是当该主节点挂了以后，会从从节点中选择一个来当主节点。

4.3 Cluster

MySQL Cluster是多主多从结构的，高可用性优秀，99.999%的可用性，可以自动切分数据，能跨节点冗余数据（其数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能被分散在多个物理节点上，任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步，以保证数据的一致性）。

5.Kubernetes

5.1 K8s简介

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制。
传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。
通过部署容器方式，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

5.2 K8s集群

K8s集群

6.MongoDB集群

6.1 Master-Slave

mongodb主从集群

主机工作，备机处于监控准备状况；
当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。
主(Master)可读可写，当数据有修改的时候，会将oplog同步到所有连接的salve上去。
从(Slave)只读不可写，自动从Master同步数据。

6.2 Replica Set

mongodb副本集集群

为了防止单点故障就需要用副本（Replication），当发生硬件故障或者其它原因造成的宕机时，可以使用副本进行恢复，最好能够自动的故障转移（failover）。有时引入副本是为了读写分离，将读的请求分流到副本上，减轻主（Primary）的读压力。而Mongodb的Replica Set都能满足这些要求。
Replica Set的一堆mongod的实例集合，它们有着同样的数据内容。包含三类角色：
- 主节点（Primary）
  - 接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。
  - 默认读请求也是发到Primary节点处理的，需要转发到Secondary需要客户端修改一下连接配置。
- 副本节点（Secondary）
  - 与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。
- 仲裁者（Arbiter）
  - 不保有数据，不参与选主，只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求，Arbiter跑起来几乎没什么大的硬件资源需求，但重要的一点是，在生产环境下它和其他数据节点不要部署在同一台机器上。
一个自动failover的Replica Set节点数必须为奇数，目的是选主投票的时候要有一个大多数才能进行选主决策。

6.3 Sharding

mongodb分片集群

当数据量比较大的时候，我们需要把数据分片运行在不同的机器中，以降低CPU、内存和IO的压力，Sharding就是这样的技术。
数据库主要由两种方式做Sharding：纵向，横向，纵向的方式就是添加更多的CPU，内存，磁盘空间等。横向就是上面说的方式。
数据分片（Shards）
- 保存数据，保证数据的高可用性和一致性。可以是一个单独的mongod实例，也可以是一个副本集。
- 在生产环境下Shard是一个Replica Set，以防止该数据片的单点故障。所有Shard中有一个PrimaryShard，里面包含未进行划分的数据集合。
查询路由（Query Routers）
- mongos的实例，客户端直接连接mongos，由mongos把读写请求路由到指定的Shard上去。
- 一个Sharding集群，可以有一个mongos，也可以有多mongos以减轻客户端请求的压力。
配置服务器（Config servers）
- 保存集群的元数据（metadata），包含各个Shard的路由规则。

Last modified on 2020-12-28