version: "3.8"

services:  
  mysql:
    image: swr.cn-north-4.myhuaweicloud.com/library/mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: "mypassword"
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql
    restart: unless-stopped
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"
    networks:
      - admin-net 

volumes: 
  mysql_data:
    
networks:
  admin-net:
    external: true

使用密码登录

mysql -u root -p

然后输入密码。

然后输入如下

-- 创建或更新 root 用户,允许从任何主机连接
CREATE USER 'root'@'%' IDENTIFIED BY 'mypassword';

-- 授予所有权限
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;

-- 刷新权限使其生效
FLUSH PRIVILEGES;

-- 查看当前 root 用户的主机配置
SELECT host, user FROM mysql.user WHERE user='root';

在 Hyper-V 虚拟机安全设置中启用 TPM 时报错：

“设置密钥保护器失败。无法为包装中的证书签名。已尝试为证书 Signing 签名。”

根本原因（层层递进）

启用 TPM 失败
    │
    ▼
Hyper-V 尝试用"签名证书"对密钥保护器签名
    │
    ▼
证书存在于 Cert:\LocalMachine\Shielded VM Local Certificates
但私钥提供程序类型损坏（NTE_PROV_TYPE_NOT_DEF / 无效的提供程序类型）
    │
    ▼
HasPrivateKey = True（元数据显示有私钥）
但实际访问私钥时返回 NULL（私钥文件损坏或提供程序不匹配）
    │
    ▼
VMMS 无法完成签名操作 → 报错

具体原因分解

解决逻辑

第一步：定位问题
├── 检查 Cert:\LocalMachine\Shielded VM Local Certificates
├── 发现证书存在但 PrivateKey 返回 NULL
└── 确认私钥提供程序类型损坏

第二步：清理损坏环境
├── 停止 VMMS 服务
├── 删除损坏的 Shielded VM 证书
└── 删除旧的 HGS 守护者 (UntrustedGuardian)

第三步：重建证书
├── 使用 Microsoft Software Key Storage Provider
├── 不带 -KeySpec 参数（KSP 不兼容 KeySpec）
├── 创建签名证书（KeyUsage: DigitalSignature）
└── 创建加密证书（KeyUsage: KeyEncipherment/DataEncipherment）

第四步：重建守护者
├── New-HgsGuardian -Name "UntrustedGuardian"
├── 绑定新签名证书 Thumbprint
└── 绑定新加密证书 Thumbprint

第五步：验证
├── 启动 VMMS
├── 确认 Shielded VM Local Certificates 中出现 2 张新证书
└── Hyper-V 管理器中成功启用 TPM

关键命令回顾

powershell

# 1. 停止服务
Stop-Service vmms -Force

# 2. 删除损坏证书
Get-ChildItem "Cert:\LocalMachine\Shielded VM Local Certificates" | Remove-Item -Force

# 3. 删除旧守护者
Import-Module HgsClient
Get-HgsGuardian | Remove-HgsGuardian

# 4. 创建新证书（关键：不带 -KeySpec）
$signingCert = New-SelfSignedCertificate `
    -Subject "CN=Shielded VM Signing Certificate (UntrustedGuardian) ($env:COMPUTERNAME)" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -KeyUsage DigitalSignature `
    -Provider "Microsoft Software Key Storage Provider" `
    -NotAfter (Get-Date).AddYears(10)

$encryptionCert = New-SelfSignedCertificate `
    -Subject "CN=Shielded VM Encryption Certificate (UntrustedGuardian) ($env:COMPUTERNAME)" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -KeyUsage KeyEncipherment, DataEncipherment `
    -Provider "Microsoft Software Key Storage Provider" `
    -NotAfter (Get-Date).AddYears(10)

# 5. 重建守护者
New-HgsGuardian `
    -Name "UntrustedGuardian" `
    -SigningCertificateThumbprint $signingCert.Thumbprint `
    -EncryptionCertificateThumbprint $encryptionCert.Thumbprint `
    -AllowUntrustedRoot

# 6. 重启服务
Start-Service vmms

经验教训

为什么常规修复手段都无效？

为什么 certmgr.msc 看不到证书？
因为损坏的证书存储在 本地计算机 的 Shielded VM Local Certificates 节点，
certmgr.msc 只显示当前用户证书，需要用 certlm.msc 才能看到。

一、原理上的区别

1. Stable Diffusion（SD）类模型

• 原理：SD属于扩散模型（Diffusion Model）。它通过“噪声还原”的方式，把一张随机噪声图片逐步还原成符合你输入文本描述的图片。
• 文本理解：SD通常会用CLIP或者类似的文本编码器，把你的提示词（prompt）转成向量，然后引导图片生成过程。
• 训练数据：SD训练时，提示词通常是简短、标签式的描述（如“a dog, in the park, sunny day”），而不是长篇自然语言。

2. 大模型（如GPT-4V、ERNIE-ViLG、文心一格等）

• 原理：大模型（尤其是多模态大模型）可能包含更复杂的文本理解和图像生成能力，甚至可以直接理解更长、更复杂的自然语言描述。
• 文本理解：这些模型的文本理解能力更强，能解析更细腻的描述和上下文。
• 训练数据：大模型训练时，可能会用到大量自然语言描述和更复杂的上下文信息。

二、提示词用法的区别

1. SD模型的提示词（Prompt）

• 风格：更偏向关键词、标签式的组合，比如“a cat, sitting on a chair, 4k, ultra realistic, soft light”。
• 原因：SD训练时用的是类似的标签描述，模型对这类提示词的理解最准确，能直接影响生成效果。
• 优化：很多“AI绘画”高手会用一长串英文关键词来精细调控画面风格、细节、构图等。

2. 大模型的提示词

• 风格：更接近自然语言，可以是完整的一句话，甚至一段话，比如“请生成一张猫咪坐在椅子上的高清照片，阳光明媚，画面温馨”。
• 原因：大模型的文本理解能力强，能处理更复杂的语义和上下文，适合用自然语言描述。
• 优势：对新手更友好，不需要掌握复杂的关键词搭配。

三、举例对比

• SD提示词：a cat, sitting on a chair, 4k, ultra realistic, soft light
• 大模型提示词：请生成一只猫咪坐在椅子上的照片，画面清晰，阳光明媚，环境温馨。

四、总结

1. SD更适合标签式关键词，因为它的训练和文本理解机制决定了这样效果最好。
2. 大模型更适合自然语言描述，能理解更复杂的场景和细节。
3. 选择哪种提示词方式，要看用的是什么模型。如果是SD，建议用关键词+风格词；如果是大模型，可以直接用自然语言。

在实际项目中，我使用 RabbitMQ 作为消息队列，后端用 C# 消费消息并做业务处理。随着业务量增大，遇到了消息消费速度慢、并发被拖死的问题。这里记录下踩过的坑和解决思路。

1. 并发控制

坑点

RabbitMQ 默认是单线程消费，如果业务处理速度较慢，消息会越积越多。
我一开始采用了如下方式控制消费端并发：

private readonly SemaphoreSlim _concurrentSemaphore = new SemaphoreSlim(8); // 最大并发8
private readonly ushort prefetchCount = 8;

每次消费消息前 _concurrentSemaphore.Wait()，处理完后 .Release()，并设置 prefetchCount 限制 RabbitMQ 推送未确认消息数。

遇到的问题

• 如果某些消息处理很慢（比如卡了10分钟），就会占用并发槽位，导致后面的消息迟迟得不到处理。
• 只要有慢消息，整个消费端就会“卡死”，消费速度极慢。

2. 超时机制

解决思路

针对慢消息，我引入了超时机制：
为每条消息的处理设置最大超时时间（比如5分钟），超过即放弃处理，释放并发槽位。

实现方式

只需在消费消息的地方（比如 RabbitMQReceiver）加一层超时包装：

TimeSpan timeout = TimeSpan.FromMinutes(5);

var handleTask = _messageHandler.HandleAsync(ea.Body.ToArray());
var timeoutTask = Task.Delay(timeout, stoppingToken);

var completedTask = await Task.WhenAny(handleTask, timeoutTask);

if (completedTask == handleTask)
{
    result = await handleTask;
}
else
{
    // 超时处理
    _logger.LogError($"[RabbitMQ] 消息处理超时（>{timeout.TotalMinutes}分钟），自动放弃 DeliveryTag={ea.DeliveryTag}");
    result = false;
}

这样一来，慢消息不会拖死整个消费端，并发利用率大大提升！

3. 日志观察

优化前，经常看到类似日志：

[RabbitMQ] 消息全流程结束 DeliveryTag=940850，总耗时: 594604 ms，结果: 成功

有的消息处理竟然超过9分钟！
优化后，超时的消息会被及时 Nack 并记录日志：

[RabbitMQ] 消息处理超时（>5分钟），自动放弃 DeliveryTag=940850

4. 建议

• 并发消费一定要配合超时机制，否则慢消息会拖死所有并发。
• SemaphoreSlim 和 prefetchCount 要一致，保证并发控制有效。
• 建议对超时消息做告警，方便及时发现和定位问题。
• 生产环境建议超时时间不要太长，一般2~5分钟足够。

总结

RabbitMQ 消费端开发中，并发与超时控制是高可靠消费的关键。
只有二者配合，才能保证高吞吐、低延迟，避免“慢消息拖死全局”的灾难。

什么是 Watchtower？

Watchtower 是一个开源工具，用于自动监控和更新运行中的 Docker 容器。当检测到关联镜像有新版本时，Watchtower 会自动拉取新镜像，重建并重启对应的容器。这样可以实现应用的自动“滚动升级”，极大提升运维效率。

Docker Compose 配置示例

下面是一个典型的 docker-compose.yml 配置片段，加入了 Watchtower 服务：

version: "3.8"

services: 

  watchtower:
    image: registry.cn-beijing.aliyuncs.com/muta/watchtower:amd64
    restart: unless-stopped
    # 挂载 docker.sock 以便 Watchtower 能管理容器
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /root/.docker/:/config/
    environment:
      - DOCKER_CONFIG=/config
    # 监控项目的容器（tuechpresentation-api-1），这样不会影响其他容器
    command: --cleanup --interval 60 tuechpresentation-api-1

下面我们详细解释每一部分的作用。

配置详解

1. 镜像设置

image: registry.cn-beijing.aliyuncs.com/muta/watchtower:amd64

这里使用的是阿里云镜像仓库中的 Watchtower 镜像，适合国内用户加速下载。

2. 容器重启策略

restart: unless-stopped

表示除非手动停止容器，否则 Watchtower 会一直保持运行状态。

3. 挂载 Docker Socket

volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  - /root/.docker/:/config/

• /var/run/docker.sock:/var/run/docker.sock
  Watchtower 需要通过 Docker 的 Unix Socket 与 Docker Daemon 通信，从而管理和重启其他容器。
• /root/.docker/:/config/
  挂载主机上的 Docker 配置目录，便于 Watchtower 使用 Docker 配置（如私有仓库认证信息等）。

4. 环境变量

environment:
  - DOCKER_CONFIG=/config

指定 Docker 配置的路径为 /config，即上面挂载的 /root/.docker/。

5. 启动命令

command: --cleanup --interval 60 tuechpresentation-api-1

• --cleanup
  更新后自动删除旧的无用镜像，节省磁盘空间。
• --interval 60
  每 60 秒检查一次镜像是否有更新。
• tuechpresentation-api-1
  只监控名为 tuechpresentation-api-1 的容器，不会影响其他容器的运行和更新。

这样配置后，Watchtower 只会自动更新指定的 API 容器，非常适合只希望自动维护某个服务的场景。

使用建议

• 安全性：挂载 Docker Socket 具有一定风险，建议只在可信环境下使用。
• 精细化控制：通过在 command 部分指定容器名，可以避免 Watchtower 无差别地更新所有容器，更加灵活。
• 日志查看：可以通过 docker logs watchtower 查看 Watchtower 的工作日志，了解其自动更新的动态。

总结

通过在 Docker Compose 中集成 Watchtower，可以实现容器的自动更新，极大降低了运维成本。合理配置后，还能做到只更新指定容器，安全高效。你可以根据自己的实际需求调整监控容器的范围和更新频率，让你的 Docker 环境始终保持最新和安全。

一、有限状态机（FSM，Finite State Machine）

1. 概念

有限状态机是一种把NPC行为分成几个“状态”的设计方式，比如“巡逻”、“攻击”、“逃跑”等。NPC任意时刻只会处于某一个状态，满足条件才会切换到其他状态。

2. 原理

• 状态：NPC所处的行为阶段。
• 切换条件：决定何时从一个状态跳转到另一个状态。
• 每个状态的具体行为：比如巡逻状态下，NPC会在场景中来回走动。

3. 树图示例

巡逻
└─ 发现敌人? 是 → 追击敌人
    └─ 距离很近? 是 → 攻击敌人
        └─ 血量很低? 是 → 逃跑

4. 讲解

比如一个警卫巡逻，发现敌人就追击，靠近了就攻击，受伤严重就逃跑。每个行为就是一个“状态”，切换条件清晰简单，非常适合新手入门和简单AI。

二、决策树（Decision Tree）

1. 概念

决策树就像一系列嵌套的“如果……那么……”的判断题。NPC会沿着判断条件，一步步选择最终要做的事情。

2. 原理

• 每一层是一个判断问题。
• 满足条件就继续往下判断，直到找到适合当前情况的行为。

3. 树图示例

发现敌人?
├─ 是
│   └─ 距离近?
│       ├─ 是 → 攻击
│       └─ 否 → 追击
└─ 否 → 巡逻

4. 讲解

比如NPC先问自己“看到敌人了吗？”如果看到，再问“敌人近吗？”，如果近就攻击，不近就追。如果没看到，就继续巡逻。适合逻辑不复杂的NPC。

三、行为树（Behavior Tree）

1. 概念

行为树是一种模块化的设计，把复杂行为拆解成一个个“小动作”，再像拼积木一样组合起来。每个“树枝”表示一个决策流程，叶子节点是具体动作。

2. 原理

• 从根节点出发，按顺序或优先级检查每个子节点。
• 组合复杂行为，比如“先做A，如果不行再做B”。
• 节点可以复用，易于扩展。

3. 树图示例

选择器
├─ 行为1：发现敌人?
│   └─ 是 → 顺序器
│       ├─ 面向敌人
│       ├─ 接近敌人
│       └─ 攻击敌人
├─ 行为2：血量低?
│   └─ 是 → 寻找掩体
└─ 行为3：巡逻

4. 讲解

行为树就像一个智能化的流程表，先判断优先级高的事（比如有敌人就先攻击），否则做次要的事（比如巡逻）。树的结构让每个行为都能灵活组合，非常适合复杂NPC。

四、GOAP（目标导向动作规划，Goal-Oriented Action Planning）

1. 概念

GOAP不是提前写好所有流程，而是让NPC根据“目标”动态规划怎么做。比如目标是“活下来”，NPC会自动选择“找药包”“找掩体”等步骤。

2. 原理

• 给NPC设定多个目标，如“消灭敌人”“保持安全”。
• 每个动作有“前提条件”和“结果”。
• NPC根据当前情况，自动规划一系列动作达成目标。

3. 树图示例（目标：消灭敌人）

目标：消灭敌人
├─ 需要武器?
│   └─ 是 → 去找武器
├─ 有武器 → 靠近敌人
└─ 接近后 → 攻击敌人

4. 讲解

比如NPC没有武器，就会先去找武器；有了武器后再去接近敌人，最后攻击。GOAP让NPC像“思考”一样，灵活应对不同情况，行为更智能。

五、黑板系统（Blackboard System）

1. 概念

黑板系统是一个信息共享平台，NPC的各个模块（比如感知、决策、行动）都可以在黑板上读写信息，实现协同。

2. 原理

• 黑板就像一个公告栏，大家都能看到。
• 感知模块发现敌人后，把信息写到黑板上。
• 行为模块读取这些信息，决定要做什么。

3. 树图示例

黑板
├─ 发现敌人 → 决策模块读取 → 切换到攻击状态
├─ 发现血包 → 决策模块读取 → 前往拾取
└─ 其他信息

4. 讲解

黑板让NPC的不同部分可以互相沟通，比如“感知”发现敌人，“决策”模块就能知道要攻击。这种方式多用于复杂AI系统。

六、基于规则的系统（Rule-based System）

1. 概念

基于规则的系统，就是提前写好一堆“如果……那么……”的规则，NPC遇到情况就一条条检查，满足条件就执行相应行为。

2. 原理

• 规则库里存着各种条件和结果。
• NPC不断检查当前所有规则，执行最先匹配的行为。

3. 树图示例

规则库
├─ 如果血量低 → 寻找医疗包
├─ 如果敌人靠近 → 攻击
└─ 否则 → 巡逻

4. 讲解

比如“如果血量低，去找药包；如果敌人靠近，先攻击”。适合简单或者中等复杂度的AI，但规则多了后管理会变复杂。

七、机器学习/深度学习方法

1. 概念

机器学习让NPC通过“学习”来变得更聪明，比如通过反复试错，自动学会最佳行为。

2. 原理

• 通过大量训练，AI模型掌握在不同情况下的最佳反应。
• 强化学习：NPC每做一次选择，都会得到奖励或惩罚，通过不断尝试，学会最优策略。

3. 树图示例（简化思路）

环境反馈
├─ 尝试动作A → 得到奖励 → 增强动作A
├─ 尝试动作B → 得到惩罚 → 减少动作B
└─ 反复迭代 → 学习到最佳行为

4. 讲解

比如NPC在模拟环境里尝试“攻击”“逃跑”“躲避”，每次尝试后都通过奖励机制调整行为，最终学会如何做得最好。这种方法适合做高智能NPC，但开发和训练成本高。

八、基于大语言模型的生成式智能体架构（以斯坦福AI小人虚拟小镇为例）

1. 概念

生成式智能体（Generative Agent）是一种借助大语言模型（如GPT）作为“智能大脑”，结合记忆、检索、反思、计划等模块，模拟出高度拟人的行为和交互。其典型代表是斯坦福大学提出的“AI小人虚拟小镇”，在开源社区（如a16z重写版）得到了广泛应用。

传统AI方法如有限状态机、行为树、GOAP等，行为多为“脚本化”或“规则化”。生成式智能体则通过自然语言驱动行为，能够自我进化、动态适应环境，表现出类似人类的复杂行为。

2. 技术架构与整体思路

2.1 架构树状图

生成式智能体架构
├─ 记忆流（Memory Stream）
│   ├─ 观察（Observations）
│   ├─ 反思（Reflections）
│   └─ 计划（Plans）
├─ 检索机制（Retrieval）
│   ├─ 近因性
│   ├─ 重要性
│   └─ 相关性（向量数据库）
├─ 反思机制（Reflection）
│   └─ 抽象/推理（生成反思树）
├─ 计划与反应（Planning & Reaction）
│   ├─ 高层计划
│   └─ 递归细化
├─ 行为生成（Action Generation）
│   ├─ 环境互动
│   └─ 代理对话
├─ 用户交互
│   └─ 用户输入（自然语言）
├─ 外部支持系统
│   ├─ 游戏引擎、数据库
│   ├─ 向量数据库
│   ├─ 文字生成模型（LLM）
│   └─ 像素图生成等

2.2 架构详细讲解

A. 记忆流（Memory Stream）

• 每个智能体都有自己的“记忆数据库”，记录着所有经历过的事件、对话、计划、反思等。
• 记忆以自然语言形式存储，包含时间戳和访问时间，既有“观测”也有“抽象反思”。
• 例如：AI小人“伊莎贝拉”会记得“今天早上在厨房遇到朋友做早餐”。

B. 检索机制（Retrieval）

• 智能体需要从大量记忆中检索出“当前最相关”的记忆，指导当下行为。
• 检索包括三大指标：
  • 近因性：越新发生的事件，分数越高。
  • 重要性：事件越重要，分数越高（如“分手”比“刷牙”重要）。
  • 相关性：用向量数据库（如Pinecone）计算与当前情境的相似度。
• 例如，AI小人要决定是否去见某人，会回忆最近有关此人的经历和情感。

C. 反思机制（Reflection）

• 不只是被动记忆，还会主动“总结归纳”，形成“反思”。
• 反思是对多个相关记忆的抽象，比如“我和朋友的关系变得更亲密了”。
• 反思会形成“树状结构”，叶节点是具体事件，高层节点是抽象见解。
• 反思周期性发生，重要事件累积到阈值时触发。

D. 计划与反应（Planning & Reaction）

• 智能体会制定自己的“日程计划”，比如“早上做早餐、上午去公园、下午工作”。
• 计划可以递归细化成更小的行动步骤，并随时根据环境变化做出调整。
• 每当环境或其他智能体行为发生变化，计划会实时更新。

E. 行为生成（Action Generation）

• 智能体的每一步行为由大语言模型（如GPT）生成，行为描述为自然语言，并映射到具体动作。
• 智能体之间的对话、与环境的交互都通过自然语言描述和解释。

F. 用户交互

• 用户可以通过自然语言输入影响智能体（如指派任务、修改属性）。
• 用户也可以“化身”进入虚拟小镇，成为其中一员。

G. 外部支持系统

• 游戏引擎（Convex）、数据库、向量数据库（Pinecone）、文字生成模型（OpenAI）、像素图生成（Replicate/Fal.ai）等，构成整个技术栈的基础设施。

3. 与传统AI方法的对比

4. 生成式智能体的创新点

• 内逻辑与外逻辑结合：大语言模型负责“想”，外部系统负责“管”数据和操作。
• 记忆驱动行为：不再依赖死板脚本，行为由“记忆-检索-反思-计划”动态生成。
• 行为高度拟人：能模拟人类的长期记忆、情感变化、临场反应、社会互动。
• 自进化能力：环境或用户输入变化时，智能体能自动适应，无需修改代码。

5. 示例：AI小人的一天（树状图）

伊莎贝拉的一天
├─ 记忆流
│   ├─ 早上做早餐
│   ├─ 与朋友聊天
│   ├─ 计划去公园
│   └─ 下午工作
├─ 检索
│   ├─ 最近与朋友的对话
│   └─ 上次工作时的反思
├─ 反思
│   ├─ 今天与朋友关系更亲密
│   └─ 工作效率提升
├─ 计划
│   ├─ 上午：社交
│   └─ 下午：工作
├─ 行为
│   ├─ 与朋友互动
│   └─ 执行工作任务

这些行为全自动生成，AI小人会根据记忆和环境调整自己的计划和反应。

6. 适用场景与未来趋势

• 虚拟世界/元宇宙：高度拟人NPC、虚拟居民。
• 游戏开发：复杂剧情与开放世界中的真实NPC行为。
• 社交/教育/陪伴：情感丰富、可自我进化的AI伙伴。
• 智能体系统：自动化办公、协作机器人等。

7. 相关资源

• 项目地址（GitHub）
• 论文原文（英文）
• 论文（中文机翻）
• 官方演示

总结

斯坦福AI小人虚拟小镇项目开启了大语言模型驱动的AI智能体新时代。它打破了传统脚本和规则系统的限制，让AI像“人”一样，有记忆、会反思、能规划、会交流，真正实现了“虚拟居民”的可信模拟。这一架构的理解，对设计下一代AI应用极具参考价值。

啊

当然现在这里啥都没有

那

玩一下鸭子吧

version: '3.8'

services:  
  emqx:
    image: registry.cn-beijing.aliyuncs.com/muta/emqx:amd64
    restart: always
    container_name: emqx
    ports:
      - "1883:1883"   # MQTT 协议端口
      - "8083:8083"   # WebSocket 端口
      - "8084:8084"   # WebSocket(SSL) 端口
      - "18083:18083" # 管理后台端口
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"

  rabbitmq:
    image: registry.cn-beijing.aliyuncs.com/muta/rabbitmq:management-amd64
    restart: always
    container_name: rabbitmq
    ports:
      - "5672:5672"   # AMQP 协议端口
      - "15672:15672" # 管理页面端口
    environment:
      RABBITMQ_DEFAULT_USER: admin
      RABBITMQ_DEFAULT_PASS: admin123
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"

  mqtt2rabbitmq:
    image: registry.cn-beijing.aliyuncs.com/dfzh/mqtt2rabbitmq:latest
    restart: always
    container_name: mqtt2rabbitmq
    environment:
      RabbitMQ__Hostname: rabbitmq
      RabbitMQ__Username: admin
      RabbitMQ__Password: admin123
      RabbitMQ__QueueName: Sensor 
      MQTT__Broker: emqx
      MQTT__Topic: /dev/luna/# 
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"

  rabbitmqvbrationwebapi:
    image: registry.cn-beijing.aliyuncs.com/dfzh/rabbitmqvibrationwebapi:latest
    restart: always
    container_name: rabbitmqvbrationwebapi
    ports:
      - "8222:5759"   
    volumes:
      - /home/HisDatas:/app/HisDatas
    environment:
      RabbitMQ__Hostname: rabbitmq
      RABBITMQ__Port: 5672
      RabbitMQ__Username: admin
      RabbitMQ__Password: admin123
      RabbitMQ__QueueName: vibhex  
      RABBITMQ__ProductionEnvironment: true
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"

1. 原理区别

帧差法（Frame Difference）

• 基本思想：直接对连续两帧图像的像素灰度值做差分，若差值大于阈值，则判定为运动区域。
• 输出结果：主要得到运动的“掩膜”或“区域”，即哪个像素发生了变化。
• 适用场景：简单的运动检测和目标分割。

光流法（Optical Flow）

• 基本思想：基于亮度一致性假设，通过分析连续帧间像素灰度分布的变化，估计每个像素的速度矢量（即运动方向和幅度）。
• 输出结果：每个像素的运动矢量场（速度场），可进一步分析位移、速度、振动等物理量。
• 适用场景：需要精确估计物体运动、结构振动、速度场、位移场等场景。

2. 结果对比

3. 优缺点对比

帧差法：

• 优点：实现简单，计算速度快，适合实时检测。
• 缺点：只能检测运动区域，无法准确估计运动的方向和幅度，易受光照变化影响，对微小运动不敏感。

光流法：

• 优点：可获得像素级别的运动方向和幅度信息，适合微小运动（如结构振动、模态识别、运动放大）。
• 缺点：计算复杂度高，对噪声和光照变化较敏感，需较好的视频质量。

4. 应用举例

• 帧差法：适合用于安防监控中检测是否有物体进入画面，或简单的运动目标检测。
• 光流法：适合用于结构健康监测、桥梁/建筑物振动检测、模态参数识别、运动放大等需要高精度运动分析的场景。

5. 总结

帧差法更偏向于“有没有运动”的检测，而光流法则能“量化运动”，包括运动的方向和幅度。在结构振动、模态识别、运动放大等需要定量分析运动的场景，光流法明显优于帧差法。

前言

对于很多初学者来说，Portainer 这个工具可能比较陌生。其实，Portainer 的作用和安卓手机上的“应用商店”非常类似。应用商店让我们方便地安装、管理和卸载各种手机应用，而 Portainer 则让我们在服务器上用可视化方式管理 Docker 容器（各种服务器应用）。本教程将用详细的类比和表格，帮助初学者快速理解 Portainer 的各项功能和实际操作细节。

一、Portainer 与安卓应用商店功能对照表

二、Portainer 安装与初次使用细节

1. 安装 Docker

• Portainer 依赖 Docker 环境，需先在服务器上安装好 Docker。类似于安卓系统必须先准备好，才能安装应用商店。
• 初学者推荐在干净的服务器或虚拟机上操作，避免环境冲突。

1. 部署 Portainer

• Portainer 本身也是一个容器应用。部署后，会自动生成管理界面，通常通过浏览器访问。
• 访问方式为：http://服务器IP:9000，首次进入需要设置管理员账号和密码，确保安全性。

1. 首次登录

• 建议初学者使用强密码，并妥善保存账号信息。
• 登录后会看到主界面，包括管理节点、容器、镜像、网络、卷等模块。

三、Portainer 图形界面与应用商店界面细节对比

四、典型操作场景细节讲解

1. 安装新容器服务（如 WordPress 网站）

• 在应用模板中找到 WordPress，点击部署。
• 细致填写数据库密码、端口号等参数，确认后即可自动完成安装。
• 部署后自动跳转到容器列表，可一键启动、停止或重启服务。
• 类似于在应用商店中搜索微信，点击安装，填写账号信息后即可使用。

1. 启动或停止容器

• 容器列表中，每个容器都有启动、停止、重启按钮。
• 可根据需要灵活操作，适合测试和维护环境。
• 类比于手机上打开或关闭应用。

1. 卸载容器服务

• 停止容器后，点击删除即可完成卸载。
• 建议初学者在删除前备份重要数据（如数据库内容），避免误删。
• 类似于卸载手机应用时确认是否保留数据。

1. 更新容器应用

• 检查镜像库是否有新版本，拉取最新镜像后重建容器。
• 更新前建议备份数据，并确认新版本兼容性。
• 类比于应用商店提示应用有新版本时，点击升级按钮。

1. 查看容器日志

• 容器详情页可实时查看运行日志，支持搜索关键字（如“error”、“failed”）。
• 日志可帮助排查启动失败、配置错误等问题，是运维必备工具。
• 类似于应用崩溃后查看日志定位问题。

五、常见问题与细节排查方法

六、进阶建议

• 初学者可优先使用模板部署常用服务，熟悉参数填写和基本管理流程。
• 建议定期查看容器日志，及时发现和解决潜在问题。
• 多用户协作时，合理分配权限，避免误操作影响整个环境。
• 学习数据卷和网络管理，提高服务的稳定性和安全性。
• 探索远程节点管理，适合多台服务器或云平台场景。

结语

Portainer 就像服务器世界里的“应用商店”，让初学者无需复杂命令，就能像管理手机应用一样，轻松管理服务器上的各种服务。通过图形界面、详细日志和丰富模板，Portainer 不仅提升了管理效率，也降低了运维门槛。建议初学者在实践中多尝试、多探索，逐步掌握容器化应用的管理技巧。