一、CEPH 简介 不管你是想为云平台提供Ceph 对象存储或Ceph 块设备，还是想部署一个Ceph 文件系统或者把 Ceph 作为他用，所有Ceph 存储集群的部署都始于部署一个个Ceph 节点、网络和 Ceph 存储集群。 Ceph 存储集群至少需要一个 Ceph Monitor 和两个 OSD 守护进程。而运行 Ceph 文件系统客户端时，则必须要有元数据服务器（ Metadata Server ）。 **Ceph OSDs：**Ceph OSD 守护进程（ Ceph OSD ）的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，但你可以调整副本数）。 **Monitors：**Ceph Monitor维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息（称为 epoch ）。 **MDSs：**Ceph 元数据服务器（ MDS ）为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。元数据服务器使得 POSIX 文件系统的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。 Ceph 把客户端数据保存为存储池内的对象。通过使用 CRUSH 算法， Ceph 可以计算出哪个归置组（PG）应该持有指定的对象(Object)，然后进一步计算出哪个 OSD 守护进程持有该归置组。 CRUSH 算法使得 Ceph 存储集群能够动态地伸缩、再均衡和修复。...

一、概述 分布式文件系统是分布式领域的一个基础应用，其中最著名的毫无疑问是 HDFS/GFS。如今该领域已经趋向于成熟，但了解它的设计要点和思想，对我们将来面临类似场景/问题时，具有借鉴意义。 并且，分布式文件系统并非只有 HDFS/GFS 这一种形态，在它之外，还有其他形态各异、各有千秋的产品形态，对它们的了解，也对扩展我们的视野有所俾益。 本文试图分析和思考，在分布式文件系统领域，我们要解决哪些问题、有些什么样的方案、以及各自的选择依据。 二、过去的样子 在几十年以前，分布式文件系统就已经出现了，以 Sun 在 1984 年开发的“Network File System (NFS)”为代表，那时候解决的主要问题，是网络形态的磁盘，把磁盘从主机中独立出来。 这样不仅可以获得更大的容量，而且还可以随时切换主机，还可以实现数据共享、备份、容灾等，因为数据是电脑中最重要的资产。 NFS 的数据通信图如下： 部署在主机上的客户端，通过 TCP/IP 协议把文件命令转发到远程文件 Server 上执行，整个过程对主机用户透明。 到了互联网时代，流量和数据快速增长，分布式文件系统所要解决的主要场景变了，开始需要非常大的磁盘空间，这在磁盘体系上垂直扩容是无法达到的，必须要分布式，同时分布式架构下，主机都是可靠性不是非常好的普通服务器，因此容错、高可用、持久化、伸缩性等指标，就成为必须要考量的特性。 三、对分布式文件系统的要求 对一个分布式文件系统而言，有一些特性是必须要满足的，否则就无法有竞争力。主要如下： 应该符合 POSIX 的文件接口标准，使该系统易于使用，同时对于用户的遗留系统也无需改造； 对用户透明，能够像使用本地文件系统那样直接使用； 持久化，保证数据不会丢失； 具有伸缩性，当数据压力逐渐增长时能顺利扩容； 具有可靠的安全机制，保证数据安全； 数据一致性，只要文件内容不发生变化，什么时候去读，得到的内容应该都是一样的。 除此之外，还有些特性是分布式加分项，具体如下： 支持的空间越大越好； 支持的并发访问请求越多越好； 性能越快越好； 硬件资源的利用率越高越合理，就越好。 四、架构模型 从业务模型和逻辑架构上，分布式文件系统需要这几类组件： 存储组件：负责存储文件数据，它要保证文件的持久化、副本间数据一致、数据块的分配 / 合并等等； 管理组件：负责 meta 信息，即文件数据的元信息，包括文件存放在哪台服务器上、文件大小、权限等，除此之外，还要负责对存储组件的管理，包括存储组件所在的服务器是否正常存活、是否需要数据迁移等； 接口组件：提供接口服务给应用使用，形态包括 SDK(Java/C/C++ 等)、CLI 命令行终端、以及支持 FUSE 挂载机制。 而在部署架构上，有着“中心化”和“无中心化”两种路线分歧，即是否把“管理组件”作为分布式文件系统的中心管理节点。两种路线都有很优秀的产品，下面分别介绍它们的区别。 1、有中心节点 以 GFS 为代表，中心节点负责文件定位、维护文件 meta 信息、故障检测、数据迁移等管理控制的职能，下图是 GFS 的架构图： 该图中GFS master 即为 GFS 的中心节点，GF chunkserver 为 GFS 的存储节点。其操作路径如下：...

1.接口 1.1黑马信息管理系统集合改进 (应用) 使用数组容器的弊端 容器长度是固定的，不能根据添加功能自动增长 没有提供用于赠删改查的方法 优化步骤 创建新的StudentDao类，OtherStudentDao 创建ArrayList集合容器对象 OtherStudentDao中的方法声明，需要跟StudentDao保持一致 注意：如果不一致，StudentService中的代码就需要进行修改 完善方法（添加、删除、修改、查看） 替换StudentService中的Dao对象 代码实现 OtherStudentDao类 public class OtherStudentDao { // 集合容器 private static ArrayList<Student> stus = new ArrayList<>(); static { Student stu1 = new Student("heima001","张三","23","1999-11-11"); Student stu2 = new Student("heima002","李四","24","2000-11-11"); stus.add(stu1); stus....

1. 继承 1.1 继承的实现（掌握） 继承的概念 继承是面向对象三大特征之一，可以使得子类具有父类的属性和方法，还可以在子类中重新定义，以及追加属性和方法 实现继承的格式 继承通过extends实现 格式：class 子类 extends 父类 { } 举例：class Dog extends Animal { } 继承带来的好处 继承可以让类与类之间产生关系，子父类关系，产生子父类后，子类则可以使用父类中非私有的成员。 示例代码 public class Fu { public void show() { System.out.println("show方法被调用"); } } public class Zi extends Fu { public void method() { System.out.println("method方法被调用"); } } public class Demo { public static void main(String[] args) { //创建对象，调用方法 Fu f = new Fu(); f....

1.案例驱动模式 1.1案例驱动模式概述 (理解) 通过我们已掌握的知识点,先实现一个案例,然后找出这个案例中,存在的一些问题,在通过新知识点解决问题 1.2案例驱动模式的好处 (理解) 解决重复代码过多的冗余,提高代码的复用性 解决业务逻辑聚集紧密导致的可读性差,提高代码的可读性 解决代码可维护性差,提高代码的维护性 2.分类思想 2.1分类思想概述 (理解) 分工协作,专人干专事 2.2黑马信息管理系统 (理解) Student类 标准学生类,封装键盘录入的学生信息(id , name , age , birthday) StudentDao类 Dao : (Data Access Object 缩写) 用于访问存储数据的数组或集合 StudentService类 用来进行业务逻辑的处理(例如: 判断录入的id是否存在) StudentController类 和用户打交道(接收用户需求,采集用户信息,打印数据到控制台) 3.分包思想 3.1分包思想概述 (理解) 如果将所有的类文件都放在同一个包下,不利于管理和后期维护,所以,对于不同功能的类文件,可以放在不同的包下进行管理 3.2包的概述 (记忆) 包 本质上就是文件夹 创建包 多级包之间使用 " . " 进行分割 多级包的定义规范：公司的网站地址翻转(去掉www) 比如：黑马程序员的网站址为www.itheima.com 后期我们所定义的包的结构就是：com.itheima.其他的包名 包的命名规则...

1.Git介绍 1.1版本控制(理解) 无论是代码编写，还是文档编写，我们都会遇到对文档内容反复修改的情况 1.2开发中存在的问题(理解) 程序员小明负责的模块就要完成了，就在即将提交发布之前的一瞬间，电脑突然蓝屏，硬盘光荣下岗！ 几个月来的努力付之东流 老王需要在项目中加入一个很复杂的功能，一边尝试，一边修改代码，就这样摸索了一个星期。 可是这被改得面目全非的代码已经回不到从前了。 小明和老王先后从文件服务器上下载了同一个文件 因项目中Bug过多，导致项目进度拖延，项目经理老徐因此被骂，但不清楚Bug是手下哪一个程序员写的 开发中要解决的问题 代码备份 版本控制 协同工作 责任追溯 1.3SVN版本控制(理解) SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而开发人员工作的时候，用的都是自己的电脑， 所以首先要从中央服务器下载最新的版本，然后开发，开发完后，需要把自己开发的代码提交到中央服务器。 服务器单点故障 将会导致所有人员无法工作 而服务器硬盘损坏 这意味着，你可能失去了该项目的所有历史记录，这是毁灭性的。 1.4Git版本控制(理解) Git是在2005年，Linux系统的创建者Linus Torvalds,为了帮助全球的开发者，维护Linux系统内核的开发 而开发了自己的开源分布式版本控制工具,分为两种类型的仓库：本地仓库和远程仓库。 每一个客户端都保存了完整的历史记录 服务器的故障，都可以通过客户端的记录得以恢复。 2.Git下载和安装 2.1Git的下载(应用) 官网下载地址：https://git-scm.com/downloads 2.2Git的安装(应用) 双击安装包，进入安装向导界面 指定安装目录 一路next下一步 等待安装 安装完成...

1.ArrayList 集合和数组的区别 : ​ 共同点：都是存储数据的容器 ​ 不同点：数组的容量是固定的，集合的容量是可变的 1.1 -ArrayList的构造方法和添加方法 public ArrayList() 创建一个空的集合对象 public boolean add(E e) 将指定的元素追加到此集合的末尾 public void add(int index,E element) 在此集合中的指定位置插入指定的元素 ArrayList<E> ： ​ 可调整大小的数组实现 ​ <E> : 是一种特殊的数据类型，泛型。 怎么用呢 ? ​ 在出现E的地方我们使用引用数据类型替换即可 ​ 举例：ArrayList<String>, ArrayList<Student> 1.2ArrayList类常用方法【应用】 **成员方法 : ** public boolean remove(Object o) 删除指定的元素，返回删除是否成功 public E remove(int index) 删除指定索引处的元素，返回被删除的元素 public E set(int index,E element) 修改指定索引处的元素，返回被修改的元素 public E get(int index) 返回指定索引处的元素 public int size() 返回集合中的元素的个数 示例代码 :...

前言 因资源成本问题，本Harbor高可用架构为最小开销方案，如果资源充足，可以将PG、Redis全部使用使用云厂商集群模式。 同时为了配置简单，并没有使用keepalived与heartbeat等高可用开源组件。 准备工作 阿里云SLB 阿里云ECS 共享存储 Redis 最小实例SLB 2c4g 2台 阿里云NFS 阿里云Redis 操作系统为Ubuntu18.04，在2台ECS上搭建主从PG，如果不想用阿里云redis，也可以使用ECS搭建Redis。 安装Harbor，用于导出基础harbor数据，恢复到PG集群中. 安装docker-compose curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose sudo add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs)stable" # 添加国内阿里云 curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add - #更新 sudo apt-get update [[查看docker]]版本 apt-cache madison docker-ce #安装最新版 sudo apt-get install -y docker-ce [[安装5]]:19....

背景 容器技术的一个最佳实践是构建尽可能精简的容器镜像。但这一实践却会给排查问题带来麻烦：精简后的容器中普遍缺失常用的排障工具，部分容器里甚至没有 shell (比如 FROM scratch ）。 在这种状况下，我们只能通过日志或者到宿主机上通过 docker-cli 或 nsenter 来排查问题，效率很低，在K8s环境部署应用后，经常遇到需要进入pod进行排错。除了查看pod logs和describe方式之外，传统的解决方式是在业务pod基础镜像中提前安装好procps、net-tools、tcpdump、vim等工具。但这样既不符合最小化镜像原则，又徒增Pod安全漏洞风险。 今天为大家推荐一款K8s pod诊断工具，kubectl-debug是一个简单、易用、强大的 kubectl 插件, 能够帮助你便捷地进行 Kubernetes 上的 Pod 排障诊断。它通过启动一个排错工具容器，并将其加入到目标业务容器的pid, network, user 以及 ipc namespace 中，这时我们就可以在新容器中直接用 netstat, tcpdump 这些熟悉的工具来解决问题了, 而业务容器可以保持最小化, 不需要预装任何额外的排障工具。 kubectl-debug 主要包含以下两部分: kubectl-debug：命令行工具 debug-agent：部署在K8s的node上，用于启动关联排错工具容器 工作原理 我们知道，容器本质上是带有 cgroup 资源限制和 namespace 隔离的一组进程。因此，我们只要启动一个进程，并且让这个进程加入到目标容器的各种 namespace 中，这个进程就能 “进入容器内部”（注意引号），与容器中的进程”看到”相同的根文件系统、虚拟网卡、进程空间了——这也正是 docker exec 和 kubectl exec 等命令的运行方式。 现在的状况是，我们不仅要 “进入容器内部”，还希望带一套工具集进去帮忙排查问题。那么，想要高效管理一套工具集，又要可以跨平台，最好的办法就是把工具本身都打包在一个容器镜像当中。 接下来，我们只需要通过这个”工具镜像”启动容器，再指定这个容器加入目标容器的的各种 namespace，自然就实现了 “携带一套工具集进入容器内部”。事实上，使用 docker-cli 就可以实现这个操作： export TARGET_ID=666666666 # 加入目标容器的 network, pid 以及 ipc namespace docker run -it --network=container:$TARGET_ID --pid=container:$TARGET_ID --ipc=container:$TARGET_ID busybox 这就是 kubectl-debug 的出发点： 用工具容器来诊断业务容器 。背后的设计思路和 sidecar 等模式是一致的：每个容器只做一件事情。...

1.API 1.1 API概述-帮助文档的使用 什么是API ​ API (Application Programming Interface) ：应用程序编程接口 java中的API ​ 指的就是 JDK 中提供的各种功能的 Java类，这些类将底层的实现封装了起来，我们不需要关心这些类是如何实现的，只需要学习这些类如何使用即可，我们可以通过帮助文档来学习这些API如何使用。 如何使用API帮助文档 : 打开帮助文档 找到索引选项卡中的输入框 在输入框中输入Random 看类在哪个包下 看类的描述 看构造方法 看成员方法 1.2 键盘录入字符串 Scanner类 : ​ next() : 遇到了空格, 就不再录入数据了 , 结束标记: 空格, tab键 ​ nextLine() : 可以将数据完整的接收过来 , 结束标记: 回车换行符 代码实现 : package com....