首页

实践过程可分为两个模块，首先学习了大数据平台高可用理论的知识，

# 一、大数据平台高可用有什么用

服务的可用性是指任何时候、任何地点、任何环境用户都能够获得他所需要的服务的比率。

实现方法：冗余，自动故障转移，系统隔离

业务连续性 ，数据一致性 ，故障恢复 ， 资源利用率 ，用户体验

# 二、大数据平台高可用技术模块

# 2.1、高可用基础理论

# 2.1.1、可用性和故障恢复指标

  • 可用性：N 个 9

img

  • rpo：业务系统允许的灾难过程最大数据丢失量
  • rto：信息系统由灾难状态恢复到可用状态需要的时间

# 2.1.2、基础技术

# 2.1.2.1、BASE

BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

BASE 是基本可用 (Basically Available)、软状态 (Soft State) 和最终一致性 ( Eventually Consistent) 三个短语的缩写。

  • 基本可用（Basically Available）：系统在出现故障或异常情况时仍能保持基本的可用性，即尽管可能会出现性能下降或功能受限，但仍然可以继续提供服务。
  • 软状态（Soft State）：系统中的状态可以根据某些条件进行变化，而不需要依赖全局一致性，例如，延迟同步或异步复制等方式来保证数据的一致性。
  • 最终一致性（Eventual Consistency）：系统中的副本最终会达到一致的状态，但在一段时间内可能存在不一致的状态。在分布式系统中，由于网络延迟、故障恢复等原因，无法保证即时的数据一致性，而是通过后续的修复或同步操作来最终达到一致性。

# 2.1.2.2、CAP

一个分布式系统，不可能同时做到这三点。

  • Consistency : Every read receives the most recent write or an error
  • Availability : Every request receives a (non-error) response – without the guarantee that it contains the most recent write
  • Partition tolerance : The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

这三个性质对应了分布式系统的三个指标：一致性，可用性，分区容忍性

# 应用范例：

在分布式的环境下，网络无法做到 100% 可靠，有可能出现故障，因此分区是一个必须的选项，如果选择了 CA 而放弃了 P，若发生分区现象，为了保证 C，系统需要禁止写入，此时就与 A 发生冲突，如果是为了保证 A，则会出现正常的分区可以写入数据，有故障的分区不能写入数据，则与 C 就冲突了。因此分布式系统理论上不可能选择 CA 架构，而必须选择 CP 或 AP 架构。

zookeeper 保证 CP：

任何时刻对 zookeeper 的访问请求能得到一致性的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务的可用性。从实际情况来分析，在使用 zookeeper 获取服务列表时，如果 zk 正在选举或者 zk 集群中半数以上的机器不可用，那么将无法获取数据。所以说，zk 不能保证服务可用性。

eureka 保证 AP：

eureka 在设计时优先保证可用性，每一个节点都是平等的，一部分节点挂掉不会影响到正常节点的工作，不会出现类似 zk 的选举 leader 的过程，客户端发现向某个节点注册或连接失败，会自动切换到其他的节点，只要有一台 eureka 存在，就可以保证整个服务处在可用状态，只不过有可能这个服务上的信息并不是最新的信息。

# 2.1.2.3、2PC/3PC

使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的算法。

# 2PC：二阶提交协议
  1. prepare - ok (undo/redo)

2.commit - ok

- err

  1. rollback - ok

在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的 ACID 特性，需要引入一个作为协调者的组件来统一掌控所有节点 (称作参与者) 的操作结果并最终指示这些节点是否要把操作结果进行真正的提交 (比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

  1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交。 （Undo 日志是记录修改前的数据，用于数据库回滚，Redo 日志是记录修改后的数据，用于提交事务后写入数 据文件）
  2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚 (Rollback) 消息；否则，发送提交 (Commit) 消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放锁资源。
# 3PC：三阶提交协议
  • 第一阶段：CanCommit
  • 第二阶段：PreCommit
  • 第三阶段：Do Commit

2pc 中，协调者和唯一接收指令的参与者都出现不可恢复宕机时，即使后面选举了新的协调者，仍然可能出现数据的不一致性。

相比 2pc ：

  • 将准备阶段一分为二，解决了 error 时需要将已完成任务的参与者 rollback 的资源浪费
  • 引入超时策略，precommit 超时，参与者继续之前的任务， cancommit 超时，参与者默认提交。协调者等待反馈超时，默认 abort 或 rollback

# 2.1.2.4、Paxos/Raft

不考虑拜占庭将军问题

# Paxos

维基百科 - 算法与证明

解决了分布式系统各个节点一致性的问题

通过一个决议分为两个阶段：

  1. prepare 阶段：

    1. proposer 选择一个提案编号 n 并将 prepare 请求发送给 acceptors 中的一个多数派；
    2. acceptor 收到 prepare 消息后，如果提案的编号大于它已经回复的所有 prepare 消息 (回复消息表示接受 accept)，则 acceptor 将自己上次接受的提案回复给 proposer，并承诺不再回复小于 n 的提案；

  3. 批准阶段：

    1. 当一个 proposer 收到了多数 acceptors 对 prepare 的回复后，就进入批准阶段。它要向回复 prepare 请求的 acceptors 发送 accept 请求，包括编号 n 和根据 P2c 决定的 value（如果根据 P2c 没有已经接受的 value，那么它可以自由决定 value）。
    2. 在不违背自己向其他 proposer 的承诺的前提下，acceptor 收到 accept 请求后即批准这个请求。

这个过程在任何时候中断都可以保证正确性。例如如果一个 proposer 发现已经有其他 proposers 提出了编号更高的提案，则有必要中断这个过程。因此为了优化，在上述 prepare 过程中，如果一个 acceptor 发现存在一个更高编号的提案，则需要通知 proposer，提醒其中断这次提案。

# Raft

用于替代 Paxos 的共识算法

Raft 透过选举领袖（英语：leader）的方式做共识算法。

在 Raft 集群（英语：Raft cluster）里，服务器可能会是这三种身份其中一个：领袖（英语：leader）、追随者（英语：follower），或是候选人（英语：candidate）。在正常情况下只会有一个领袖，其他都是追随者。而领袖会负责所有外部的请求，如果不是领袖的机器收到时，请求会被导到领袖。

通常领袖会借由固定时间发送消息，也就是 “心跳（英语：heartbeat）”，让追随者知道集群的领袖还在运作。而每个追随者都会设计超时机制（英语：timeout），当超过一定时间没有收到心跳（通常是 150 ms 或 300 ms），集群就会进入选举状态。

算法步骤：

  • 领袖选举（英语：Leader Election）
  • 记录复写（英语：Log Replication）
  • 安全性（英语：Safety）

# 2.1.2.5、Quorum/Gossip

Quorum 机制基于鸽笼原理，保证数据冗余和最终一致性。通常指在分布式系统中最小节点数或最小投票数。

Gossip 是分布式系统中的一种通信协议，用于在节点之间传播信息和状态，实现节点之间的信息同步和状态一致性。可以类比六度空间理论。具体实现方式为：随机选取节点，共享任何信息。

# 2.2、云原生平台高可用

# 2.2.1、集群管理

# 节点：

Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。 节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pod 所需的服务； 这些节点由控制面负责管理。

通常集群中会有若干个节点；而在一个学习所用或者资源受限的环境中，你的集群中也可能只有一个节点。

节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

# 资源分配：

通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。

  • 不同的团队可以在不同的命名空间下工作。这可以通过 RBAC 强制执行。
  • 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
  • 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况， 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
  • 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。
  • 如果命名空间下的计算资源 （如 cpu 和 memory）的配额被启用， 则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示：可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

# 2.2.2、弹性伸缩

（Horizontal Pod Autoscaling）HPA 是一种基于 CPU 利用率、内存使用量等指标来自动调整 Pod 数量的机制。当负载增加时，HPA 可以根据预定义的规则自动增加 Pod 的副本数，以提供更多的处理能力。当负载减少时，HPA 会相应地减少 Pod 的副本数，以释放资源。这与 “垂直（Vertical）” 扩缩不同，垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。

# 2.2.3、负载均衡

  • Service：直接用 Service 提供 cluster 内部的负载均衡，并借助 cloud provider 提供的 LB 提供外部访问
  • Ingress Controller：还是用 Service 提供 cluster 内部的负载均衡，但是通过自定义 LB 提供外部访问
  • Service Load Balancer：把 load balancer 直接跑在容器中，实现 Bare Metal 的 Service Load Balancer
  • Custom Load Balancer：自定义负载均衡，并替代 kube-proxy，一般在物理部署 Kubernetes 时使用，方便接入公司已有的外部服务

# 2.2.4、容器健康检查

通过存活（Liveness）、就绪（Readiness）和启动（Startup）探针检测

  • 使用存活探针来确定什么时候要重启容器。常见模式是为就绪探针使用相同的低成本 HTTP 端点，但具有更高的 failureThreshold。 这样可以确保在硬性终止 Pod 之前，将观察到 Pod 在一段时间内处于非就绪状态。

错误的存活探针可能会导致级联故障。 这会导致在高负载下容器重启；例如由于应用无法扩展，导致客户端请求失败；以及由于某些 Pod 失败而导致剩余 Pod 的工作负载增加。了解就绪探针和存活探针之间的区别， 以及何时为应用配置使用它们非常重要。

  • 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
  • 使用启动探针来了解应用容器何时启动。 如果配置了这类探针，存活探针和就绪探针成功之前不会重启，确保这些探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。

# 2.2.5、故障检测和自动恢复

在分布式系统中，检测硬件故障通常比较麻烦，因此会通过查看软件层的表现结果来进行故障检测，常见的故障检测方法是心跳机制。

对于单节点故障问题，往往采取主备策略，即当主节点故障后，从备节点中选出一个作为新的主节点，以继续提供服务。例如 Raft 算法。

对于网络故障问题的解决方案，简单来说就是 C、A、P 选择的问题，即在分布式系统的可用性和数据一致性之间做权衡。根据不同的应用场景，选择不同的解决方案。

# 2.2.6、数据备份和恢复

Kubernetes 本身并不提供完整的数据备份和恢复解决方案，而是提供了一些基础设施和机制来支持备份和恢复操作。

k8s 集群服务所有组件都是无状态服务，所有数据都存储在 etcd 集群当中，所以为保证 k8s 集群的安全可以直接备份 etcd 集群数据，备份 etcd 的数据相当于直接备份 k8s 整个集群。

一般通过软件进行备份和恢复， Velero 是很好的选择

# 2.2.7、滚动升级

滚动更新允许允许通过使用新的实例逐步更新 Pod 实例，零停机进行 Deployment 更新。新的 Pod 将在具有可用资源的节点上进行调度。

  • 将应用程序从一个环境提升到另一个环境（通过容器镜像更新）
  • 回滚到以前的版本
  • 持续集成和持续交付应用程序，无需停机

# 2.2.8、监控与日志

# 监控

需要考虑监控指标的选择、监控频率和告警策略等因素。

应用程序监控：通过监控应用程序的运行状态、资源利用率和性能指标等，可以及时发现和解决问题。

系统监控：通过监控系统的运行状态、资源利用率和性能指标等，可以及时发现和解决问题。

网络监控：通过监控网络的运行状态、带宽利用率和延迟等指标，可以及时发现和解决网络问题。

# 日志

需要考虑日志格式、日志级别和日志存储等因素。

应用程序日志：通过记录应用程序的日志，可以帮助用户了解应用程序的运行情况和问题。

系统日志：通过记录系统的日志，可以帮助用户了解系统的运行情况和问题。

安全日志：通过记录安全事件的日志，可以帮助用户了解系统的安全情况和问题。

# 2.3、大数据平台高可用

# 2.3.1. 分布式存储

数据被分散存储在多个独立的存储服务器上，这些分散的数据存储服务器构成了一个虚拟的存储系统。分布式存储使用的负载均衡技术可以有效避免系统中可能出现的数据存储不均衡问题。分布式存储系统可将底层存储设备的资源整合，在性能允许的情况下，将饱和设备中的数据划分到其他底层存储设备上，从而实现分布式存储的负载均衡。

  • 数据更新在集中式存储中管理和更新数据更为容易，因为它只涉及一个数据库。但在分布式存储中，由于涉及到多个数据库，管理和更新数据也就需要花费更多时间。
  • 数据访问在用户数量相同的情况下，集中式存储可能需要更多时间来访问系统获取数据，但分布式存储不需要太多时间，因为文件可直接从距离最近的数据库中检索查阅。
  • 数据库故障集中式存储中的数据库如果发生故障会影响到所有的用户。但是分布式存储的数据库发生故障不会造成大规模影响，因为它是由多个独立存储设备合成的数据库系统，除去发生故障的数据库，其他的数据库仍然可以正常访问。
  • 数据一致性集中式存储为用户提供了单一完整的数据视图，而分布式存储可能由于不同数据库间的数据复制错误而产生数据的差异变化，这就造成了数据的不一致。

# 2.3.2. 分布式计算

一组电脑，透过网路相互连接传递讯息与通讯后并协调它们的行为而形成的系统，组件之间彼此进行交互以实现一个共同的目标。把需要进行大量计算的工程数据分割成小块，由多台计算机分别计算，再上传运算结果后，将结果统一合并得出数据结论的科学。分布式系统的例子来自有所不同的面向服务的架构，大型多人线上游戏，对等网络应用。

在分布式计算中，有几个关键的概念和组件：

  1. 计算节点（Compute Nodes）：计算节点是指参与分布式计算的物理或虚拟计算机，它们负责执行分配给它们的计算任务。
  2. 任务调度（Task Scheduling）：任务调度是将计算任务分配给计算节点的过程。任务调度器负责根据任务的特性和计算节点的可用性，将任务分配给最合适的计算节点。
  3. 数据分发（Data Distribution）：在分布式计算中，数据通常需要在计算节点之间进行传输和共享。数据分发机制负责将数据分发到计算节点，以便节点可以访问和使用所需的数据。
  4. 任务协调（Task Coordination）：分布式计算中的任务通常需要相互协作和共享结果。任务协调器负责管理任务之间的依赖关系、协调任务的执行顺序，并收集和整合计算结果。
  5. 容错性（Fault Tolerance）：分布式计算系统需要具备容错性，即在计算节点故障或网络中断等情况下，能够自动恢复计算任务并保证计算的正确性和完整性。

常见的分布式计算框架和平台包括：

  1. Apache Hadoop：Hadoop 是一个开源的分布式计算框架，它提供了分布式文件系统（HDFS）和分布式计算模型（MapReduce）来处理大规模数据集的计算任务。
  2. Apache Spark：Spark 是一个快速、通用的分布式计算引擎，它支持内存计算和迭代计算，并提供了丰富的 API 和库，用于处理大规模数据集和复杂的计算任务。
  3. Apache Flink：Flink 是一个流式处理和批处理的分布式计算框架，它提供了高吞吐量和低延迟的数据处理能力，并支持事件时间处理和状态管理。
  4. Apache Storm：Storm 是一个分布式实时计算系统，它用于处理实时数据流，并提供可扩展性和容错性。

# 2.3.3. 数据管理与调度

数据冗余和备份：数据会被复制到多个节点或存储设备上，以防止单点故障导致数据不可用。通过数据冗余和备份，即使某个节点或存储设备发生故障，数据仍然可以从其他副本中恢复。

故障检测和自动恢复：大数据平台需要实时监测各个组件的状态，并及时检测到故障。一旦发现故障，系统应该能够自动进行故障恢复，例如重新启动故障节点、重新分配任务、重新复制数据等。这样可以减少故障对数据管理和调度的影响，并提高系统的可用性。

资源调度和负载均衡：在大数据平台中，数据管理和调度需要合理地分配计算资源和存储资源，以满足不同任务的需求。资源调度器负责根据任务的优先级、资源需求和可用资源的情况，将任务分配给最合适的计算节点。同时，负载均衡机制可以确保各个节点的负载均衡，避免资源过度集中或过度分散，从而提高系统的整体性能和可用性。

数据一致性和同步：在大数据平台中，数据管理和调度需要确保数据的一致性和同步。当数据发生变化时，系统应该能够及时将这些变化同步到所有副本中，以保证数据的一致性。同时，对于分布式计算任务，系统需要确保任务的执行顺序和结果的正确性，避免数据处理过程中的竞争条件和数据不一致的问题。

监控和报警：为了及时发现和解决数据管理和调度中的问题，大数据平台需要建立完善的监控和报警系统。监控系统可以实时监测各个组件的状态和性能指标，并生成相应的报警信息。当系统出现异常或故障时，报警系统可以及时通知管理员或运维人员，以便他们能够快速采取措施进行故障排查和修复。

# 2.3.4. 数据采集与传输

# 数据采集：

  • 设计可靠的数据采集策略，包括确定数据源、采集频率和数据格式等。
  • 使用适当的采集工具或技术，例如使用 Apache Kafka、Flume、Logstash 等。
  • 考虑数据采集的并行性和分布式处理，以提高采集效率和容错性。
  • 实施数据质量控制，包括数据验证、清洗和转换等，以确保采集到的数据准确可用。

# 数据传输：

  • 选择合适的传输协议和技术，例如使用 HTTP、HTTPS、MQTT、Kafka 等。
  • 实现数据传输的容错和重试机制，以应对网络故障或传输错误。
  • 考虑数据传输的安全性，例如使用加密和身份验证等机制保护数据传输过程。
  • 监控数据传输状态，包括传输成功率、传输延迟和吞吐量等指标，以及实时报警和故障排查。

# 2.3.5. 数据处理与分析

# 数据处理：

  • 设计可扩展和可并行的数据处理架构，例如使用分布式计算框架如 Apache Hadoop、Apache Spark 等。
  • 利用数据分区和分片技术，将数据分布在多个节点上进行并行处理，以提高处理效率和容错性。
  • 考虑数据压缩和编码技术，以减少存储和传输成本，并提高处理速度。
  • 实施数据清洗、转换和聚合等预处理步骤，以确保数据的准确性和一致性。

# 数据分析：

  • 选择适当的数据分析工具和技术，例如使用 SQL 查询、机器学习算法、图分析等。
  • 设计有效的数据模型和数据结构，以支持快速和高效的数据分析操作。
  • 考虑实时数据分析和流式处理，以及批处理和交互式查询等不同的分析需求。
  • 实施数据可视化和报告功能，以便用户能够理解和利用分析结果。

# 2.3.6. 数据可视化与报表

  1. 确定需求和目标：
    • 理解用户的需求和目标，确定需要呈现的关键指标和信息。
    • 确定可视化和报表的用途，是用于实时监控、决策支持还是业务报告等。
  1. 选择合适的可视化工具和技术：
    • 考虑使用流行的数据可视化工具，如 Tableau、Power BI、D3.js 等，根据需求选择适合的工具。
    • 了解不同的可视化类型，如柱状图、折线图、饼图、热力图、地图等，选择适合展示数据的图表类型。
  1. 设计清晰和易懂的可视化界面：
    • 简化和优化可视化界面，确保信息传达清晰、易于理解。
    • 使用合适的颜色、标签和图例，以区分不同的数据类别和趋势。
    • 考虑交互性，例如添加过滤器、下钻和悬停等功能，以便用户进行更深入的数据探索和分析。
  1. 报表设计和布局：
    • 确定报表的结构和布局，包括标题、副标题、图表、表格、说明文本等元素的排列和组织方式。
    • 使用合适的数据展示方式，例如使用趋势图展示时间序列数据，使用地图展示地理数据等。
    • 考虑报表的可打印性和导出性，以便用户能够将报表输出为 PDF、Excel 等格式。
  1. 实时和自动化更新：
    • 如果需要实时监控和数据更新，确保可视化界面和报表能够及时反映最新的数据。
    • 考虑自动化数据抓取和更新机制，以减少人工干预和提高效率。
  1. 用户培训和反馈：
    • 为用户提供培训和指导，帮助他们理解和使用可视化界面和报表。
    • 收集用户反馈和需求，不断改进和优化可视化界面和报表的设计。

# 2.3.7. 数据安全与权限管理

  1. 访问控制和身份验证：
    • 实施严格的访问控制机制，限制对数据和系统资源的访问权限。
    • 使用身份验证技术，例如用户名和密码、单一登录（SSO）、双因素认证等，确保只有授权用户可以访问数据。
  1. 角色和权限管理：
    • 设计和实施角色和权限模型，将用户分配到不同的角色，并为每个角色分配相应的权限。
    • 根据用户的职责和需求，分配适当的权限，以限制用户对数据的访问和操作。
  1. 数据加密：
    • 对敏感数据进行加密，保护数据在传输和存储过程中的安全性。
    • 使用加密算法和密钥管理系统，确保只有授权的用户能够解密和访问加密数据。
  1. 审计和日志管理：
    • 记录用户的操作日志和系统事件，以便跟踪和审计数据的访问和操作情况。
    • 定期审查和分析日志数据，发现异常行为和安全事件，并及时采取措施进行响应和调查。
  1. 数据脱敏和匿名化：
    • 对敏感数据进行脱敏处理，以保护用户隐私和敏感信息。
    • 实施数据匿名化技术，将个人身份信息等敏感数据转化为不可识别或无法关联的形式。
  1. 安全审计和漏洞管理：
    • 定期进行安全审计和漏洞扫描，发现和修补系统和应用程序中的安全漏洞。
    • 及时应用安全补丁和更新，以防止已知的安全漏洞被利用。
  1. 命名实体识别和数据分类：
    • 识别和分类敏感数据中的命名实体，例如姓名、地址、信用卡号等。
    • 采用数据分类和标记技术，对数据进行分类和分级，以便更好地管理和保护敏感数据。
  1. 员工培训和意识提升：
    • 为员工提供安全培训和意识提升，教育他们关于数据安全的最佳实践和风险防范措施。
    • 强调数据保密和合规要求，提醒员工保持警惕并遵守安全政策和规定。

# 2.3.8. 故障检测与自动恢复

  1. 监控和告警系统：
    • 部署监控系统来实时监测大数据平台的各个组件和关键指标，包括集群状态、资源利用率、作业运行情况等。
    • 配置告警规则，当监测指标超出预设的阈值时，触发告警通知，以便及时采取措施。
  1. 心跳检测和自动故障切换：
    • 在集群中的各个节点之间设置心跳检测机制，用于检测节点的存活状态。
    • 当节点出现故障或不可用时，自动将任务或数据迁移到其他可用节点上，实现自动故障切换。
  1. 任务监控和自动重启：
    • 监控作业的运行状态和进度，及时检测到作业失败或异常情况。
    • 自动重启失败的作业或任务，以确保任务能够继续执行。
  1. 数据备份和恢复：
    • 定期进行数据备份，并将备份数据存储在可靠的位置，以防止数据丢失。
    • 在发生故障时，自动从备份中恢复数据，以保证数据的完整性和可用性。
  1. 自动扩容和负载均衡：
    • 监控集群的负载情况，当负载过高时，自动进行集群的扩容，增加计算和存储资源。
    • 实施负载均衡机制，将任务和数据均匀地分配到可用的节点上，以避免出现单点故障和资源瓶颈。
  1. 日志分析和故障诊断：
    • 收集和分析集群和组件的日志数据，以便及时发现故障和异常情况。
    • 利用日志分析技术，进行故障诊断和根因分析，快速定位和解决问题。
  1. 容错和冗余设计：
    • 在架构设计中考虑容错和冗余机制，例如使用冗余节点、数据备份和复制等。
    • 采用分布式存储和计算框架，确保即使部分节点故障，系统仍能保持可用性和稳定性。

# 2.3.9. 数据备份与恢复

  1. 定期备份：
    • 设计并执行定期的数据备份计划，根据数据的重要性和变化频率确定备份的时间间隔。
    • 确保备份过程自动化和可靠，包括数据的全量备份和增量备份。
  1. 分布式备份：
    • 在大数据平台中使用分布式备份技术，将数据备份到多个物理位置或存储介质上，提高数据的容灾能力和可用性，以防止单点故障和数据丢失。
  1. 冗余存储：
    • 使用冗余存储技术，将数据复制到多个存储设备或节点上，以实现数据的冗余和容错。
    • 当一个存储设备或节点发生故障时，可以从其他冗余副本中恢复数据。
  1. 异地备份：
    • 将数据备份到异地的存储设备或数据中心，以防止地域性灾难（如火灾、地震等）对数据造成的影响。
    • 异地备份可以确保数据的安全性和可恢复性，即使一个地区发生故障，数据仍然可用。
  1. 恢复测试：
    • 定期进行数据恢复测试，验证备份的完整性和可恢复性。
    • 恢复测试可以帮助发现备份和恢复过程中的潜在问题，并及时进行修复和改进。
  1. 数据版本控制：
    • 保留多个数据版本，以便在需要时可以恢复到特定的时间点或状态。
    • 数据版本控制可以帮助应对数据错误、损坏或误操作等问题。
  1. 日志备份和恢复：
    • 对系统和应用程序的日志数据进行备份，以便在故障发生时进行故障排查和恢复。
    • 日志备份可以提供有关故障原因和恢复过程的重要信息。
  1. 自动化备份和恢复：
    • 实施自动化的备份和恢复流程，减少人工干预和错误的可能性。
    • 使用自动化工具和脚本，简化备份和恢复操作，并确保数据的一致性和完整性。

# 2.3.10. 监控与性能调优

  1. 系统监控：
    • 监控集群的整体运行状态，包括资源利用率、负载情况、任务运行状态等。
    • 使用监控工具和仪表盘，实时监测系统指标，并设置警报机制，及时发现和解决问题。
  1. 资源管理和调度：
    • 使用资源管理和调度工具，如 YARN、Mesos 等，对集群资源进行有效管理和分配。
    • 根据任务的需求和优先级，合理分配资源，提高系统的资源利用率和任务执行效率。
  1. 数据分区和分片：
    • 对大数据进行合理的分区和分片，以便并行处理和查询。
    • 根据数据的特征和访问模式，选择合适的分区策略，提高查询性能和数据加载速度。
  1. 数据压缩和编码：
    • 使用数据压缩和编码技术，减小数据的存储空间和传输开销。
    • 选择适合的压缩算法和编码方式，平衡存储和计算的性能开销。
  1. 数据倾斜处理：
    • 监测和处理数据倾斜问题，即某些数据分片或分区的负载不均衡导致任务执行效率低下。
    • 使用数据重分布、数据采样、调整任务并行度等技术，解决数据倾斜问题，提高任务的平衡性和效率。
  1. 索引和优化：
    • 在适当的情况下，为关键字段创建索引，提高数据查询和过滤的效率。
    • 使用查询优化工具和技术，如查询重写、查询优化器等，优化查询计划和执行过程。
  1. 缓存和预热：
    • 使用缓存技术，将热门数据或计算结果缓存起来，减少重复计算和查询的开销。
    • 针对特定的任务或查询，进行预热操作，提前加载数据到内存中，加速查询响应时间。
  1. 日志分析和故障排查：
    • 分析系统和应用程序的日志数据，发现潜在的性能问题和故障原因。
    • 使用日志分析工具和技术，定位和解决性能瓶颈，提高系统的稳定性和可靠性。
  1. 定期优化和调整：
    • 定期评估和优化系统配置和参数设置，以适应不断变化的数据和业务需求。
    • 监测系统的性能指标和趋势，根据实际情况进行调整和优化。

# 2.4 docker

# 2.4.1 简介

“容器化技术”，“Build Once, Run Everywhere”

** 特性：**docker 是一种容器方案，将应用，配置，环境打包，可在任意支持 docker 命令的环境中直接运行

** 解决问题：** 软件需要在特定环境下运行

与虚拟机比较，docker 是进程级隔离，开销更小，启动更快

** 特点：** 自包含，可移植，相互隔离，轻量级

工作流程：从镜像仓库中拉取到容器镜像，使用容器镜像在宿主机上运行容器

Host：容器运行的系统环境

Image：静态的，通过镜像启动程序

:

Container：最小对象单元，

registry：集中管理镜像的仓库，以 HTTP 的方式对外提供服务。可以通过 docker 命令从 registry 中 pull 到镜像，或者将镜像 push 到 registry 中。

# 2.4.2 镜像管理

操作类似 git

# 本地镜像

docker images : 列出本地镜像。

docker rmi : 删除本地一个或多少镜像。

docker tag : 标记本地镜像，将其归入某一仓库。

docker build ：根据 Dockerfile 构建镜像。

docker commit：将容器 commit 为镜像

docker history : 查看指定镜像的创建历史。

docker save : 将指定镜像保存成 tar 归档文件。

docker load : 导入使用 docker save 命令导出的镜像。

docker import : 从归档文件中创建镜像。

# 镜像仓库

docker login : 登陆到一个 Docker 镜像仓库，如果未指定镜像仓库地址，默认为官方仓库 Docker Hub

docker logout : 登出一个 Docker 镜像仓库，如果未指定镜像仓库地址，默认为官方仓库 Docker Hub

docker pull : 从镜像仓库中拉取或者更新指定镜像

docker push : 将本地的镜像上传到镜像仓库，要先登陆到镜像仓库

docker search : 从 Docker 镜像仓库中查找镜像

# 2.4.3 容器管理

1
2
3
4
5
6
7
8
9
docker run						#运行
docker ps [options]				#查看运行的容器
docker exec						#在运行的容器中执行命令
docker logs [OPTIONS] CONTAINER
								#查看容器日志
docker rm [OPTIONS] CONTAINER [CONTAINER...]		#删除
docker kill [OPTIONS] CONTAINER [CONTAINER...]		#杀死
docker stop [OPTIONS] CONTAINER [CONTAINER...]		#停止
docker start [OPTIONS] CONTAINER [CONTAINER...]		#启动停止的容器

# 2.4.4 dockerfile：

每条指令创建一个镜像层

docker build [OPTIONS] PATH | URL | -

FROM：指定基础镜像

RUN：运行 bash 命令

COPY：将源位置的文件复制到目标位置，

源位置以 / 结尾，表示 <源路径> 复制到 < 目标路径 > 下的同名文件或目录中

ADD：与 copy 类似，可以自动解压，自动下载 URL

CMD：定义容器启动时执行的默认命令

CMD [“nginx”, “-g”, “daemon off;”]

ENV：设置环境变量

ENV

WORKDIR：指定工作目录

EXPOSE：指定端口

Docker systemd service 配置文件有更多操作

# 2.5 kubernetes

快速部署，优化资源使用，分布式架构方案

通过调整应用副本数来分担负载以及提升可用性。

Master 节点的高可用：Kubernetes 采用多 Master 节点的架构来实现 Master 节点的高可用性。在多 Master 节点的架构中，每个 Master 节点都运行着 Kubernetes 的控制平面组件，例如 API Server、Controller Manager 和 Scheduler 等。这些组件通过互相通信来协调集群中的资源和状态。同时，Kubernetes 还采用了选举机制来选出一个 Leader 节点，其他节点作为 Follower 节点提供备份。当 Leader 节点失效时，Follower 节点会自动选举出新的 Leader 节点，从而保证 Master 节点的高可用性。

Node 节点的高可用：Kubernetes 采用多 Node 节点的架构来实现 Node 节点的高可用性。在多 Node 节点的架构中，每个 Node 节点都运行着 Kubernetes 的工作平面组件，例如 Kubelet 和 Kube-proxy 等。这些组件通过与 Master 节点的 API Server 通信来获取任务和配置信息，并运行容器和提供服务。同时，Kubernetes 还采用了 Replication Controller 和 ReplicaSet 等机制来保证 Pod 的副本数量，从而保证应用程序的高可用性。

ETCD 的高可用：ETCD 是 Kubernetes 集群的数据存储和管理中心，负责存储集群的状态和配置信息。为了保证 ETCD 的高可用性，Kubernetes 采用了多 ETCD 节点的架构，通过 Raft 协议来保证数据的一致性和容错性，从而保证 ETCD 的高可用性。

# 2.5.1 结构

img

# master 节点

调度，监控，对资源的操作

为了实现高可用，运行多个 master

# etcd

高可用强一致性分布式存储服务

使用 raft 算法

  • raft 集群中的每个节点都可以根据集群运行的情况在三种状态间切换：follower, candidate 与 leader。
  • follower 节点只能接收来自 leader 节点的请求，candidate 节点是指正在进行 leader 选举的节点，而 leader 节点则是负责处理客户端请求和管理集群状态的节点。
  • leader 和 follower 之间保持心跳。
  • 如果 follower 在一段时间内没有收到来自 leader 的心跳，就会转为 candidate ，发出新的选主请求。
  • 一个节点获得了大于一半节点的投票后会转为 leader
# kube-apiserver

kubernetes-api 前端组件，处理来自客户端的 api 请求并转发到后端的 etcd 系统，管理集群状态和配置

其他组件通过它访问集群状态

# kube-scheduler

调度资源，将 pod 分配

有多种调度策略，负载均衡、资源限制、节点亲和性和反亲和性等

# kube-controller-manager

一组默认控制器，例如 Node Controller、Replication Controller、Endpoints Controller 和 Namespace Controller 等。

# node 节点

承担工作负载

监控并汇报容器状态

根据 master 需要管理容器生命周期

# kubelet

运行在每个节点上，管理节点的 pod

在 node 节点上创建，修改，监控，删除 pod

在 api-server 上注册节点信息，向 master 定期汇报

最小操作单位是 pod ，部分操作（如登录）可精确到 container

kubelet 会定期从 Kubernetes API Server 中获取 Pod 的配置信息，包括 Pod 的名称、容器镜像、容器命令、容器参数、容器环境变量、容器资源限制等。kubelet 会根据 Pod 的配置信息，从容器镜像仓库中下载所需的容器镜像。然后，kubelet 会根据 Pod 的配置信息，创建和启动容器，并将容器的状态信息报告给 Kubernetes API Server。

如果容器启动失败，kubelet 会尝试重新启动容器，直到容器成功启动或者达到最大重试次数。

kubelet 会定期监控节点上运行的容器的状态，并将状态信息报告给 Kubernetes API Server。如果容器出现异常，kubelet 会尝试重新启动容器，直到容器成功启动或者达到最大重试次数。

kubelet 会根据 Pod 的配置信息，挂载 Pod 所需的卷（Volume）。如果卷挂载失败，kubelet 会尝试重新挂载卷，直到卷成功挂载或者达到最大重试次数。

# kube-proxy

在 node 上运行，实现网络代理与负载均衡

使发往 Service 的流量（通过 ClusterIP 和端口）负载均衡到正确的后端 Pod。

# 2.5.2 资源对象

# 基础资源

Node：节点，物理机或虚拟机

namespace：逻辑上的资源对象

ResourceQuota：限制 namespace 中资源的使用

# 工作负载

pod：最小的操作单元，独占 ip，运行在 node 上

ReplicaSet：pod 组监控，无状态负载，保证 running 数

Deployment：管理 ReplicaSet，有 Strategy（更新策略），RevisionHistoryLimit（动态管理 rs）

StatefulSet：面对有状态工作负载的场景（即需要将数据持久化到本地，比如 MySQL 数据库）

DaemonSet：确保在每个节点上都会运行一个 Pod 副本

Job：较为简单的一次性任务

# 网络

Service：解决容器集群负载均衡的问题，可以看作是一组提供某一类功能的 Pod 的对外访问接口。

Ingress：为进入集群的请求提供路由规则的集合，通常需要部署一个 Ingress Controller，监听 Ingress 和 service 的变化，并根据规则配置负载均衡并提供访问入口。

NetworkPolicy： 提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来自外部的流量。

# 存储

PersistentVolume 即 PV，是持久化存储资源，可以是本地存储，也可以是网络存储。

PersistentVolumeClaim 即 PVC，是对 PV 的请求声明。可以声明申请存储空间大小和访问模式。

# 2.6 Spark

Spark 支持多种数据源，包括 Hadoop 的分布式文件系统（HDFS）、Cassandra、HBase 和 Amazon S3 等。这些数据源可以将数据分布在多个节点上，以提高数据的可靠性和可用性。

Spark 将数据分成多个分区，并将每个分区存储在不同的节点上。这样，即使某个节点发生故障，数据仍然可以从其他节点中恢复。Spark 还支持数据复制机制，可以将数据复制到多个节点上，以避免单点故障。具体实现原理是，Spark 会将数据复制到多个节点上，并在多个节点上存储数据的副本。这样，即使某个节点发生故障，数据仍然可以从其他节点中恢复。

Spark 的计算引擎可以在多个节点上并行计算数据，以提高计算效率和可靠性。

Spark 的计算引擎使用 RDD（弹性分布式数据集）来表示数据集，RDD 可以分成多个分区，并在多个节点上并行计算。Spark 的计算引擎还支持任务重试机制，可以在任务失败时自动重试，以提高应用程序的可靠性。

# 2.6.1 资源管理器的高可用性

  • Spark 支持多种资源管理器，包括 Spark Standalone、YARN 和 Mesos 等。这些资源管理器可以监控 Spark 应用程序的运行状态，并在节点故障或其他故障发生时重新启动应用程序。
  • 在 Spark Standalone 模式下，可以使用 Spark 自带的高可用性机制来实现故障转移。这个机制使用 ZooKeeper 来协调主节点的选举和故障转移。当主节点发生故障时，ZooKeeper 会通知备用节点接管主节点的工作。具体实现原理是，每个 Spark Standalone 节点都会向 ZooKeeper 注册自己的信息，包括节点的 IP 地址和端口号等。当主节点发生故障时，备用节点会从 ZooKeeper 获取主节点的信息，并接管主节点的工作。
  • 在 YARN 和 Mesos 模式下，Spark 可以利用这些资源管理器的高可用性机制来实现故障转移。这些资源管理器可以监控 Spark 应用程序的运行状态，并在节点故障或其他故障发生时重新启动应用程序。具体实现原理是，YARN 和 Mesos 会监控 Spark 应用程序的运行状态，并在节点故障或其他故障发生时重新启动应用程序。

# 2.6.2 故障转移

  • Spark 的故障转移机制可以确保 Spark 应用程序在节点故障或其他故障发生时能够继续运行。Spark 会在多个节点上运行应用程序的不同任务，如果某个节点发生故障，Spark 会将该节点上的任务重新分配到其他节点上运行，以确保应用程序的正常运行。
  • 在 Spark Standalone 模式下，故障转移是通过 ZooKeeper 来实现的。当主节点发生故障时，ZooKeeper 会通知备用节点接管主节点的工作，并重新分配任务到其他节点上运行。
  • 在 YARN 和 Mesos 模式下，故障转移是通过资源管理器来实现的。当节点发生故障时，资源管理器会重新启动应用程序，并将任务重新分配到其他节点上运行。

# 2.6.3 动态资源分配

  • Spark 的动态资源分配机制可以根据应用程序的需求动态分配资源，以避免资源浪费。Spark 会根据应用程序的需求动态分配资源，以确保应用程序的正常运行。如果应用程序需要更多的资源，Spark 会从其他任务中抽取资源，并分配给该应用程序。如果应用程序不再需要某些资源，Spark 会将这些资源释放给其他任务使用。

# 2.6.4 任务重试

  • Spark 的任务重试机制可以在任务失败时自动重试，以提高应用程序的可靠性。当任务失败时，Spark 会自动重试该任务，直到任务成功为止。如果任务多次失败，Spark 会将该任务标记为失败，并将任务重新分配到其他节点上运行。
更新于 阅读次数 次