总结
谈到面试，其实说白了就是刷题刷题刷题，天天作死的刷。。。。。
为了准备这个“金三银四”的春招，狂刷一个月的题，狂补超多的漏洞知识，像这次美团面试问的算法、数据库、Redis、设计模式等这些题目都是我刷到过的
并且我也将自己刷的题全部整理成了PDF或者Word文档（含详细答案解析）
66个Java面试知识点
架构专题（MySQL，Java，Redis，线程，并发，设计模式，Nginx，Linux，框架，微服务等）+大厂面试题详解（百度，阿里，腾讯，华为，迅雷，网易，中兴，北京中软等）
算法刷题（PDF）
==========================================================================
DADI 没有直接使用 overlayfs，或者说，它只是借鉴了 overlayfs 和早期联合文件系统（union filesystem）的思想，但提出了一种全新的基于块设备的分层堆叠技术，称之为 overlaybd，它为容器镜像提供了一系列基于块的合并数据视图。overlaybd 的实现十分简单，因此很多之前想做而不能做的事都可以成为现实；而实现一个完全 POSIX 兼容的文件系统接口则充满挑战，并可能存在 bug，这点从各个主流文件系统的发展历史上就可以看出。
除了简单以外，overlaybd 对比 overlayfs 的其他优点有：
-
避免多层镜像导致的性能下降，如 overlayfs 模式下大文件的更新会触发跨层引用复制，系统必须先将文件复制到可写层；或者创建硬链接速度很慢等问题。
-
可以方便地采集 block 级别的 I/O 模式，进行录制以及重放，从而预取数据，进一步加速启动。
-
用户的文件系统和宿主机 OS 可以灵活选择，如支持 Windows NTFS。
-
可以使用有效的编解码器进行在线解压缩。
-
可以下沉到云中的分布式存储（如 EBS）中，镜像系统盘可以跟数据盘使用同一套存储方案。
-
overlaybd 具有天然的可写层支持（RW），只读挂载甚至可以成为历史。
=================================================================================
为了理解 overlaybd 的原理，首先需要了解容器镜像的分层机制。容器镜像由多个增量 layer 文件组成，在使用时进行叠加，这样在镜像分发时只需要对 layer 文件进行分发。每一层实质上都是与上一层的差异（包括文件的添加，修改或删除）的压缩包。容器引擎可以通过其 storage driver，按照约定的方式将差异叠加起来，然后以 Read-Only 的模式挂载到指定目录，该目录即称为 lower_dir；而以 Read/Write 模式挂载的可写层，挂载目录则一般称为 upper_dir。
请注意，overlaybd 本身没有文件的概念，它只是将镜像抽象为虚拟块设备，并在其上装载常规的文件系统。当用户应用读取数据时，该读取请求首先由常规的文件系统处理，将请求转换为虚拟块设备的一次或多次读取。这些读取请求会被转发到用户态的接收程序，即 overlaybd 的运行时载体，最后转换为对一个或多个 layer 的随机读取。
与传统镜像一样，overlaybd 在内部仍然保留着 layer 分层的结构，但每层的内容都是文件系统变更差异对应的一系列 data block。overlaybd 向上提供了一个合并视图，对 layer 的叠加规则很简单，即对于任意一个 data block，总是使用最后的变更，在 layer 中未发生变更的块均视为全零块；向下又提供了将一系列 data block 导出成一个 layer 文件的功能，该文件高密度非稀疏、且可索引。因此，对块设备某个连续 LBA 范围进行读操作，可能包含了原本属于多层的小块数据段，我们将这些小块数据段称为 segment。从 segment 的属性中找到层号，便能够继续映射到对这层的 layer 文件的读取上来。传统的容器镜像可以将它的 layer 文件保存在 Registry 或者对象存储上，那么 overlaybd 镜像自然也可以。
为了更好的兼容性，overlaybd 在 layer 文件的最外层，包装了一层 tar 文件的头和尾，这样伪装成一个 tar 文件。由于 tar 内部仅一个文件，不影响按需读取。目前无论是 docker、containerd 或者 buildkit，对镜像的下载或上传默认都有 untar 和 tar 的流程，不侵入代码是无法逾越的，所以增加 tar 伪装有利于兼容性和流程的统一，例如在镜像转换、构建、或者全量下载使用时，都无需修改代码，只需提供插件即可。
=========================================================================
DADI 整体架构如图，以下分别介绍各个组件：
containerd 自 1.4 版起，开始初步支持一些启动远程镜像的功能，并且 K8s 已经明确将放弃 Docker 作为运行时的支持。所以 DADI 开源版本选择优先支持 containerd 生态，之后再支持 Docker。
snapshotter 的核心功能是实现抽象的服务接口，用于容器 rootfs 的挂载和卸载等操作。它的设计替代了在 Docker 早期版本称之为 graphdriver 的模块，使得存储驱动更加简化，同时兼容了块设备快照与 overlayfs。
DADI 提供的 overlaybd-snapshotter 一方面能让容器引擎支持新的 overlaybd 格式的镜像，即将虚拟块设备挂载到对应的目录，另一方面也兼容传统 OCI tar 格式镜像，让用户继续以 overlayfs 运行普通容器。
iSCSI 是一种被广泛支持的远程块设备协议，稳定成熟性能高，遇到故障可恢复。overlaybd 模块作为 iSCSI 协议的后端存储，即使程序意外 crash，重新拉起即可恢复。而基于文件系统的镜像加速方案，例如 stargz，则无法恢复。
iSCSI target 是 overlaybd 的运行时载体。在本项目中，我们实现了两种 target 模块：第一种是基于开源项目 tgt，由于其拥有 backing store 机制，可以将代码编译成动态链接库以便运行时加载；第二种是基于 Linux 内核的 LIO SCSI target（又称为 TCMU），整个 target 运行在内核态，可以比较方便地输出虚拟块设备。
ZFile 是我们提供的一种支持在线解压的数据压缩格式。它将源文件按固定大小的 block size 切分，各数据块进行单独压缩，同时维护一个 jump table，记录了各数据块在 ZFile 中的物理偏移位置。如需从 ZFile 中读数据，只要查找索引找到对应位置，并仅解压缩相关的 data block 即可。
ZFile 支持各种有效的压缩算法，包括 lz4，zstd 等，它解压速度极快，开销低，可以有效节省存储空间和数据传输量。实验数据表明，按需解压远程的 ZFile 数据，性能高于加载非压缩数据，这是因为传输节省的时间，大于解压的额外开销。
overlaybd 支持将 layer 文件导出成 ZFile 格式。
正如上文所说，layer 文件保存在 Registry 上，容器对块设备的读 I/O 会映射到对 Registry 的请求上（这里利用到了 Registry 对 HTTP Partial Content 的支持）。但是由于 cache 机制的存在，这种情形不会一直存在。cache 会在容器启动后的一段时间后自动开始下载 layer 文件，并持久化到本地文件系统。如果 cache 命中，则读 I/O 就不会再发给 Registry，而是读本地。
=========================================================================
3 月 25 日，权威咨询机构 Forrester 发布 2021 年第一季度 FaaS 平台（Function-As-A-Service Platforms）评估报告，阿里云凭借产品能力全球第一的优势脱颖而出，在八个评测维度中拿到最高分，成为比肩亚马逊 AWS 的全球 FaaS 领导者。这也是首次有国内科技公司进入 FaaS 领导者象限。
众所周知，容器是 FaaS 平台的承载基础，而容器启动速度更是决定了整个平台的性能与响应延迟。DADI 助力阿里云函数计算产品，大幅度缩短容器启动时间 50%~80%，带来了全新的 Serverless 使用体验。
=========================================================================
最后
终极手撕架构师的学习笔记：分布式+微服务+开源框架+性能优化
笔记+最新讲解视频+实战项目源码】](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**
1106
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
