云计算技术-25fa-zb最后一课

发表于 更新于 分类于 本文字数： 3.3k 阅读时长 ≈ 3 分钟

好吧，我是把那个考试点给你说一下吧。其实就那点东西嘛

本文连载于云计算技术-25fa-zb最后一课| HeZzz

🙇‍♂️🙇‍♂️🙇‍♂️时间仓促，有不足之处烦请及时告知。邮箱hez2z@foxmail.com 或者在 速通之家 群里 @9¾。

虚拟化

虚拟化的定义

在计算机科学领域中， 虚拟化代表着对计算资源的抽象，而不仅仅局限于虚拟机的概念。

虚拟化是一种技术，它通过在物理硬件之上创建一个抽象层，使得多个虚拟实例能够共享同一套物理资源。这个抽象层通常由虚拟机监视器(Hypervisor)或容器引擎来实现，它们负责管理和分配底层硬件资源，如CPU、内存、存储和网络等。

虚拟机的类型

  1. 全虚拟化，半虚拟化，硬件辅助虚拟化
    • 全虚拟化：通过软件模拟完整的硬件环境，使得操作系统无需修改即可运行在虚拟机上。
    • 半虚拟化：需要对操作系统进行修改，以便更好地与虚拟化层协同工作，提高性能。
    • 硬件辅助虚拟化：利用现代处理器的虚拟化扩展(如 Intel VT-x 和 AMD-V)来提升虚拟化性能和效率。
  2. 硬件虚拟化技术
    • GPU 虚拟化：允许多个虚拟机共享物理 GPU 资源，以支持图形密集型应用。
    • FPGA 虚拟化：使得多个虚拟机能够访问和使用 FPGA 资源，适用于高性能计算任务。
    • RMDA 虚拟化：远程直接内存访问虚拟化，提升数据传输效率。
    • NVM 虚拟化：非易失性内存虚拟化，优化存储性能。
  3. 容器与虚拟机对比
    • 容器：轻量级，启动速度快，共享主机操作系统内核，适合微服务架构。
    • 虚拟机：重量级，启动较慢，拥有独立的操作系统，适合需要隔离的应用场景。

HDFS

“HDFS 一些语言性东西。大概是这些。”

他就说了这么一句话，然后就没了，可以看看 HDFS 相关的作业或者在本站搜索 “HDFS” 查看更多。

http://hez2z.github.io/2025/11/29/云计算技术-25fa-zb学习通作业/#HDFS-作业

MapReduce

那然后我可不可以给你们一个表，然后让你上一课一样是那种形式，给你问题描述，让你去写出它的输入输出。

MapReduce 还有 Combiner 的,Reducer(？没听清) 的一些概念，

可以看

云计算技术 -25fa-zb 最后一课 - MapReduce

和

https://hez2z.github.io/2025/11/29/云计算技术-25fa-zb学习通作业/#MapReduce

HBase

Hbase 让你设计一个表

TODO: 我还没找到 HBase 的相关习题，帮帮我😭

存储并查询电商平台的用户订单数据
常见的查询需求：

  1. 根据用户ID查询该用户的所有订单（按时间倒序）。
  2. 根据订单ID查询订单的详细信息。
  3. 根据时间范围查询某个时间段内所有订单（运营分析用）。

A1. 设计 HBase 表结构

表名：user_orders

列族 列限定符 说明
info user_id 用户ID
info order_id 订单ID
info order_date 订单日期
info amount 订单金额
info status 订单状态
details item_list 订单商品列表（JSON格式）

行键设计：row_key = user_id + reverse(order_date) + order_id

  • 这样设计行键可以支持按用户ID查询所有订单，并且订单按时间倒序排列，方便获取最新订单。
  • 订单ID作为行键的一部分，支持根据订单ID查询订单详情。
  • 时间范围查询可以通过扫描行键前缀实现。

根据用户 ID 查询订单：

  • 使用 Scan 操作，设置行键前缀为 user_id，获取该用户的所有订单，结果按时间倒序排列。

根据订单 ID 查询订单详情：

  • 使用 Get 操作，直接通过 row_key 查询订单详情。

根据时间范围查询订单：

  • 使用 Scan 操作，设置行键范围为 start_row_key 和 end_row_key，获取指定时间段内的所有订单。

ZooKeeper

他只是说了一个 “ZooKeeper”, 然后就没了，Claude 对 ZooKeeper 的理解如下。

ZooKeeper | Apache

What is Apache ZooKeeper? | GeeksforGeeks

Apache ZooKeeper | Wiki

Apache ZooKeeper 是一个开源的分布式协调服务，旨在简化分布式应用程序的管理和协调。它提供了一组高性能的原语，用于实现分布式系统中的同步、配置管理和命名服务。

ZooKeeper 的核心功能

  1. 配置管理：ZooKeeper 可以集中管理分布式系统的配置信息，当配置发生变化时，能够及时通知各个节点更新配置。

  2. 命名服务：提供类似 DNS 的命名服务，为分布式系统中的节点提供统一的命名空间，方便节点之间的相互发现和通信。

  3. 分布式锁：通过 ZooKeeper 的顺序节点和临时节点特性，可以实现分布式锁机制，保证在分布式环境下对共享资源的互斥访问。

  4. 集群管理：监控集群中节点的状态，当节点上线或下线时，能够及时感知并通知相关节点，实现动态的集群管理。

  5. Leader 选举：在分布式系统中，ZooKeeper 可以帮助实现 Leader 选举机制，确保在任何时刻只有一个节点作为 Leader 提供服务。

ZooKeeper 的数据模型

ZooKeeper 采用树形的层次化命名空间，类似于文件系统的目录结构：

  • ZNode：ZooKeeper 中的数据节点，每个 ZNode 可以存储数据，也可以有子节点。
  • 持久节点(Persistent)：创建后会一直存在，除非主动删除。
  • 临时节点(Ephemeral)：与客户端会话绑定，会话结束后自动删除。
  • 顺序节点(Sequential)：在节点名称后自动添加递增的序号，常用于实现分布式锁。

ZooKeeper 的一致性保证

ZooKeeper 使用 ZAB(ZooKeeper Atomic Broadcast)协议 来保证数据的一致性：

  1. 顺序一致性：来自客户端的更新请求会按照发送顺序被应用。
  2. 原子性：更新操作要么成功，要么失败，不存在中间状态。
  3. 单一视图：无论客户端连接到哪个服务器，看到的数据视图都是一致的。
  4. 持久性：一旦更新被确认，该更新将持久保存，直到被覆盖。

ZooKeeper 集群架构

ZooKeeper 采用主从架构：

  • Leader：负责处理所有的写请求，并将状态变化广播给 Follower。
  • Follower：处理读请求，参与 Leader 选举和投票，同步 Leader 的状态。
  • Observer：只处理读请求，不参与投票，用于提高读性能和可扩展性。

集群需要满足 过半机制(Quorum)：超过半数的节点存活，集群才能正常工作。例如，5 个节点的集群最多容忍 2 个节点故障。

ZooKeeper 的应用场景

  1. 分布式协调：协调分布式系统中各个节点的行为，如任务调度、资源分配等。
  2. 服务注册与发现：微服务架构中，服务提供者在 ZooKeeper 注册，消费者从 ZooKeeper 获取服务列表。
  3. 分布式队列：利用顺序节点实现分布式队列，保证任务的有序执行。
  4. 主备切换：当主节点故障时，通过 Leader 选举机制快速切换到备用节点。

ZooKeeper 与 Nacos 的对比

PS：诶，分布式系统中的同步、配置管理和命名服务？这好像和 Nacos 有点像？

还真是，对于微服务架构，需要同时处理动态服务发现和配置管理的场景来说，Nacos 就是 ZooKeeper 的一个替代品。

主要区别：

特性 ZooKeeper Nacos
CAP 模型 CP (一致性+分区容错) 支持 AP 和 CP 模式切换
适用场景 强一致性要求的协调服务 微服务的注册发现和配置管理
使用复杂度 较高，需要理解 ZNode 模型 较低，提供友好的 UI 和 API
性能 写入性能较低 性能更优，特别是在 AP 模式下

在网络分区发生时，ZooKeeper 会停止对少数派分区的服务，只有多数派节点可达时才能提供服务，从而保证数据的强一致性。而 Nacos 在默认的 AP 模式下，允许各个分区继续提供服务，确保服务的持续可用，通过后台同步机制最终达到一致。

如果你了解 Nacos 但是不了解 ZooKeeper，那么你可以向 AI 助手提问 "Nacos 和 ZooKeeper 有什么区别？"以便于更好地理解 ZooKeeper。

ZooKeeper