如下图所示，给大家一个直观的认识：Diffusion Model分为前向过程和反向过程，前向过程将输入图$x_{0}$变为纯高斯噪声$x_{T}$，反向过程就是将噪声$x_{T}$还原为图片$x_{0}$的过程（就是一个不断去噪的过程）
给定真实图片$x_0 \sim q(x)$，前向过程中diffusion model对其添加了$T$次高斯噪声，分别得到图$x_{0},x_{1},…,x_{T}$（随着$t$的增加，$x$包含越来越多的噪声），这个过程如下表示
下图展示了前向加噪的过程中图片的变化，从左到右为$x_{0},x_{1},…,x_{T}$
推荐理由：本文是DDPM的奠基之作，是本领域最经典的论文之一。其实扩散模型并不是一个新的概念，这篇论文第一个给出了严谨的数学推导，可以复现的代码，完善了整个推理过程。后面diffusion models相关的论文基本都继承了前向加噪-反向降噪-训练这样的体系。所以强烈推荐初学者精读这篇论文！
推荐理由：作者使用简单的重参数化和混合学习目标来学习反向过程方差，该目标将VLB与DDPM的简化目标相结合。在混合目标下，所提出模型获得的对数似然比通过直接优化对数似然获得的对数似然更好，并发现后一个目标在训练期间具有更多的梯度噪声。最关键的是，原先的DDPM需要长达1000steps的推理步骤，而DDIM改善了反向扩散过程中的噪声水平，改变了递推公式，在更少的推理步骤(如100步)上取得了更好的结果。这项成果堪称革命性的，后面的大部分diffusion models论文(特别是运算量高的)都采用这一改进技术。
一款产品从开发到上线，从操作系统，到运行环境，再到应用配置。作为开发+运维之间的协作我们需要关心很多东西，这也是很多互联网公司都不得不面对的问题，特别是各种版本的迭代之后，不同版本环境的兼容，对运维人员是极大的考验！
环境配置如此麻烦，换一台机器，就要重来一次，费力费时。很多人想到，能不能从根本上解决问题，软件可以带环境安装？也就是说，安装的时候，把原始环境一模一样地复制过来。解决开发人员说的“ 在我的机器上可正常工作”的问题。
之前在服务器配置一个应用的运行环境，要安装各种软件，就拿一个基本的工程项目的环境来说吧，Java/Tomcat/MySQL/JDBC驱动包等。安装和配置这些东西有多麻烦就不说了，它还不能跨平台。假如我们是在 Windows 上安装的这些环境，到了 Linux 又得重新装。况且就算不跨操作系统，换另一台同
样操作系统的服务器，要移植应用也是非常麻烦的。
传统上认为，软件编码开发/测试结束后，所产出的成果即是程序或是能够编译执行的二进制字节码文件等（Java为例）。而为了让这些程序可以顺利执行，开发团队也得准备完整的部署文件，让维运团队得以部署应用程式，开发需要清楚的告诉运维部署团队，用的全部配置文件+所有软件环境。不过，即便如此，仍然常常发生部署失败的状况。
Docker之所以发展如此迅速，也是因为它对此给出了一个标准化的解决方案。Docker镜像的设计，使得Docker得以打破过去「程序即应用」的观念。通过Docker镜像 ( images ) 将应用程序所需要的系统环境，由下而上打包，达到应用程序跨平台间的无缝接轨运作。
MySQL入门：
MySQL基础笔记可看 菜鸟教程
mysql基础视频教程 bilibili 上搜即可
MySQL进阶：
尚硅谷MySQL数据库高级
视频：https://www.bilibili.com/video/BV1KW411u7vy
笔记链接：https://pan.baidu.com/s/1GUzPFVG3Je9uT419rHE8MQ
提取码：ybfi
黑马程序员2020最新MySQL高级教程
我刚开始看的是尚硅谷的，看了一半跑去看黑马的了
这两教程内容都差不多，黑马的更多一些
推荐书籍：《深入浅出mysql》
视频内容围绕着这本书上内容讲的
本章节主要介绍应用程序在服务器上部署方式演变以及kubernetes的概念、组件和工作原理。
在部署应用程序的方式上，主要经历了三个时代：
传统部署：互联网早期，会直接将应用程序部署在物理机上
优点：简单，不需要其它技术的参与
缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产生影响
虚拟化部署：可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境
优点：程序环境不会相互产生影响，提供了一定程度的安全性
缺点：增加了操作系统，浪费了部分资源
容器化部署：与虚拟化类似，但是共享了操作系统
优点：
可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等
运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦
容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署
文档对应的视频来自bibi黑马程序员MongoDB基础入门到高级进阶
Message Queue（MQ），消息队列中间件。很多人都说：MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。一个分布式系统中两个模块之间通讯要么是HTTP，要么是自己开发的（rpc） TCP，但是这两种协议其实都是原始的协议。HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上WebServer，而且还不支持⻓连接（HTTP 2.0 的库根本找不到）。TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。MQ 所要做的就是在这些协议之上构建一个简单的“协议”——生产者/消费者模型。MQ 带给我的“协议”不是具体的通讯协议，而是更高层次通讯模型。它定义了两个对象——发送数据的叫生产者；接收数据的叫消费者， 提供一个SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议
MQ，Message Queue，是一种提供消息队列服务的中间件，也称为消息中间件，是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据。一般消息的体量不会很大。
从网上可以查看到很多的关于MQ用途的叙述，但总结起来其实就以下三点。
限流削峰
异步解耦
MQ(message queue)，从字面意思上看，本质是个队列，FIFO 先入先出，只不过队列中存放的内容是 message 而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常 见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不 用依赖其他服务。
举个例子，如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。