皮皮网

1.Linux软件管理-YUM工具及源码包
2.17款最佳开源免费的云记源码云记 wiki 知识文档工具
3.有道云笔记网页剪报插件无法使用解决办法
4.《了不起的Markdown》第六章
5.Alluxio 客户端源码分析
6.有道云笔记印象笔记evernote哪个更好

Linux软件管理-YUM工具及源码包

       YUM基本概述

       yum是RedHat及CentOS中的软件包管理器，提供自动解决依赖性关系、教程通过互联网下载以rpm结尾的云记源码云记包、安装软件包、教程简化命令等众多优势。云记源码云记具体来说，教程命理小程序源码包含以下几点：

       联网获取软件

       基于RPM管理

       自动解决依赖

       命令简单好记

       遵循生产最佳实践

       YUM源的云记源码云记配置

       为了成功使用yum工具安装或更新软件或系统，需要配置一个包含各种rpm软件包的教程repository，称为yum源或yum仓库。云记源码云记该仓库可为本地或网络源。教程

       BASE源：各大镜像源，云记源码云记如阿里云、教程清华大学、云记源码云记、教程华为云、云记源码云记中国科学技术大学等。

       EPEL源：安装其他特定源，如nginx、zabbix、saltstack等。

       YUM实践案例

       使用yum工具时，可执行以下操作：

       查询软件包：使用yum search关键字

       安装软件包：使用yum install 软件包名称

       重装软件包：使用yum reinstall 软件包名称

       更新软件包：使用yum update 软件包名称

       删除软件包：使用yum remove 软件包名称

       YUM全局配置文件[扩展]

       YUM的配置方式包括全局配置文件（/etc/yum.conf）和子配置文件（/etc/yum.repos.d/目录下的所有.repo文件）。

       YUM签名检查机制[扩展]

       rpm软件在构建rpm包时使用redhat的私钥签名，客户端使用redhat提供的公钥验证rpm包的合法性。可通过指定公钥位置、提前导入公钥或选择不进行签名验证来实现。

       制作本地YUM仓库

       自行制作本地YUM仓库时，需了解配置文件参数含义。操作步骤包括挂载镜像、备份原有仓库、创建新仓库文件、刷新repos生成缓存等。

       构建企业级YUM仓库

       本地光盘提供基础软件包（Base）、yum缓存提供update软件包、常用软件包如nginx、zabbix、docker、saltstack等。环境准备涉及IP、角色、主机名、服务端yum仓库及客户端使用等。

       源码包概述

       源码包指的是未编译成可运行工具的程序源代码。学习源码包有助于自定义软件、定制功能、优先更新源码及实现自动化规范。

       优点：二次开发、定制功能、优先更新、自动化规范

       缺点：相较于yum安装复杂、耗时较长

       源码包获取

       常见软件源码包可在官方网站获取。

       源码包安装步骤

       解压tar、生成configure或cmake、编译、安装。

       源码包安装实战

       通过编译Nginx深入理解源码包安装过程。

       源码编译报错信息处理

       在安装源码包时遇到问题，需妥善处理报错信息，确保安装过程顺利。

       自定义RPM包并制作YUM仓库[扩展]

       可自行定制RPM包及制作YUM仓库，实现软件自定义安装与管理。

款最佳开源免费的 wiki 知识文档工具

       Wiki知识文档工具是协作工作环境的重要组成部分，旨在提供一个平台，让团队成员能够共享、创建和编辑内容。企业共享信息的需求催生了改进知识管理的方法，而Wiki工具则提供了知识获取、管理与共享的途径，有效促进企业创新、提高生产力并支持决策。

       WiKi是一个多人协作写作的系统，与常见系统相比，WiKi具有以下特点：使用方便、自组织、可增长、开放性。市面上提供了多种开源免费的python网站实战源码WiKi在线协同办公文档平台，如字节跳动的飞书、蚂蚁的语雀、网易的有道云笔记、腾讯文档、石墨文档、金山文档、Microsoft 、Google Docs等。然而，对于企业使用来说，这些平台的费用可能较高。

       为了满足企业对成本敏感的需求，以下推荐个最佳开源免费的WiKi知识文档工具，这些工具支持私有化部署，确保数据安全。这些工具包括：OI-wiki、zyplayer-doc、MrDoc、smart-doc、torna、Matterwiki、mm-wiki、km_community、siyuan、WDA、SmartSQL、file-online-preview、DocHub、showdoc、CrapApi、koodo-reader、archivy。

       在众多工具中，例如OI-wiki是一个免费开放且持续更新的知识整合站点，致力于提供编程竞赛基础知识、常见题型、解题思路和常用工具等信息，帮助编程竞赛初学者系统学习。而zyplayer-doc是一款适合团队和个人私有化部署的知识库、笔记、WIKI文档管理系统，具有数据库管理、API接口管理等功能。MrDoc则是为个人和中小型团队设计的在线文档、知识库管理系统，支持私有化部署。

       同时，smart-doc是一个针对Java RESTful API和Apache Dubbo RPC接口文档生成的工具，能够基于接口源码分析生成易于理解的文档。torna则专注于接口文档管理的便利性和速度，通过团队协作维护文档，提供功能强大且灵活的权限管理、全文检索、多维检索、文件在线预览等功能。

       Matterwiki是一个全球知名的开源WiKi程序，适用于企业搭建百科、知识库查询等用途。mm-wiki是一个轻量级的团队知识分享与协作软件，易于部署和使用。km_community则基于Elasticsearch构建了强大的文件和知识管理系统，提供全文检索、多维检索、文件在线预览、版本控制、手机端支持等功能。siyuan是一个注重隐私的个人知识管理系统，支持块级引用和Markdown编辑器，便于创建和组织知识。

       此外，WDA工具实现了文档在线预览，并支持多种文档格式转换和预览。SmartSQL是一个数据库文档查询和生成工具，支持多种数据库查询和导出功能。file-online-preview提供了文档在线预览解决方案，易于部署且支持主流文档格式预览。交易国买源码DocHub则是一个适合IT团队的在线API文档和文档生成工具，支持markdown语法和自动化文档生成功能。CrapApi是一个开源的API接口管理系统，提供了API接口管理、文档管理、数据库表管理等功能。koodo-reader是一个跨平台的电子书阅读器，支持多种电子书格式阅读。archivy则是一个开源知识库，提供了可扩展的wiki，适用于学习笔记和信息保存。

       这些开源免费的WiKi知识文档工具各有特色和优势，企业可根据自身需求选择合适的工具，实现知识管理和协作的高效与安全。

有道云笔记网页剪报插件无法使用解决办法

       对于有道云笔记网页剪报插件无法使用的解决办法，根据最新更新，可以通过以下步骤解决：

       首先，请前往官网下载并安装最新版本的插件（目前版本为2.1.3），确保浏览器（如最新版的chrome, .0..）兼容。适用于所有Chromium内核大于小于的浏览器，包括新版edge。

       接下来，执行以下步骤以解决兼容性问题：

       打开chrome://flags/#cors-for-content-scripts并将其设置为Disabled

       然后，打开chrome://flags/#same-site-by-default-cookies并将其设置为Disabled

       完成上述设置后，请重启浏览器。如果遇到选项被自动重置为Default的情况，请重新修改设置。

       对于一些用户而言，可能需要使用替代方法。为此，有道云笔记官网提供了另一种解决方案：

       安装名为Disable Content-Security-Policy的插件。若无法通过正常途径安装，可通过开发者模式或百度搜索相关教程，使用源码直接安装。

       安装插件后，请打开有道云笔记的下载页面并将按钮拖动至书签栏。在想要保存的网页中使用扩展图标，点击后书签链接将生效。

       然而，需要注意的是，该方法存在一定的不便之处，用户每次点击新的链接都需要再次激活扩展图标。对于插件重度使用用户，推荐使用其他Chromium内核低于的浏览器，例如百分浏览器。

       针对chrome .0..版本中删除的chrome://flags/#cors-for-content-scripts选项，插件可能再次失效。同样，最新版edge Chromium内核版本为.0..，也存在兼容性问题。因此，建议插件重度使用用户选择其他兼容性更好的浏览器。

《了不起的Markdown》第六章

       笔记软件是现代人记录重要信息、事件与想法的重要工具。Markdown作为一种简洁的文本格式标记语言，因其专注且高效的写作特点，在笔记软件中大放异彩。以下介绍几款流行的笔记软件及其与Markdown的结合：

       印象笔记

       印象笔记支持基础Markdown语法与GFM语法，用户可以快速绘制数学公式、流程图、时序图、甘特图，并提供多种图表绘制功能。在印象笔记中新建Markdown笔记，可通过左上角的新建Markdown笔记按钮或快捷键实现。默认编辑模式下，左侧为源码，右侧为预览。工具栏提供常用标记的快速插入功能，包括图表模板。使用添加流程图功能后，可快速插入流程图模板。印象笔记支持四种图表：饼图、折线图、柱状图、条形图，广告跳转html源码预览界面支持交互操作。上传、直接拖拽添加或从剪切板粘贴均支持，大小可通过右键菜单调整。导出Markdown格式或转换为PDF文件亦可实现。

       有道云笔记

       有道云笔记支持Markdown功能，包括基础Markdown语法、代码高亮、任务列表、表格、数学公式等。在电脑端与Web端，新建Markdown文件可通过右键菜单中的新文档选项完成。手机端则在+按钮中选择Markdown。在Markdown编辑环境中，常用语法可通过工具栏的快速插入图标直接使用。有道云笔记还提供快速插入公式与图表模板的功能，简化了创建图表的过程。

       OneNote

       OneNote本身不直接支持Markdown，但通过插件可以实现Markdown功能。插件可在网站上下载，适用于Windows版本。

       在线多人协作工具

       在线文档协作工具如腾讯文档和石墨文档，支持简单的Markdown语法，如标题、分隔线、列表等，且在编辑时直接通过“标记符号+空格”使用Markdown，效果实时显示。

       写博客

       知乎支持基础Markdown语法，通过“标记符号+空格”对文字进行排版。简书与CSDN也分别支持Markdown编辑器，其中CSDN的Markdown编辑器功能齐全，可以导入/导出Markdown文件，解析GFM语法。

       写微信公众号文章

       对于写微信公众号文章，Markdown虽然方便，但某些格式在微信编辑器中不支持。推荐使用Online-Markdown或Md2All等在线格式化工具，将Markdown文档渲染为适合微信公众号的格式。

       写邮件

       Markdown Here插件允许用户在邮件编辑器中使用Markdown语法，通过该插件，Markdown编辑器直接集成在邮件编辑器中，实现Markdown写作，简化了邮件写作流程。

       其他常见工具

       锤子便签支持Markdown语法，适用于文字排版；DayOne日记软件支持Markdown对日记进行排版，使用简单；交互式文档工具如Jupyter Notebook与R Markdown，分别在数据分析与技术写作领域提供强大的功能支持，支持代码的实时执行与显示结果。Markdown页编写工具md-page允许直接使用Markdown编写网页，无需转换格式。项目文档写作工具如MkDocs与VuePress，提供快速创建项目文档的解决方案，支持Markdown编写。

       付费软件方面，如Ulysses、MWeb、MarkdownPad与CMD Markdown等提供更专业的服务与更好的用户体验，适合不同需求的用户群体。

       小结

       本文详细介绍了多个专业Markdown工具，旨在帮助用户根据不同的写作场景选择合适的工具。从记笔记、写博客、写邮件、编写技术文档到创建交互式文档，Markdown工具提供了丰富的功能与便捷的体验，满足了现代写作的多样化需求。

Alluxio 客户端源码分析

       Alluxio是一个用于云分析和人工智能的开源数据编排技术，作为分布式文件系统，采用与HDFS相似的主从架构。系统中包含一个或多个Master节点存储集群元数据信息，以及Worker节点管理缓存的数据块。本文将深入分析Alluxio客户端的实现。

       创建客户端逻辑在类alluxio.client.file.FileSystem中，简单示例代码如下。XDMA WINDOWS源码解析

       客户端初始化包括调用FileSystem.Context.create创建客户端对象的上下文，在此过程中需要初始化客户端以创建与Master和Worker连接的连接池。若启用了配置alluxio.user.metrics.collection.enabled，将启动后台守护线程定时与Master节点进行心跳传输监控指标信息。同时，客户端初始化时还会创建负责重新初始化的后台线程，定期从Master拉取配置文件的哈希值，若Master节点配置发生变化，则重新初始化客户端，期间阻塞所有请求直到重新初始化完成。

       创建具有缓存功能的客户端在客户端初始化后，调用FileSystem.Factory.create进行客户端创建。客户端实现分为BaseFileSystem、MetadataCachingBaseFileSystem和LocalCacheFileSystem三种，其中MetadataCachingBaseFileSystem和LocalCacheFileSystem对BaseFileSystem进行封装，提供元数据和数据缓存功能。BaseFileSystem的调用主要分为三大类：纯元数据操作、读取文件操作和写入文件操作。针对元数据操作，直接调用对应GRPC接口（例如listStatus）。接下来，将介绍客户端如何与Master节点进行通信以及读取和写入的流程。

       客户端需要先通过MasterInquireClient接口获取主节点地址，当前有三种实现：PollingMasterInquireClient、SingleMasterInquireClient和ZkMasterInquireClient。其中，PollingMasterInquireClient是针对嵌入式日志模式下选择主节点的实现类，SingleMasterInquireClient用于选择单节点Master节点，ZkMasterInquireClient用于Zookeeper模式下的主节点选择。因为Alluxio中只有主节点启动GRPC服务，其他节点连接客户端会断开，PollingMasterInquireClient会依次轮询所有主节点，直到找到可以连接的节点。之后，客户端记录该主节点，如果无法连接主节点，则重新调用PollingMasterInquireClient过程以连接新的主节点。

       数据读取流程始于BaseFileSystem.openFile函数，首先通过getStatus向Master节点获取文件元数据，然后检查文件是否为目录或未写入完成等条件，若出现异常则抛出异常。寻找合适的Worker节点根据getStatus获取的文件信息中包含所有块的信息，通过偏移量计算当前所需读取的块编号，并寻找最接近客户端并持有该块的Worker节点，从该节点读取数据。判断最接近客户端的Worker逻辑位于BlockLocationUtils.nearest，考虑使用domain socket进行短路读取时的Worker节点地址一致性。根据配置项alluxio.worker.data.server.domain.socket.address，判断每个Worker使用的domain socket路径是否一致。如果没有使用域名socket信息寻找到最近的Worker节点，则根据配置项alluxio.user.ufs.block.read.location.policy选择一个Worker节点进行读取。若客户端和数据块在同一节点上，则通过短路读取直接从本地文件系统读取数据，否则通过与Worker节点建立GRPC通信读取文件。

       如果无法通过短路读取数据，客户端会回退到使用GRPC连接与选中的Worker节点通信。首先判断是否可以通过domain socket连接Worker节点，优先选择使用domain socket方式。创建基于GRPC的块输入流代码位于BlockInStream.createGrpcBlockInStream。通过GRPC进行连接时，每次读取一个chunk大小并缓存chunk，减少RPC调用次数提高性能，chunk大小由配置alluxio.user.network.reader.chunk.size.bytes决定。

       读取数据块完成后或出现异常终止，Worker节点会自动释放针对该块的写入锁。读取异常处理策略是记录失败的Worker节点，尝试从其他Worker节点读取，直到达到重试次数上限或没有可用的Worker节点。

       若无法通过本地Worker节点读取数据，则客户端尝试发起异步缓存请求。若启用了配置alluxio.user.file.passive.cache.enabled且存在本地Worker节点，则向本地Worker节点发起异步缓存请求，否则向负责读取该块数据的Worker节点发起请求。

       数据写入流程首先向Master节点发送CreateFile请求，Master验证请求合法性并返回新文件的基本信息。根据不同的写入类型，进行不同操作。如果是THROUGH或CACHE_THROUGH等需要直接写入底层文件系统的写入类型，则选择一个Worker节点处理写入到UFS的数据。对于MUST_CACHE、CACHE_THROUGH、ASYNC_THROUGH等需要缓存数据到Worker节点上的写入类型，则打开另一个流负责将每个写入的块缓存到不同的Worker上。写入worker缓存块流程类似于读取流程，若写入的Worker与客户端在同一个主机上，则使用短路写直接将块数据写入Worker本地，无需通过网络发送到Worker上。数据完成写入后，客户端向Master节点发送completeFile请求，表示文件已写入完成。

       写入失败时，取消当前流以及所有使用过的输出流，删除所有缓存的块和底层存储中的数据，与读取流程不同，写入失败后不进行重试。

       零拷贝实现用于优化写入和读取流程中WriteRequest和ReadResponse消息体积大的问题，通过配置alluxio.user.streaming.zerocopy.enabled开启零拷贝特性。Alluxio通过实现了GRPC的MethodDescriptor.Marshaller和Drainable接口来实现GRPC零拷贝特性。MethodDescriptor.Marshaller负责对消息序列化和反序列化的抽象，用于自定义消息序列化和反序列化行为。Drainable扩展java.io.InputStream，提供将所有内容转移到OutputStream的方法，避免数据拷贝，优化内容直接写入OutputStream的过程。

       总结，阅读客户端代码有助于了解Alluxio体系结构，明白读取和写入数据时的数据流向。深入理解Alluxio客户端实现对于后续阅读其他Alluxio代码非常有帮助。

有道云笔记印象笔记evernote哪个更好

       作为两者的忠实用户，说句心里话，还是印象笔记做的好，用户体验以及数据同步的稳定性，以及其他各个平台的稳定性，都做的比有道云笔记好。

       有道云笔记唯一的优点就是容量大，但是对于一个普通用户，5G的容量无非是噱头，意义不大。目前对容量的需求不是很大，每月M的容量足以存储每天的记录了，如果以后容量不够了，只要用户体验做的好，产品优秀，我想多数人还是愿意付费的。

       有道的体验做的就不是那么好了，比如当某个分类里面的笔记很多的时候，在多个分类之间点击切换的时候，就出现卡顿、程序界面假死的现象，甚至多次因网络不稳定导致程序界面不断地闪屏。还有多个平台同步不一致的问题，太多的bug，也曾多次向官方反馈，但是答复都不是那么令人满意，唯一一次令人“满意”的答复是：有道云笔记目前不支持网页剪辑的格式化显示。

在我的印象中，印象笔记从来都是支持网页剪辑内容的格式化显示。也许我用的时间短。

       还有最重要的一点是：网页剪辑的功能，不得不说有道云笔记这方面太差了，剪辑下来的网页格式化内容都没有了，有时候查资料，那些源码都是高亮显示的，但是用有道云笔记剪下来以后就排版乱了，彩色也没了，代码的格式化都没了，看起来很不好看，就算是以后查阅起来也不好查阅。

       通过下面的对比，我们通过“网页剪辑”功能进行对比，可以看出明显的诧异：

下面是原网页的显示：

       下面是有道云笔记剪辑下来的显示（我们可以看到，网页的绿色注释以及代码的格式化等等已经没有了）：

       下面是印象笔记（evernote）的网页剪辑：

            通过以上对比，我们可以看出，印象笔记的网页剪辑几乎全部保留了原网页的排版与布局，而有道云笔记剪辑并没有保留原网页的代码格式化以及风格。看来有道云笔记的网页剪辑这一块的问题还亟待解决。

云HIS源码，基于云计算的医院临床信息系统

       云HIS作为一款基于云计算的医院临床信息系统，整合了全面的商业源码，旨在优化医疗流程，提升效率。其核心功能包括但不限于：

       预约挂号与门急诊服务：患者可在线预约或现场挂号，实现便捷就诊。

       门诊流程：医生开具处方后，收费和发药流程自动化，确保高效。

       住院业务：从登记到出院，涉及长期医嘱、临时医嘱管理，电子病历记录全程透明。

       系统管理流程包括医生信息录入、排班设定、功能权限分配，以及按照门诊、住院的常规步骤执行相应功能模块，如挂号、收费、发药和病历填写等。同时，系统还具备自动化数据上报和与其他系统接口数据传输的能力，满足外部监管需求。

       无论是门诊还是住院，云HIS都提供了流畅且高效的服务流程，极大地简化了医院的日常运营，提高了医疗服务质量和效率。

Diffusion Model原理详解及源码解析

       Hello，大家好，我是小苏

       今天来为大家介绍Diffusion Model（扩散模型），在具体介绍之前呢，先来谈谈Diffusion Model主要是用来干什么的。其实啊，它对标的是生成对抗网络（GAN），只要GAN能干的事它基本都能干。在我一番体验Diffusion Model后，它给我的感觉是非常惊艳的。我之前用GAN网络来实现一些生成任务其实效果并不是很理想，而且往往训练很不稳定。但是换成Diffusion Model后生成的则非常逼真，也明显感觉到每一轮训练的结果相比之前都更加优异，也即训练更加稳定。

       说了这么多，我就是想告诉大家Diffusion Model值得一学。但是说实话，这部分的公式理解起来是有一定困难的，我想这也成为了想学这个技术的同学的拦路虎。那么本文将用通俗的语言和公式为大家介绍Diffusion Model，并且结合公式为大家梳理Diffusion Model的代码，探究其是如何通过代码实现的。如果你想弄懂这部分，请耐心读下去，相信你会有所收获。

       如果你准备好了的话，就让我们开始吧！！！

       Diffusion Model的整体思路如下图所示：

       其主要分为正向过程和逆向过程，正向过程类似于编码，逆向过程类似于解码。

       怎么样，大家现在的感觉如何？是不是知道了Diffusion Model大概是怎么样的过程了呢，但是又对里面的细节感到很迷惑，搞不懂这样是怎么还原出的。不用担心，后面我会慢慢为大家细细介绍。

       这一部分为大家介绍一下Diffusion Model正向过程和逆向过程的细节，主要通过推导一些公式来表示加噪前后图像间的关系。

       正向过程在整体思路部分我们已经知道了正向过程其实就是一个不断加噪的过程，于是我们考虑能不能用一些公式表示出加噪前后图像的关系呢。我想让大家先思考一下后一时刻的图像受哪些因素影响呢，更具体的说，比如[公式]由哪些量所决定呢？我想这个问题很简单，即[公式]是由[公式]和所加的噪声共同决定的，也就是说后一时刻的图像主要由两个量决定，其一是上一时刻图像，其二是所加噪声量。「这个很好理解，大家应该都能明白吧」明白了这点，我们就可以用一个公式来表示[公式]时刻和[公式]时刻两个图像的关系，如下：

       [公式] ——公式1

       其中，[公式]表示[公式]时刻的图像，[公式]表示[公式]时刻图像，[公式]表示添加的高斯噪声，其服从N(0,1)分布。「注：N(0,1)表示标准高斯分布，其方差为1，均值为0」目前可以看出[公式]和[公式]、[公式]都有关系，这和我们前文所述后一时刻的图像由前一时刻图像和噪声决定相符合，这时你可能要问了，那么这个公式前面的[公式]和[公式]是什么呢，其实这个表示这两个量的权重大小，它们的平方和为1。

       接着我们再深入考虑，为什么设置这样的权重？这个权重的设置是我们预先设定的吗？其实呢，[公式]还和另外一个量[公式]有关，关系式如下：

       [公式] ——公式2

       其中，[公式]是预先给定的值，它是一个随时刻不断增大的值，论文中它的范围为[0.,0.]。既然[公式]越来越大，则[公式]越来越小，[公式]越来越小，[公式]越来越大。现在我们在来考虑公式1，[公式]的权重[公式]随着时刻增加越来越大，表明我们所加的高斯噪声越来越多，这和我们整体思路部分所述是一致的，即越往后所加的噪声越多。

       现在，我们已经得到了[公式]时刻和[公式]时刻两个图像的关系，但是[公式]时刻的图像是未知的。我们需要再由[公式]时刻推导出[公式]时刻图像，然后再由[公式]时刻推导出[公式]时刻图像，依此类推，直到由[公式]时刻推导出[公式]时刻图像即可。

       逆向过程是将高斯噪声还原为预期的过程。先来看看我们已知条件有什么，其实就一个[公式]时刻的高斯噪声。我们希望将[公式]时刻的高斯噪声变成[公式]时刻的图像，是很难一步到位的，因此我们思考能不能和正向过程一样，先考虑[公式]时刻图像和[公式]时刻的关系，然后一步步向前推导得出结论呢。好的，思路有了，那就先来想想如何由已知的[公式]时刻图像得到[公式]时刻图像叭。

       接着，我们利用贝叶斯公式来求解。公式如下：

       那么我们将利用贝叶斯公式来求[公式]时刻图像，公式如下：

       [公式] ——公式8

       公式8中[公式]我们可以求得，就是刚刚正向过程求的嘛。但[公式]和[公式]是未知的。又由公式7可知，可由[公式]得到每一时刻的图像，那当然可以得到[公式]和[公式]时刻的图像，故将公式8加一个[公式]作为已知条件，将公式8变成公式9，如下：

       [公式] ——公式9

       现在可以发现公式9右边3项都是可以算的啦，我们列出它们的公式和对应的分布，如下图所示：

       知道了公式9等式右边3项服从的分布，我们就可以计算出等式左边的[公式]。大家知道怎么计算嘛，这个很简单啦，没有什么技巧，就是纯算。在附录->高斯分布性质部分我们知道了高斯分布的表达式为：[公式]。那么我们只需要求出公式9等式右边3个高斯分布表达式，然后进行乘除运算即可求得[公式]。

       好了，我们上图中得到了式子[公式]其实就是[公式]的表达式了。知道了这个表达式有什么用呢，主要是求出均值和方差。首先我们应该知道对高斯分布进行乘除运算的结果仍然是高斯分布，也就是说[公式]服从高斯分布，那么他的表达式就为 [公式]，我们对比两个表达式，就可以计算出[公式]和[公式]，如下图所示：

       现在我们有了均值[公式]和方差[公式]就可以求出[公式]了，也就是求得了[公式]时刻的图像。推导到这里不知道大家听懂了多少呢？其实你动动小手来算一算你会发现它还是很简单的。但是不知道大家有没有发现一个问题，我们刚刚求得的最终结果[公式]和[公式]中含义一个[公式]，这个[公式]是什么啊，他是我们最后想要的结果，现在怎么当成已知量了呢？这一块确实有点奇怪，我们先来看看我们从哪里引入了[公式]。往上翻翻你会发现使用贝叶斯公式时我们利用了正向过程中推导的公式7来表示[公式]和[公式]，但是现在看来那个地方会引入一个新的未知量[公式]，该怎么办呢？这时我们考虑用公式7来反向估计[公式]，即反解公式7得出[公式]的表达式，如下：

       [公式] ——公式

       得到[公式]的估计值，此时将公式代入到上图的[公式]中，计算后得到最后估计的 [公式]，表达式如下：

       [公式] ——公式

       好了，现在在整理一下[公式]时刻图像的均值[公式]和方差[公式]，如下图所示：

       有了公式我们就可以估计出[公式]时刻的图像了，接着就可以一步步求出[公式]、[公式]、[公式]、[公式]的图像啦。

       这一小节原理详解部分就为大家介绍到这里了，大家听懂了多少呢。相信你阅读了此部分后，对Diffusion Model的原理其实已经有了哥大概的解了，但是肯定还有一些疑惑的地方，不用担心，代码部分会进一步帮助大家。

       代码下载及使用本次代码下载地址： Diffusion Model代码

       先来说说代码的使用吧，代码其实包含两个项目，一个的ddpm.py，另一个是ddpm_condition.py。大家可以理解为ddpm.py是最简单的扩散模型，ddpm_condition.py是ddpm.py的优化。本节会以ddpm.py为大家讲解。代码使用起来非常简单，首先在ddpm.py文件中指定数据集路径，即设置dataset_path的值，然后我们就可以运行代码了。需要注意的是，如果你使用的是CPU的话，那么你可能还需要修改一下代码中的device参数，这个就很简单啦，大家自己摸索摸索就能研究明白。

       这里来简单说说ddpm的意思，英文全称为Denoising Diffusion Probabilistic Model，中文译为去噪扩散概率模型。

       代码流程图这里我们直接来看论文中给的流程图好了，如下：

       看到这个图你大概率是懵逼的，我来稍稍为大家解释一下。首先这个图表示整个算法的流程分为了训练阶段（Training）和采样阶段（Sampling）。

       我们在正向过程中加入的噪声其实都是已知的，是可以作为真实值的。而逆向过程相当于一个去噪过程，我们用一个模型来预测噪声，让正向过程每一步加入的噪声和逆向过程对应步骤预测的噪声尽可能一致，而逆向过程预测噪声的方式就是丢入模型训练，其实就是Training中的第五步。

       代码解析首先，按照我们理论部分应该有一个正向过程，其最重要的就是最后得出的公式7，如下：

       [公式]

       那么我们在代码中看一看是如何利用这个公式7的，代码如下：

       Ɛ为随机的标准高斯分布，其实也就是真实值。大家可以看出，上式的返回值sqrt_alpha_hat * x + sqrt_one_minus_alpha_hat其实就表示公式7。注：这个代码我省略了很多细节，我只把关键的代码展示给大家看，要想完全明白，还需要大家记住调试调试了

       接着我们就通过一个模型预测噪声，如下：

       model的结构很简单，就是一个Unet结构，然后里面嵌套了几个Transformer机制，我就不带大家跳进去慢慢看了。现在有了预测值，也有了真实值Ɛ返回后Ɛ用noise表示，就可以计算他们的损失并不断迭代了。

       上述其实就是训练过程的大体结构，我省略了很多，要是大家有任何问题的话可以评论区留言讨论。现在来看看采样过程的代码吧！！！

       上述代码关键的就是 x = 1 / torch.sqrt(alpha) * (x - ((1 - alpha) / (torch.sqrt(1 - alpha_hat))) * predicted_noise) + torch.sqrt(beta) * noise这个公式，其对应着代码流程图中Sampling阶段中的第4步。需要注意一下这里的跟方差[公式]这个公式给的是[公式]，但其实在我们理论计算时为[公式]，这里做了近似处理计算，即[公式]和[公式]都是非常小且近似0的数，故把[公式]当成1计算，这里注意一下就好。

       代码小结可以看出，这一部分我所用的篇幅很少，只列出了关键的部分，很多细节需要大家自己感悟。比如代码中时刻T的用法，其实是较难理解的，代码中将其作为正余弦位置编码处理。如果你对位置编码不熟悉，可以看一下我的 这篇文章的附录部分，有详细的介绍位置编码，相信你读后会有所收获。

       参考链接由浅入深了解Diffusion

       附录高斯分布性质高斯分布又称正态分布，其表达式为：

       [公式]

       其中[公式]为均值，[公式]为方差。若随机变量服X从正态均值为[公式]，方差为[公式]的高斯分布，一般记为[公式]。此外，有一点大家需要知道，如果我们知道一个随机变量服从高斯分布，且知道他们的均值和方差，那么我们就能写出该随机变量的表达式。

       高斯分布还有一些非常好的性质，现举一些例子帮助大家理解。

       版权声明：本文为奥比中光3D视觉开发者社区特约作者授权原创发布，未经授权不得转载，本文仅做学术分享，版权归原作者所有，若涉及侵权内容请联系删文。

       3D视觉开发者社区是由奥比中光给所有开发者打造的分享与交流平台，旨在将3D视觉技术开放给开发者。平台为开发者提供3D视觉领域免费课程、奥比中光独家资源与专业技术支持。

       加入 3D视觉开发者社区学习行业前沿知识，赋能开发者技能提升！加入 3D视觉AI开放平台体验AI算法能力，助力开发者视觉算法落地！

       往期推荐：1、 开发者社区「运营官」招募启动啦！ - 知乎 (zhihu.com)

       2、 综述：基于点云的自动驾驶3D目标检测和分类方法 - 知乎 (zhihu.com)

       3、 最新综述：基于深度学习方式的单目物体姿态估计与跟踪 - 知乎 (zhihu.com)

ribbon负载均衡详解

       æœåŠ¡ç«¯è´Ÿè½½å‡è¡¡ï¼šåœ¨å®¢æˆ·ç«¯å’ŒæœåŠ¡ç«¯ä¸­é—´ä½¿ç”¨ä»£ç†ï¼Œlvs  和 nginx。

        硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。

        客户端负载均衡：根据自己的情况做负载。Ribbon。

        客户端负载均衡和服务端负载均衡最大的区别在于 服务端地址列表的存储位置，以及负载算法在哪里。

        2、Spring Cloud的负载均衡机制的实现

        Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Ribbon实现客户端的负载均衡，负载均衡器提供很多对.netflix.client.conf.CommonClientConfigKey。

        <clientName>.<nameSpace>.NFLoadBalancerClassName=xx

        <clientName>.<nameSpace>.NFLoadBalancerRuleClassName=xx

        <clientName>.<nameSpace>.NFLoadBalancerPingClassName=xx

        <clientName>.<nameSpace>.NIWSServerListClassName=xx

        <clientName>.<nameSpace>.NIWSServerListFilterClassName=xx

        com.netflix.client.config.IClientConfig：Ribbon的客户端配置，默认采用com.netflix.client.config.DefaultClientConfigImpl实现。

        com.netflix.loadbalancer.IRule：Ribbon的负载均衡策略，默认采用com.netflix.loadbalancer.ZoneAvoidanceRule实现，该策略能够在多区域环境下选出最佳区域的实例进行访问。

        com.netflix.loadbalancer.IPing：Ribbon的实例检查策略，默认采用com.netflix.loadbalancer.NoOpPing实现，该检查策略是一个特殊的实现，实际上它并不会检查实例是否可用，而是始终返回true，默认认为所有服务实例都是可用的。

        com.netflix.loadbalancer.ServerList：服务实例清单的维护机制，默认采用com.netflix.loadbalancer.ConfigurationBasedServerList实现。

        com.netflix.loadbalancer.ServerListFilter：服务实例清单过滤机制，默认采org.springframework.cloud.netflix.ribbon.ZonePreferenceServerListFilter，该策略能够优先过滤出与请求方处于同区域的服务实例。

        com.netflix.loadbalancer.ILoadBalancer：负载均衡器，默认采用com.netflix.loadbalancer.ZoneAwareLoadBalancer实现，它具备了区域感知的能力。

        上面的配置是在项目中没有引入spring Cloud Eureka，如果引入了Eureka和Ribbon依赖时，自动化配置会有一些不同。

        通过自动化配置的实现，可以轻松的实现客户端的负载均衡。同时，针对一些个性化需求，我们可以方便的替换上面的这些默认实现，只需要在springboot应用中创建对应的实现实例就能覆盖这些默认的配置实现。

        @Configuration

        public class MyRibbonConfiguration {

            @Bean

            public IRule ribbonRule(){

                return new RandomRule();

            }

        }

        这样就会使用P使用了RandomRule实例替代了默认的com.netflix.loadbalancer.ZoneAvoidanceRule。

        也可以使用@RibbonClient注解实现更细粒度的客户端配置

       å¯¹äºŽRibbon的参数通常有二种方式：全局配置以及指定客户端配置

        全局配置的方式很简单

        只需要使用ribbon.<key>=<value>格式进行配置即可。其中，<key>代表了Ribbon客户端配置的参数名，<value>则代表了对应参数的值。比如，我们可以想下面这样配置Ribbon的超时时间

        ribbon.ConnectTimeout=

        ribbon.ServerListRefreshInterval=   ribbon获取服务定时时间

        全局配置可以作为默认值进行设置，当指定客户端配置了相应的key的值时，将覆盖全局配置的内容

        指定客户端的配置方式

        <client>.ribbon.<key>=<value>的格式进行配置.<client>表示服务名，比如没有服务治理框架的时候（如Eureka），我们需要指定实例清单，可以指定服务名来做详细的配置，

        user-service.ribbon.listOfServers=localhost:,localhost:,localhost:

        对于Ribbon参数的key以及value类型的定义，可以通过查看com.netflix.client.config.CommonClientConfigKey类。

        当在spring Cloud的应用同时引入Spring cloud Ribbon和Spring Cloud Eureka依赖时，会触发Eureka中实现的对Ribbon的自动化配置。这时的serverList的维护机制实现将被com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList的实例所覆盖，该实现会讲服务清单列表交给Eureka的服务治理机制来进行维护。IPing的实现将被com.netflix.niws.loadbalancer.NIWSDiscoveryPing的实例所覆盖，该实例也将实例接口的任务交给了服务治理框架来进行维护。默认情况下，用于获取实例请求的ServerList接口实现将采用Spring Cloud Eureka中封装的org.springframework.cloud.netflix.ribbon.eureka.DomainExtractingServerList，其目的是为了让实例维护策略更加通用，所以将使用物理元数据来进行负载均衡，而不是使用原生的AWS AMI元数据。在与Spring cloud Eureka结合使用的时候，不需要再去指定类似的user-service.ribbon.listOfServers的参数来指定具体的服务实例清单，因为Eureka将会为我们维护所有服务的实例清单，而对于Ribbon的参数配置，我们依然可以采用之前的两种配置方式来实现。

        此外，由于spring Cloud Ribbon默认实现了区域亲和策略，所以，可以通过Eureka实例的元数据配置来实现区域化的实例配置方案。比如可以将不同机房的实例配置成不同的区域值，作为跨区域的容器机制实现。而实现也非常简单，只需要服务实例的元数据中增加zone参数来指定自己所在的区域，比如：

        eureka.instance.metadataMap.zone=shanghai

        在Spring Cloud Ribbon与Spring Cloud Eureka结合的工程中，我们可以通过参数禁用Eureka对Ribbon服务实例的维护实现。这时又需要自己去维护服务实例列表了。

        ribbon.eureka.enabled=false.

        由于Spring Cloud Eureka实现的服务治理机制强调了cap原理的ap机制（即可用性和可靠性），与zookeeper这类强调cp（一致性，可靠性）服务质量框架最大的区别就是，Eureka为了实现更高的服务可用性，牺牲了一定的一致性，在极端情况下宁愿接受故障实例也不要丢弃"健康"实例。

        比如说，当服务注册中心的网络发生故障断开时候，由于所有的服务实例无法维护续约心跳，在强调ap的服务治理中将会把所有服务实例剔除掉，而Eureka则会因为超过%的实例丢失心跳而触发保护机制，注册中心将会保留此时的所有节点，以实现服务间依然可以进行互相调用的场景，即使其中有部分故障节点，但这样做可以继续保障大多数服务的正常消费。

        在Camden版本，整合了spring retry来增强RestTemplate的重试能力，对于我们开发者来说，只需要简单配置，即可完成重试策略。

        spring.cloud.loadbalancer.retry.enabled=true

        hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=

        user-service.ribbon.ConnectTimeout=

        user-service.ribbon.ReadTimeout=

        user-service.ribbon.OkToRetryOnAllOperations=true

        user-service.ribbon.MaxAutoRetriesNextServer=2

        user-service.ribbon.maxAutoRetries=1

        spring.cloud.loadbalancer.retry.enabled:该参数用来开启重试机制，它默认是关闭的。

        hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds：断路器的超时时间需要大于Ribbon的超时时间，不然不会触发重试。

        user-service.ribbon.ConnectTimeout：请求连接超时时间。

        user-service.ribbon.ReadTimeout：请求处理的超时时间

        user-service.ribbon.OkToRetryOnAllOperations：对所有操作请求都进行重试。

        user-service.ribbon.MaxAutoRetriesNextServer：切换实例的重试次数。

        user-service.ribbon.maxAutoRetries：对当前实例的重试次数。

        根据以上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由maxAutoRetries配置），如果不行，就换一个实例进行访问，如果还是不行，再换一个实例访问（更换次数由MaxAutoRetriesNextServer配置），如果依然不行，返回失败

       é¡¹ç›®å¯åŠ¨çš„时候会自动的为我们加载LoadBalancerAutoConfiguration自动配置类，该自动配置类初始化条件是要求classpath必须要有RestTemplate这个类，必须要有LoadBalancerClient实现类。

        LoadBalancerAutoConfiguration为我们干了二件事，第一件是创建了LoadBalancerInterceptor拦截器bean，用于实现对客户端发起请求时进行拦截，以实现客户端负载均衡。创建了一个

        RestTemplateCustomizer的bean，用于给RestTemplate增加LoadBalancerInterceptor拦截器。

        每次请求的时候都会执行org.springframework.cloud.client.loadbalancer.LoadBalancerInterceptor的intercept方法，而LoadBalancerInterceptor具有LoadBalancerClient（客户端负载客户端）实例的一个引用，

        在拦截器中通过方法获取服务名的请求url（比如/p/1bddb5dc

        Spring cloud系列六 Ribbon的功能概述、主要组件和属性文件配置  

       /p/faffa

        本人有道云笔记中记录的参考文章

        文档：_ribbon 负载均衡.note

        链接：/noteshare?id=efc3efbbefd8ed0b9&sub=B0E6DFEEBDAF