第五篇-存储服务

最新推荐文章于 2024-08-03 23:10:27 发布
转载 最新推荐文章于 2024-08-03 23:10:27 发布 · 377 阅读 · 0
文章标签：

#云计算 #openstack #cinder #虚拟化

 


第五篇cinder— 存储服务

一、cinder 介绍：

 

理解 Block Storage

操作系统获得存储空间的方式一般有两种：

  1. 通过某种协议（SAS,SCSI,SAN,iSCSI 等）挂接裸硬盘，然后分区、格式化、创建文件系统；或者直接使用裸硬盘存储数据（数据库）

  2. 通过 NFS、CIFS 等 协议，mount 远程的文件系统

     

第一种裸硬盘的方式叫做 Block Storage（块存储），每个裸硬盘通常也称作 Volume（卷） 第二种叫做文件系统存储。NAS 和 NFS 服务器，以及各种分布式文件系统提供的都是这种存储。

 

理解 Block Storage Service

Block Storage Servicet 提供对 volume 从创建到删除整个生命周期的管理。从 instance 的角度看，挂载的每一个 Volume 都是一块硬盘。OpenStack 提供 Block Storage Service 的是 Cinder，其具体功能是：

  1. 提供 REST API 使用户能够查询和管理 volume、volume snapshot 以及 volume type

  2. 提供 scheduler 调度 volume 创建请求，合理优化存储资源的分配

  3. 通过 driver 架构支持多种 back-end（后端）存储方式，包括 LVM，NFS，Ceph 和其他诸如 EMC、IBM 等商业存储产品和方案

     

Cinder 架构

下图是 cinder 的逻辑架构图

 

 

Cinder 包含如下几个组件：

 

cinder-api

接收 API 请求， 调用 cinder-volume 。是整个 Cinder 组件的门户，所有 cinder 的请求都首先由 cinder-api 处理。cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我们可以查询 cinder-api 的 endponits。

客户端可以将请求发送到 endponits 指定的地址，向 cinder-api 请求操作。 当然，作为最终用户的我们不会直接发送 Rest API 请求。OpenStack CLI，Dashboard 和其他需要跟 Cinder 交换的组件会使用这些 API。

cinder-api 对接收到的 HTTP API 请求会做如下处理：

1、检查客户端传人的参数是否合法有效

2、调用 cinder 其他子服务的处理客户端请求

3、将 cinder 其他子服务返回的结果序列号并返回给客户端

cinder-api 接受哪些请求呢？简单的说，只要是 Volume 生命周期相关的操作，cinder-api 都可以响应。大部分操作都可以在 Dashboard 上看到。

 

 

cinder-volume

管理 volume 的服务，与 volume provider 协调工作，管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。

 

cinder-volume 在存储节点上运行，OpenStack 对 Volume 的操作，最后都是交给 cinder-volume 来完成的。cinder-volume 自身并不管理真正的存储设备，存储设备是由 volume provider 管理的。cinder-volume 与 volume provider 一起实现 volume 生命周期的管理。

 

通过 Driver 架构支持多种 Volume Provider

接着的问题是：现在市面上有这么多块存储产品和方案（volume provider），cinder-volume 如何与它们配合呢？

 

通过的 Driver 架构。 cinder-volume 为这些 volume provider 定义了统一的接口，volume provider 只需要实现这些接口，就可以 Driver 的形式即插即用到 OpenStack 系统中。

 

定期向 OpenStack 报告计算节点的状态

cinder-volume 会定期向 Cinder 报告存储节点的空闲容量来做筛选启动volume

 

实现 volume 生命周期管理

Cinder 对 volume 的生命周期的管理最终都是通过 cinder-volume 完成的，包括 volume 的 create、extend、attach、snapshot、delete 等。

 

cinder-scheduler

scheduler 通过调度算法选择最合适的存储节点创建 volume。 创建 Volume 时，cinder-scheduler 会基于容量、Volume Type 等条件选择出最合适的存储节点，然后让其创建 Volume

 

volume provider

数据的存储设备，为 volume 提供物理存储空间。 cinder-volume 支持多种 volume provider，每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。

 

Message Queue

Cinder 各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列，子服务之间实现了解耦，这种松散的结构也是分布式系统的重要特征。

 

Database Cinder 

有一些数据需要存放到数据库中，一般使用 MySQL。数据库是安装在控制节点上的，比如在我们的实验环境中，可以访问名称为“cinder”的数据库。

 

 

物理部署方案

Cinder 的服务会部署在两类节点上，控制节点和存储节点。我们来看看控制节点 controller 上都运行了哪些 cinder-* 子服务。

 

 

cinder-api 和 cinder-scheduler 部署在控制节点上，这个很合理。

 

至于 cinder-volume 也在控制节点上可能有些同学就会迷糊了：cinder-volume 不是应该部署在存储节点上吗？

 

要回答这个问题，首先要搞清楚一个事实： OpenStack 是分布式系统，其每个子服务都可以部署在任何地方，只要网络能够连通。无论是哪个节点，只要上面运行了 cinder-volume，它就是一个存储节点，当然，该节点上也可以运行其他 OpenStack服务。

 

cinder-volume 是一顶存储节点帽子，cinder-api 是一顶控制节点帽子。在我们的环境中，devstack-controller 同时戴上了这两顶帽子，所以它既是控制节点，又是存储节点。当然，我们也可以用一个专门的节点来运行 cinder-volume。

 

这再一次展示了 OpenStack 分布式架构部署上的灵活性： 可以将所有服务都放在一台物理机上，用作一个 All-in-One 的测试环境；而在生产环境中可以将服务部署在多台物理机上，获得更好的性能和高可用。

 

RabbitMQ 和 MySQL 通常放在控制节点上。另外，也可以用 cinder service list 查看 cinder-* 子服务都分布在哪些节点上

 

还有一个问题：volume provider 放在那里？

一般来讲，volume provider 是独立的。cinder-volume 使用 driver 与 volume provider 通信并协调工作。所以只需要将 driver 与 cinder-volume 放到一起就可以了。在 cinder-volume 的源代码目录下有很多 driver，支持不同的 volume provider。

 

后面我们会以 LVM 和 NFS 这两种 volume provider 为例讨论 cinder-volume 的使用，其他 volume provider 可以查看 OpenStack 的 configuration 文档。

 

 

二、 Cinder 的设计思想：

 

从 volume 创建流程看 cinder-* 子服务如何协同工作

 

对于 Cinder 学习来说，Volume 创建是一个非常好的场景，涉及各个 cinder-* 子服务，下面是流程图：

  • 客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（cinder-api）发送请求：“帮我创建一个 volume”

     

  • API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个 volume”

     

  • Scheduler（cinder-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计存储点中选出节点 A

     

  • Scheduler 向 Messaging 发送了一条消息：“让存储节点 A 创建这个 volume”

     

  • 存储节点 A 的 Volume（cinder-volume）从 Messaging 中获取到 Scheduler 发给它的消息，然后通过 driver 在 volume provider 上创建 volume。

 

Cinder 的设计思想

 

Cinder 延续了 Nova 的以及其他组件的设计思想。

API 前端服务

cinder-api 作为 Cinder 组件对外的唯一窗口，向客户暴露 Cinder 能够提供的功能，当客户需要执行 volume 相关的操作，能且只能向 cinder-api 发送 REST 请求。这里的客户包括终端用户、命令行和 OpenStack 其他组件。

设计 API 前端服务的好处在于：

  1. 对外提供统一接口，隐藏实现细节

  2. API 提供 REST 标准调用服务，便于与第三方系统集成

  3. 可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 cinder-api 进程

Scheduler 调度服务

Cinder 可以有多个存储节点，当需要创建 volume 时，cinder-scheduler 会根据存储节点的属性和资源使用情况选择一个最合适的节点来创建 volume。

调度服务就好比是一个开发团队中的项目经理，当接到新的开发任务时，项目经理会根据任务的难度，每个团队成员目前的工作负荷和技能水平，将任务分配给最合适的开发人员。

Worker 工作服务

调度服务只管分配任务，真正执行任务的是 Worker 工作服务。

在 Cinder 中，这个 Worker 就是 cinder-volume 了。这种 Scheduler 和 Worker 之间职能上的划分使得 OpenStack 非常容易扩展：当存储资源不够时可以增加存储节点（增加 Worker）。 当客户的请求量太大调度不过来时，可以增加 Scheduler。

Driver 框架

OpenStack 作为开放的 Infrastracture as a Service 云操作系统，支持业界各种优秀的技术，这些技术可能是开源免费的，也可能是商业收费的。

这种开放的架构使得 OpenStack 保持技术上的先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。 那 OpenStack 的这种开放性体现在哪里呢？一个重要的方面就是采用基于 Driver 的框架。

以 Cinder 为例，存储节点支持多种 volume provider，包括 LVM, NFS, Ceph, GlusterFS，以及 EMC, IBM 等商业存储系统。 cinder-volume 为这些 volume provider 定义了统一的 driver 接口，volume provider 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。下面是 cinder driver 的架构示意图：

在 cinder-volume 的配置文件 /etc/cinder/cinder.conf 中 volume_driver 配置项设置该存储节点使用哪种 volume provider 的 driver，下面的示例表示使用的是 LVM。

 

OpenStack之存储cinder
weixin_42795092的博客
03-17 1376
因为有了消息队列，子服务之间实现了解耦，这种松散的结构也是分布式系统的重要特征。用户向cinder-api发送请求，cinder-api接收API请求后将消息放入消息队列，通过cinder-scheduler处理消息队列 里请求，选择合适节点创建volume，由cinder-volume管理volume，volume provider为volume提供存储空间。3）文件系统无法共享：不同的操作系统使用不同的文件系统，格式化后，不同文件系统间的数据是无法共享的，虽然其他主机可以挂载，但是数据不能识别。
Openstack15--块存储服务（Cinder）安装
m0_70212665的博客
11-19 1541
安装的“openstack-cinder”软件包里包括“cinder-api”和“cinder-scheduler”模块。安装“openstack-cinder”软件包时，和安装其他OpenStack核心组件时一样，会自动创建名为“cinder”的Linux系统用户和同名的用户组。
cinder块存储服务安装
qq_42365664的博客
07-12 902
cinder-api：  接受和响应外部有关块存储请求cinder-volume：  提供存储空间cinder-scheduler:  调度器，决定将要分配的空间由哪一个cinder-volume提供cinder-backup:  备份存储1、数据库创库授权 CREATE DATABASE cinder;GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'l...
08.存储Cinder→1.理解Block Storage
xiangrongweng0547的博客
07-13 419
返回总目录 操作系统获得存储空间的方式一般有二种：通过某种协议（SAS,SCSI,SAN,iSCSI 等）挂接裸硬盘，然后分区、格式化、创建文件系统；或者直接使用裸硬盘存储数据（数据库）介绍：第一种裸硬盘的方式叫做Block Storage（块存储），每个裸硬盘通常也称作Volume（卷）。使用lvm划分出的逻辑卷也是块存储，因为操作系统是区分不出到底是逻辑还是物理的，比如，有5个逻辑卷，它一概就...
Dubbo视频教程--高级篇--第24节--简易版支付系统介绍
01-03
### Dubbo视频教程--高级篇--第24节--简易版支付系统介绍知识点 #### 1. Dubbo框架与分布式系统架构 Dubbo是一款高性能、轻量级的Java RPC框架，由阿里巴巴开源。它提供了高可用的服务治理能力，在分布式系统中尤为...
1-IV-H(G)-用户手册-现场网络篇-521CN-03.pdf
06-24
- `16 65535 MAX MIN MAX MIN 1 505 1 1 50.5 5`：这里提到了16位数据的最大和最小值，并给出了具体示例。 - `ABCDEF A (0x41) B (0x42) C (0x43) D (0x44) E (0x45) F (0x46)`：展示了一些ASCII编码的字符及其...
跟我学，你的服务器安全吗？第二篇----数据库mysql安全篇
zhumengyisheng的博客
12-10 3182
这是一篇非常值得收藏的文章，你的服务器会天天被黑客攻击吧？数据库又瘫痪了，数据库又被黑客入侵了，数据库怎么这么多事？怎么让数据库能安全些呢？急需指导，在线等，挺急的，再晚一会，老板都要破产了......
K8s- Kubernetes全栈架构师 K8s初级篇+中级篇+高级篇+架构篇培训视频.zip
06-07
第07阶段:K8s基础篇-服务发布入门[11节课] 第08阶段:K8s基础篇-配置管理[5节课] 第09阶段:K8s进阶篇-持久化存储入门[8节课] 第10阶段:K8s进阶篇-高级调度[11节课] 第11阶段:k8s进阶篇-准入控制及细粒度权限控制[10节...
第一部分-基础篇-第一章：PSTN与VOIP（下篇）
huiguo_的博客
05-28 1818
IMS的全称是IP多媒体子系统（IP Multimedia Subsystem）,它是一个基于IP网提供 语音及多媒体业务的网络体系架构。作为其 GSM之后的未来移动网络远景目标的一部分。IMS的最初的版本（3GPP R5 ）主要是给出了一种基于GPRS来实现IP多媒体业务的方法。在这个版本的基础上，3GPP、3GPP2以及 TISPAN进行了进一步的更新，以支持GPRS之外的（诸如WLAN, CDMA2000和固定等） 其他接入网络。
08.存储Cinder→2.理解Block Storage Service
xiangrongweng0547的博客
07-13 209
返回总目录 Block Storage Service提供对 volume 从创建到删除整个生命周期的管理。从 instance 的角度看，挂载的每一个 Volume 都是一块硬盘。OpenStack 提供 Block Storage Service 的是 Cinder，其具体功能是：提供REST API使用户能够查询和管理 volume、volume snapshot 以及 volume t...
OpenStack项目八--块存储服务安装（cinder)
wsh
08-03 1183
Cinder是OpenStack平台中的一个核心项目，提供对存储卷的创建、挂载、卸载、快照等全生命周期的管理，为云计算环境中的虚拟机提供持久化的存储。
Linux中cinder的作用,11-cinder块存储服务部署
weixin_29876341的博客
05-13 551
[TOC]## 功能简述块存储服务(cinder)为实例提供块存储。通过驱动程序可支持的各种各样的存储,如NAS/SAN，NFS，LVM，Ceph等。**常用组件：**cinder-api: 接收和响应外部有关块存储请求cinder-volume： 提供存储空间cinder-scheduler：调度器，决定将要分配的空间由哪一个cinder-volume提供cinder-backu...
Block Storage\File Storage\Object storage.
hwclong911的博客
05-15 744
OpenStack —— 块存储服务Cinder(六)
weixin_33681778的博客
09-05 443
一、Cinder介绍    Cinder(Block Storage service)提供对volume从创建到删除整个生命周期的管理，从instance的角度看，挂载的每一个volume都是一块硬盘。    OpenStack早起版本使用nova-volume为云平台虚拟机提供持久性块存储。从F版本后，就把最为Nova组成部分的nova-volume分离了出来，形成了独立的Cinder组件。二、...
探索 OpenStack 之（9）：深入块存储服务Cinder （功能篇）
weixin_34220963的博客
01-13 324
继研究了Neutron之后，继续Nova的外围研究之旅。本站是研究块存储服务Cinder。   0。验证环境 环境包括： 1、一个controller节点，运行nova-api, nova-scheduler, cinder-api, cinder-scheduler, mysql, rabbitmq 2、一个Nova compute节点，运行一个虚机 3、三个cinder vol...
深入理解块存储：特性、应用场景及与其他存储方式的对比
编程技术探索者，分享C/C++、C#、Java、数据库等开发经验，聚焦实战技巧与AI兴趣，助力编程爱好者成长。
07-05 1359
块存储是什么？什么是块存储?详解块存储的概念
openstack块存储服务基础：Linux LVM硬盘管理及LVM扩容
Mediocre_person的博客
11-30 4894
在Openstack中，有3个与存储相关组件：Swift——提供对象存储（object storage）,Glance——提供虚机镜像（image）存储和管理，Cinder——提供块存储（block storage）。 块存储服务基本概念： Cinder的核心功能是对卷的管理，允许对卷、卷的类型、快照进行处理。然而它并没有实现对块设备的管理和实际服务（提供逻辑卷），而是通过后端的统一存储接口来支持不同块设备厂商的块存储服务，实现其驱动支持并于OpenStack进行整合。 cinder两个显著..
OpenStack之部署块存储服务cinder
Tuki来了
08-20 5712
OpenStack块存储服务(cinder)为虚拟机添加持久的存储，块存储提供一个基础设施为了管理卷，以及和OpenStack计算服务交互，为实例提供卷。此服务也会激活管理卷的快照和卷类型的功能。
基础篇-0-Java虚拟机导学课程 11:33 基础篇-1-初识JVM 22:27 基础篇-2-Java虚拟机的组成 04:47 基础篇-3-字节码文件的组成-以正确的姿势打开字节码文件 10:41 基础篇（补）-3.5-字节码文件的组成-基础信息 15:54 基础篇-4-字节码文件的组成-常量池和方法 25:51 基础篇-5-字节码文件常见工具的使用1 11:43 基础篇-6-字节码文件常见工具的使用2 22:20 基础篇-7-类的生命周期加载阶段 22:09 基础篇-8-类的生命周期2连接阶段 19:58 基础篇-9-类的生命周期3初始化阶段 26:27 基础篇-10-类加载器的分类 13:56 基础篇-11-启动类加载器 13:36 基础篇-12-扩展和应用程序类加载器 16:26 基础篇-13-双亲委派机制 18:43 基础篇-14-打破类的双亲委派机制-自定义类加载器 25:16 基础篇-15-打破双亲委派机制2-线程上下文类加载器 20:17 基础篇-16-打破双亲委派机制3-osgi和类的热部署 11:53 基础篇-17-JDK9之后的类加载器 09:05 基础篇-18-运行时数据区-程序计数器 15:42 基础篇-19-栈-局部变量表 19:20 基础篇-20-栈-操作数栈和帧数据 12:08 基础篇-21-栈-内存溢出 15:28 基础篇-22-堆内存 25:56 基础篇-23-方法区的实现 16:25 基础篇-24-方法区-字符串常量池 20:40 基础篇-25-直接内存 12:39 基础篇-26-自动垃圾回收 11:32 基础篇-27-方法区的回收 11:32 基础篇-28-引用计数法 15:41 基础篇-29-可达性分析法 20:25 基础篇-30-软引用 24:40 基础篇-31-弱虚终结器引用 12:08 基础篇-32-垃圾回收算法的评价标准 13:31 基础篇-33-垃圾回收算法1 10:05 基础篇-34-垃圾回收算法-分代GC 20:19 基础篇-35-垃圾回收器1 15:54 基础篇-36-垃圾回收器2 11:44 基础篇-37-垃圾回收器3 15:51 基础篇-38-g1垃圾回收器 26:23 实战篇-1-内存泄漏和内存溢出 21:25 实战篇-2-解决内存泄漏-监控-top命令 12:16 实战篇-3-解决内存泄漏-监控-visualvm 12:50 实战篇-4-解决内存泄漏-监控-arthas tunnel 15:18 实战篇-5-解决内存泄漏-监控-prometheus-grafana 17:53 实战篇-6-解决内存泄漏-堆内存状况对比 08:39 实战篇-7-解决内存泄漏-内存泄漏产生的几大原因 16:01 实战篇-8-内存泄漏产生的原因2 13:30 实战篇-9-内存泄漏产生的原因3 10:43 实战篇-10-内存泄漏产生的原因4 10:04 实战篇-11-内存泄漏产生原因2-并发请求问题 17:30 实战篇-12-导出堆内存快照并使用MAT分析 08:38 实战篇-13-MAT内存泄漏检测原理 17:23 实战篇-14-服务器导出内存快照和MAT使用小技巧 13:31 实战篇-15-实战1-查询大数据量导致的内存溢出 26:24 实战篇-16-实战2-mybatis导致的内存溢出 10:34 实战篇-17-实战3-k8s容器环境导出大文件内存溢出 26:13 实战篇-18-系统不处理业务时也占用大量的内存 14:13 实战篇-19-文章审核接口的内存问题 18:28 实战篇-20-btrace和arthas在线定位问题 20:15 实战篇-21-GC调优的核心目标 11:23 实战篇-22-GC调优的常用工具 12:05 实战篇-23-GC调优的常见工具2 14:25 实战篇-24-常见的GC模式 13:38 实战篇-25-基础JVM参数的设置 28:31 实战篇-26-垃圾回收器的选择 18:04 实战篇-27-垃圾回收参数调优 07:56 实战篇-28-实战-GC调优和内存调优 30:43 实战篇-29-性能问题的现象和解决思路 10:49 实战篇-30-定位进程CPU占用率高的问题 18:52 实战篇-31-接口响应时间很长问题的定位 14:44 实战篇-32-火焰图定位接口响应时间长的问题 12:03 实战篇-33-死锁问题的检测 14:37 实战篇-34-基准测试框架JMH的使用 28:24 实战篇-35-实战-性能调优 26:36 高级篇-01-GraalVM介绍 12:13 高级篇-02-GraalVM的两种运行模式 15:43 高级篇-03-使用SpringBoot3构建GraalVM应用 15:08 高级篇-04-将GraalVM应用部署到函数计算 25:13 高级篇-05-将GraalVM应用部署到Serverless 09:14 高级篇-06-参数优化和故障诊断 22:31 高级篇-07-垃圾回收器的技术演进 13:09 高级篇-08-ShenandoahGC 22:50 高级篇-09-ZGC 14:35 高级篇-10-实战案例-内存不足时的垃圾回收测试 09:47 高级篇-11-JavaAgent技术 12:16 高级篇-12-JavaAgent环境搭建 15:24 高级篇-13-查看内存的使用情况 18:48 高级篇-14-生成内存快照 13:47 高级篇-15-获取类加载器的信息 16:26 高级篇-16-打印类的源码 18:00 高级篇-17-使用ASM增强方法 29:45 高级篇-18-使用ByteBuddy打印方法执行的参数和耗时 21:55 高级篇-19-APM系统和数据采集 24:30 原理篇-01-栈上的数据存储 15:05 原理篇-02-boolean在栈上的存储方式 22:48 原理篇-03-对象在堆上的存储1 17:27 原理篇-04-对象在堆上的存储2 25:14 原理篇-05-方法调用的原理1-静态绑定 19:26 原理篇-06-方法调用的原理2-动态绑定 15:25 原理篇-07-异常捕获的原理 12:00 原理篇-08-JIT即时编译器 14:49 原理篇-09-JIT即时编译器优化手段1-方法内联 16:49 原理篇-10-JIT即时编译器优化手段2-逃逸分析 09:03 原理篇-11-g1垃圾回收器原理-年轻代回收 27:57 原理篇-12-g1垃圾回收器原理-混合回收 17:24 原理篇-13-ZGC原理 26:27 原理篇-14-ShenandoahGC原理 09:39 面试篇-01-什么是JVM 16:38 面试篇-02-字节码文件的组成 15:02 面试篇-03-什么是运行时数据区 20:09 面试篇-04-哪些区域会出现内存溢出 11:56 面试篇-05-JDK6-8内存区域上的不同 14:36 面试篇-06-类的生命周期 17:17 面试篇-07-什么是类加载器 17:05 面试篇-08-什么是双亲委派机制 12:15 面试篇-09-如何打破双亲委派机制 18:10 面试篇-10-tomcat的自定义类加载器 31:18 面试篇-11-如何判断堆上的对象有没有被引用 10:05 面试篇-12-JVM中都有哪些引用类型 16:58 面试篇-13-theadlocal中为什么要使用弱引用 12:16 面试篇-14-有哪些垃圾回收算法 24:54 面试篇-15-有哪些常用的垃圾回收器 18:55 面试篇-16-如何解决内存泄漏问题 23:52 面试篇-17-常见的JVM参数 11:11 这是目前我学习的视频集合，要不要全看，或者少了什么，有哪些重要内容需要进行学习汇总或刷题或通过小实例验证
最新发布
10-02
<think>我们正在为一位计算机专业研一学生设计JVM学习方案，该学生研究方向是边缘计算安全（差分隐私、隐私路径等），有408和软件工程基础，目前正在学习JVM。需要评估是否需要全看JVM视频集，补充缺失内容，并提供学习汇总、刷题和实例验证建议。 分析需求： 1. 判断视频全集必要性：基于研究生背景和边缘计算安全方向，不需要全看基础视频，应侧重与安全、资源受限环境相关的JVM特性。 2. 补充缺失内容：边缘设备特有的JVM问题（内存管理、轻量级GC、安全机制）。 3. 学习汇总：结构化知识框架，突出重点。 4. 刷题建议：结合边缘安全场景的实战题目。 5. 小实例验证：通过代码实验加深理解。 参考信息： [^1]: 强调现代程序需兼顾灵活性和安全性。 [^2]: 提到JVM监控工具（如JConsole、VisualVM）对分析GC性能的重要性。 [^3]: 警示微小的不一致会导致严重问题（类比JVM调优需谨慎）。 解决方案： 一、视频学习策略（不全看） - 跳过：基础内存结构、类加载流程等已掌握内容。 - 重点观看： 1. 堆外内存管理（DirectByteBuffer与网络安全缓冲区） 2. 适用于嵌入式设备的GC算法（ZGC/Shenandoah低延迟特性） 3. 字节码验证与安全沙箱（关联边缘设备防恶意代码） 4. JNI安全实践（预防本地代码漏洞） 二、缺失内容补充（边缘计算关联点） - 内存安全：垃圾回收停顿对实时性影响（边缘设备需<10ms停顿） - 轻量化：GraalVM Native Image构建无JVM运行时 - 可信执行：Intel SGX Enclave与JVM的集成 - 资源监控：Linux cgroups限制JVM内存/CPU 三、学习汇总（核心模块） ``` 1. 内存模型进阶 - 堆外内存：ByteBuffer.allocateDirect VS malloc - 内存屏障：VarHandle保证边缘设备数据一致性 2. 垃圾回收调优 - ZGC着色指针技术（适应边缘设备异构内存） - 最大停顿时间预测：`-XX:MaxGCPauseMillis`实战 3. 安全机制 - 类加载隔离：自定义类加载器实现隐私计算引擎隔离 - 字节码加密：Transformer保护边缘节点代码 4. 原生交互 - JNI临界区：GetPrimitiveArrayCritical优化数据传输 - 安全退出：确保本地代码释放资源 ``` 四、刷题建议 - LeetCode题目：不需要传统算法题，改成JVM场景题： 1. 手写安全内存分配器（防止堆外内存泄漏） 2. 模拟ZGC并发处理（并发标记算法实现） - 大厂面试题改造： - 如何诊断边缘设备Full GC？→ 添加资源限制条件（仅512MB RAM） 五、小实例验证 ```java // 边缘设备GC停顿模拟 public class GCPauseSimulator { static final int _1MB = 1024 * 1024; public static void main(String[] args) { // 创建短生命周期对象模拟传感器数据 new Thread(() -> { while (true) { byte[] sensorData = new byte[2 * _1MB]; // 诱发Young GC Thread.sleep(10); } }).start(); // 监控线程（边缘设备需低延迟） new Thread(() -> { long lastTime = System.nanoTime(); while (true) { long now = System.nanoTime(); if (now - lastTime > 20_000_000) { // 20ms停顿警报 System.err.println("GC pause detected: " + (now - lastTime)/1000000 + "ms"); } lastTime = now; } }).start(); } } ``` 运行参数：`-XX:+UseZGC -Xmx256m -XX:+UnlockDiagnosticVMOptions -XX:+PrintGC` 六、监控工具实践（参考引用[^2]） - JConsole：观察堆外内存（Direct Memory）波动 - VisualVM：分析GC日志中停顿时间分布 - 添加安全监控：`-Djava.security.debug=access`跟踪权限检查 相关问题： 1. 如何在512MB内存的边缘设备配置ZGC参数？ 2. 自定义类加载器如何防止差分隐私算法被篡改？ 3. 边缘设备部署时，如何验证JVM运行时完整性？ 4. JNI代码导致的内存泄漏如何诊断？ </think>### 针对边缘计算安全方向的JVM学习优化方案 #### 一、视频学习策略（不必全看） 1. **可跳过的基础内容** - 类加载流程、内存区域划分等基础概念（408已覆盖） - GC基础算法（标记清除/复制算法等） *理由：你已具备扎实的计算机基础，重复学习效率低* 2. **必须重点学习的内容** - 堆外内存管理（`DirectByteBuffer`） ```java // 边缘设备内存敏感场景示例 ByteBuffer directBuffer = ByteBuffer.allocateDirect(1024); // 绕过堆内存GC ``` - 低延迟GC原理（**ZGC/Shenandoah**） - 关键参数：`-XX:MaxGCPauseMillis=10`（边缘设备要求<20ms停顿） - 安全沙箱机制 - `SecurityManager`在隐私计算中的应用 - 字节码验证流程（结合差分隐私算法保护） - JNI本地调用安全 - 预防本地代码的内存泄漏攻击 #### 二、缺失关键内容补充（边缘场景特需） | **知识点** | **边缘计算关联性** | **学习资源** | |----------------------|-----------------------------------|----------------------------------| | **GraalVM Native** | 构建无JVM的轻量级安全容器 | [GraalVM官方文档](https://www.graalvm.org/) | | **内存屏障硬件实现** | NUMA架构下边缘节点数据一致性 | 《深入理解计算机系统》第6章 | | **TEE集成** | Intel SGX Enclave隐私计算保护 | [OpenEnclave SDK](https://openenclave.io/) | | **eBPF监控** | 内核级JVM行为审计（安全框架基础） | 《BPF Performance Tools》第11章 | #### 三、学习汇总与优先级建议 ```mermaid graph TD A[JVM核心] --> B[内存模型] A --> C[GC机制] A --> D[执行引擎] B --> B1(堆外内存管理) B --> B2(内存屏障) C --> C1(ZGC/Shenandoah) C --> C2(GC调优实战) D --> D1(字节码验证) D --> D2(JNI安全) style B1 stroke:#f66,stroke-width:2px style C1 stroke:#f66,stroke-width:2px style D2 stroke:#f66,stroke-width:2px ``` #### 四、刷题与实例验证方案 1. **刷题建议（LeetCode改造）** - 传统题：`Java内存泄漏排查` → **改造为** *"在512MB内存的边缘设备上，优化DirectByteBuffer缓存策略"* - 参考[^2]的GC监控方法，增加**资源约束条件**： ```bash # 限制容器资源 docker run -it --cpus=1 --memory=512m openjdk:17 ``` 2. **小实例设计** **边缘设备安全内存分配验证** ```java public class EdgeMemoryValidator { // 模拟边缘设备内存压力 static final int MAX_DIRECT_MEM = 100 * 1024 * 1024; // 100MB public static void main(String[] args) { List<ByteBuffer> buffers = new ArrayList<>(); try { while (true) { buffers.add(ByteBuffer.allocateDirect(2 * 1024 * 1024)); // 每次2MB System.out.println("已分配: " + (buffers.size() * 2) + "MB"); Thread.sleep(100); } } catch (OutOfMemoryError e) { System.err.println("堆外内存溢出! 最大分配: " + (buffers.size() * 2) + "MB"); } catch (InterruptedException ignored) {} } } ``` **运行参数**： `-XX:MaxDirectMemorySize=100m -Xmx50m` **观测点**： - 使用`jcmd <PID> VM.native_memory`监控堆外内存 - 通过[^2]提到的JConsole观察GC行为 #### 五、安全场景验证建议 1. **差分隐私保护实验** - 在JNI层实现拉普拉斯噪声注入： ```c // JNI 代码片段 JNIEXPORT jdouble JNICALL Java_PrivacyEngine_addNoise(JNIEnv *env, jobject obj, jdouble value) { double noise = laplace_noise(0.0, 1.0); // ϵ=1.0的拉普拉斯噪声 return value + noise; } ``` 2. **安全监控实践** - 部署**Prometheus+JMX Exporter**： ```yaml # prometheus.yml 配置片段 - job_name: 'edge_jvm' static_configs: - targets: ['edge-device-ip:9091'] # 边缘设备暴露的JMX端口 ``` --- ### 相关问题 1. 如何在资源受限的边缘设备实现JVM安全热升级？ 2. ZGC的`-XX:SoftMaxHeapSize`参数对边缘计算有何特殊价值？ 3. 如何通过JVM沙箱防止差分隐私算法被恶意篡改？ 4. 在可信执行环境（TEE）中部署JVM需要考虑哪些安全因素？ 5. 如何利用eBPF跟踪JVM堆外内存泄漏？ > **关键提醒**：边缘计算场景下，JVM学习需重点关注**内存精确控制**、**确定式延迟**和**可信执行**三要素。建议结合[OpenJDK Panama项目](https://openjdk.org/projects/panama/)探索硬件原生交互，这将直接支撑你的隐私路径研究[^1]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值