Tinksp
Tinksp
该篇为tinksp2.0我的账户炸杠后的补充文档，历史链接，
# MultiPaper 与 ItemsAdder 兼容性与性能分析（
**作者**：明晞（辅助：ChatGPT）
**日期**：2025-10-09 15:10
---
## 摘要
众所周知，没人知道我在研究这东西，但近期部分老外也在搞这个，比如联动mm这种方式，所以发出来这些内容以便更好地数据互通交流。
在没有官方兼容保证的前提下，实测表明 MultiPaper 与 ItemsAdder 可以实现跨节点 家具 的可视与交互。本文深入分析其潜在机制、性能开销（CPU / Tick / 带宽）、风险点，并给出可执行的测量公式和优化建议。特别补充：带宽/网络包量估算模型与参考来源。
---
## 1. 背景与术语
- **MultiPaper**：一种将 Minecraft 世界跨多台服务器分布式运行的系统，通过主控数据库 + 节点间同步来共享区块、实体等状态。它保证一个世界逻辑上一致，同时让各节点承担部分负载。 :contentReference[oaicite:0]{index=0}
- **ItemsAdder（IA）**：用于添加自定义家具、物品、实体等的 Bukkit / Spigot 插件。家具通常通过实体（armor_stand、item_display、item_frame） + 插件管理的数据层实现。 :contentReference[oaicite:1]{index=1}
测试环境：
核心为paper 1.20.1/purpur 1.20.1 均为发帖日期时最后更新的版本
ia插件版本：ItemsAdder_3.6.3-beta-12.jar
mp版本：编号#60 2025/5/22
术语说明：
- **实体（Entity）**：Minecraft 中可被客户端渲染、交互的对象，如盔甲架 (armor_stand)、item_frame、item_display 等。
- **Tick / MSPT**：服务器每 “刻” 的处理周期；MSPT 是每 tick 花费的毫秒数（理想值越低越好）。
- **带宽 / 网络包量**：服务器向客户端、或节点间同步实体状态所发送的数据总量。
- **同步 / 转交 / 所有权**：在 MultiPaper 架构下，某些 chunk/实体可能由某节点“负责”，而其他节点通过同步来显示状态。
---
## 2. 兼容性机制假设与证据
### 2.1 MultiPaper 的实体与 chunk 同步机制
- MultiPaper 的 README 指出：各服务器节点缓存其所需的 chunk，并同步缓存状态给其他节点。 :contentReference[oaicite:2]{index=2}
- 在 “How It Works” 里，MultiPaper 强调节点之间采用点对点通信实时同步状态（包括实体等）以支持跨服务器交互。 :contentReference[oaicite:3]{index=3}
- 在其配置文档 `MULTIPAPER_YAML.md` 中，有项 `sync-entity-ids` 用以控制实体 ID 在服务器间的同步（以便插件/客户端识别同一实体）。 :contentReference[oaicite:4]{index=4}
由此可判断：MultiPaper 原生具备将实体状态在节点间同步的基础设施。
### 2.2 ItemsAdder 家具实体类型与优化特性
- IA 在其家具模型介绍中指出，它支持 `item_display` 类型实体，这比传统的 armor_stand 更轻量，并且允许通过 `render_size` 参数来控制渲染区域、剔除视野外实体以减少负载。 :contentReference[oaicite:5]{index=5}
- 在 ItemsAdder 的 issue #2458，有社区建议使用 `item_display` 替代 armor_stand 以减轻性能负载（显示实体、动画更新、客户端同步更低开销）。 :contentReference[oaicite:6]{index=6}
- IA 的家具配置允许设定 `max_per_chunk` 等参数，以控制每区块最大家具数量。 :contentReference[oaicite:7]{index=7}
因此，IA 本身具备一些性能控制手段。
### 2.3 兼容路径（推测）
综合上述，跨节点家具兼容可能的流程：
1. 在节点 A 上，玩家触发放置家具 → IA 插件生成实体 + 更新其内部状态持久化。
2. MultiPaper 负责该 chunk 的节点 A 将该实体 /块状态变更通知 master /其他节点。
3. 其他节点接收到同步后，在其本地创建 /更新该实体映像，以便其节点内玩家可见。
4. 玩家在其他节点拆除或交互时，发送交互事件到该节点 → 节点映射到 IA 插件处理 → 插件再触发同步变更到其它节点 → 撤除实体。
这种同步既包括实体在节点间的“镜像拷贝”，也可能包括实体 ID 对应（由 `sync-entity-ids` 配置支持）。
这种兼容方式目前没有官方明确文档声明，但你的实测效果就是这一机制在你环境中“刚好能用”。
---
## 3. 性能开销模型：CPU / Tick 与 带宽
下面我给出详细的计算模型、基准假设、公式，以及估算方法与优化建议。
### 3.1 CPU / Tick 成本模型
每个服务器节点对家具实体要做 Tick 处理（如位置、碰撞检测、动画、插件逻辑等）。可近似模型：
\[
\Delta MSPT = N_e \times c_{tick}
\]
- \( \Delta MSPT \)：每 tick 因家具实体导致的毫秒开销
- \( N_e \)：该节点负责模拟的家具实体数量
- \( c_{tick} \)：单个家具每 tick 平均处理成本 (ms)
举例估算假设：
- 若实体为 armor_stand / 带动画 /碰撞检测复杂，假定 \(c_{tick} ≈ 0.02 \, \text{ms} = 0.02\)
- 若为更轻量的 `item_display`，可假定 \(c_{tick} ≈ 0.005 \, \text{ms}\)
若 \(N_e = 120\)，则：
- armor_stand 模式：\(\Delta MSPT = 120 \times 0.02 = 2.4 \, \text{ms}\)
- item_display 模式：\(\Delta MSPT = 120 \times 0.005 = 0.6 \, \text{ms}\)
如果服务器基础 tick 数为 5 ms，则合计 7.4 ms 或 5.6 ms，仍在 50 ms 上限内有余量。
> **注意**：这些是假设值。真实 \(c_{tick}\) 与插件复杂度、逻辑分支、碰撞检测等高度相关，建议实测。
### 3.2 带宽 / 网络包量模型
实体状态变化要推送给客户端（玩家）以及跨节点同步。网络开销模型：
\[
\text{Bandwidth (bytes/s)} = N_e \times N_p \times f_u \times B_{avg}
\]
- \(N_e\)：实体数量
- \(N_p\)：跟踪 / 看到这些实体的玩家数量（即在线玩家或处于视距玩家数）
- \(f_u\)：每秒更新频率（updates per second），即实体向客户端发送状态的次数
- \(B_{avg}\)：每次更新包平均字节数
示例假设：
- \(N_e = 120\)
- \(N_p = 100\)
- \(f_u = 1\)（静态实体，一秒一次或客户端请求时更新）
- \(B_{avg} = 200\) bytes
代入：
\[
120 \times 100 \times 1 \times 200 = 2,400,000 \, \text{bytes/s} ≈ 2.29 \, \text{MB/s}
\]
如果更新频率提高（如 \(f_u = 2\)），或包体积更大，带宽需求成比例增长。
此外，还要考虑节点间同步实体状态时的带宽（主节点 → 从节点）类似模型，每当状态变化就会跨节点推送实体变更包。这个开销通常比客户端推送低（玩家数量通常比节点少），但在高交互场景也可能显著。
对于 Minecraft / Bukkit / Spigot / Paper 类服务器，每个实体更新包可能包含位置、旋转、metadata、NBT 数据等（数十到几百字节）。在 “Entities & Packets” 讨论中，客户端在 chunk load 时会接收到实体 spawn 包、metadata 包等。 :contentReference[oaicite:8]{index=8}
因此上面的模型虽简化，但在 Minecraft 插件环境下是合理的第一阶估算。
### 3.3 总开销比较与负载分布
- **Tick / CPU 开销**：与玩家数量无关，只看实体数量与实体复杂度
- **客户端带宽开销**：与玩家数量成正比
- **节点间同步开销**：与实体变更频率 + 节点数 + 状态同步包大小有关
- 在 MultiPaper 架构下，理想还应加上“实体所有权转移 / 主控协调”开销，但它通常是偶发性的且低频。
---
## 4. 风险点、边界案例与优化建议
### 4.1 风险点
- **实体同步冲突 / 所有权错乱**：当 chunk 控制权在节点间切换时，实体可能会在切换过程中被删除或重复。
- **同步延迟 / 丢包**：网络延迟或丢包可能导致某节点短暂看不到家具或状态不同步。
- **高并发操作冲突**：多个玩家同时在多个节点操作同一区家具，可能导致状态冲突、覆盖或错误。
- **带宽峰值瓶颈**：在玩家密集区域，如果 many 家具同时改动，瞬时带宽需求可能超出带宽上限。
- **客户端渲染压力**：即使服务器能承担，客户端也可能因过多实体渲染而卡顿。
### 4.2 优化建议（再细化）
- 优先使用 `item_display` 类型家具以减少 `c_{tick}` 与包体积开销。
- 在家具配置中使用 `render_size`、`hitbox` 限制视距外剔除（让实体在玩家看不到时不发送更新）。
- 设置合理的 `max_per_chunk` 与 `custom_entities.max_per_chunk`，不要让某一区块家具密度过高。
- 对高交互 / 高实体密度区域做节点局部化（让一个节点专责处理），减少多节点同步转交风险。
- 启用 MultiPaper 的 `sync-entity-ids` 以保证节点间实体 ID 对应一致。 :contentReference[oaicite:9]{index=9}
- 在交互操作上（放置/拆除）做短时锁 / 互斥 / 重试保护，避免冲突。
- 使用 `/spark profiler` 或 `/timings` 定期监测 `entity-ticking`、`netty write` 等模块负载。
- 若可能，对节点间同步流量做压缩 / 差分更新（仅发送变化部分，而不是整实体 metadata），以减少带宽。
---
## 5. 完整的增强版说明文档（Markdown 保存版）
（你可以把下面整段复制为 `.md` 文档）
```markdown
# MultiPaper 与 ItemsAdder 兼容性与性能分析（增强版）
## 摘要
在无官方兼容保证下，实测表明 MultiPaper 与 ItemsAdder 可实现跨节点家具有视与交互。本文通过机制分析、性能模型、风险点评估与优化建议，给出更详尽说明。
## 背景与术语
- MultiPaper：一种将 Minecraft 世界跨多服务器分布的方法，节点通过点对点通讯与主控数据库同步 chunk/实体数据。
> 各服务器缓存所需 chunk，并与其他节点同步状态。 :contentReference[oaicite:10]{index=10}
> 在 “How It Works” 中，实体 / 块状态同步是核心机制。 :contentReference[oaicite:11]{index=11}
> 在配置中，`sync-entity-ids` 控制实体 ID 在节点间同步。 :contentReference[oaicite:12]{index=12}
- ItemsAdder：Bukkit/Spigot 插件，用于添加自定义家具、实体、物品等。家具通过实体 + 插件数据层实现。
> 支持多种实体类型（`item_display`、`armor_stand`、`item_frame`）及渲染优化选项。 :contentReference[oaicite:13]{index=13}
> 社区建议 `item_display` 可显著减轻性能开销。 :contentReference[oaicite:14]{index=14}
> 支持设定 `max_per_chunk` 等限制。 :contentReference[oaicite:15]{index=15}
## 兼容机制假设与证据
- MultiPaper 原生支持实体/状态同步功能
- IA 家具实体 + 插件数据结构允许跨节点同步
- 实现路径可能是：实体在一个节点生成 → 同步给其他节点 → 各节点再本地镜像实体 → 玩家跨节点互动事件同步 → 插件处理 → 再广播变更
## 性能开销模型
### CPU / Tick 成本模型
\[
\Delta MSPT = N_e \times c_{tick}
\]
- 假设 armor_stand 模式 \(c_{tick} = 0.02\) ms
- 假设 item_display 模式 \(c_{tick} = 0.005\) ms
- 若 \(N_e = 120\)，则：armor_stand 模式开销 ≈ 2.4 ms/tick，item_display 模式 ≈ 0.6 ms/tick
### 带宽 / 网络包量模型
\[
\text{Bandwidth (bytes/s)} = N_e \times N_p \times f_u \times B_{avg}
\]
- 示例：\(N_e=120\)，\(N_p=100\)，\(f_u=1\)，\(B_{avg}=200\) bytes → ≈ 2.4 MB/s
- 若频率或包体变大，则成比例增长
- 需同时考虑节点间同步流量（实体状态广播）
### 总成本组成
- Tick / CPU：与实体数量、实体复杂度有关
- 客户端带宽：与在线人数、视距、更新频率有关
- 节点间同步：与同步频率、节点数、状态变化有关
## 风险点与边界案例
| 风险 | 描述 | 可能后果 |
|---|---|---|
| 实体所有权转移异常 | chunk 控制权切换时实体归属不稳定 | 家具丢失或重复 |
| 同步延迟 / 丢包 | 节点间通讯不及时 | 短暂不同步 |
| 并发操作冲突 | 多节点同时操作同一区家具 | 状态覆盖或错误 |
| 带宽峰值 | 家具频繁更新 | 带宽饱和 |
| 客户端渲染压力 | 大量实体渲染 | 客户端卡顿 |
## 优化建议
- 使用 `item_display` 类型家具，降低 CPU 与包体积
- 配置 `render_size`、`hitbox` 剔除视野外实体
- 调整 `max_per_chunk`、`custom_entities.max_per_chunk` 控制密度
- 局部化高交互区域至单节点处理
- 启用 `sync-entity-ids` 确保实体 ID 对应 :contentReference[oaicite:16]{index=16}
- 操作加锁 / 重试以避免冲突
- 定期使用 `/spark` 或 `/timings` 监测 `entity-ticking`、`netty write` 等指标
- 若可能，对同步包做差分/压缩优化
---
## 结束语
这份增强版说明结合公开文档与社区讨论，配合你实地验证出来的跨节点家具交互现象，提供一个有据可测的模型与风险分析。
建议你用这份作为基础，在你的真实服务器环境里替换假设为实际硬件参数，做对比测量，以得出你那套系统的“真实承受极限”。
附加补充：
说人话就是，multi paper端再多 该加载的ia家具仍然会造成负载，但不会被人数影响，假设mp的VCmaster那里的ia家具会被加载1000个实体家具，那么无论你下面的multipaper有多少人 只要被服务器加载了，1个人也是这么多，100个人也是这么多 不会影响tps 因为他只是个原版实体而已。
至于ia的兼容性，也只是兼容而已 俩官方我并没有找到对应的兼容 反而近期mm生物倒是兼容了个folia。
需要注意的是如果你不太了解multi paper 又想往里塞meg为驱动的生物/怪物。别想了 会丢失ai的，在mp的不同核心分片区域的时候的一瞬间，生物将会丢失该分片插件控制，但因为另一分片的区域接受不到这个生物负责的插件信息[比如mm，比如mcpets]，导致瞬间变成了原版生物，也就是后台配置中的这个生物的原版ai。但荒谬的是如果你短时间内把这个走到其他分片的meg生物推回原来的生成分片区域，他还是可以正常显示。
你也仍然需要注意 即便ia资源包每个分片核心都能调整一样，但每次meg生物生成的时候，另一分片的玩家们看到的只是一个原版生物头顶了个mm生物名称。
比如你使用pets召唤了你的一个中世纪守卫，他的后台mm写的生物是wolf，那么你生成这个守卫meg实体的时间，另一个multipaper分片的玩家们看到的，只是一个原版的狼 但ai在离开你召唤的分片区域之前还被你所在分片的核心插件 比如mcpets 比如mm 所控制而已。
以及根据一些同样实操测试过的服主，所反馈的类似于同步数据的问题。我没测过，因为篝火是全程封闭的大世界，地图提前定制跑好了，不会出现地图加载或者所谓相关服主反馈的问题需求。所以如果你是要用这个玩意开服且玩家会在里面跑图生成新区块，其稳定性我没测试过，如有结果可以留在此帖造福后人。
# MultiPaper 与 ItemsAdder 兼容性与性能分析（
**作者**：明晞（辅助：ChatGPT）
**日期**：2025-10-09 15:10
---
## 摘要
众所周知，没人知道我在研究这东西，但近期部分老外也在搞这个，比如联动mm这种方式，所以发出来这些内容以便更好地数据互通交流。
在没有官方兼容保证的前提下，实测表明 MultiPaper 与 ItemsAdder 可以实现跨节点 家具 的可视与交互。本文深入分析其潜在机制、性能开销（CPU / Tick / 带宽）、风险点，并给出可执行的测量公式和优化建议。特别补充：带宽/网络包量估算模型与参考来源。
---
## 1. 背景与术语
- **MultiPaper**：一种将 Minecraft 世界跨多台服务器分布式运行的系统，通过主控数据库 + 节点间同步来共享区块、实体等状态。它保证一个世界逻辑上一致，同时让各节点承担部分负载。 :contentReference[oaicite:0]{index=0}
- **ItemsAdder（IA）**：用于添加自定义家具、物品、实体等的 Bukkit / Spigot 插件。家具通常通过实体（armor_stand、item_display、item_frame） + 插件管理的数据层实现。 :contentReference[oaicite:1]{index=1}
测试环境：
核心为paper 1.20.1/purpur 1.20.1 均为发帖日期时最后更新的版本
ia插件版本：ItemsAdder_3.6.3-beta-12.jar
mp版本：编号#60 2025/5/22
术语说明：
- **实体（Entity）**：Minecraft 中可被客户端渲染、交互的对象，如盔甲架 (armor_stand)、item_frame、item_display 等。
- **Tick / MSPT**：服务器每 “刻” 的处理周期；MSPT 是每 tick 花费的毫秒数（理想值越低越好）。
- **带宽 / 网络包量**：服务器向客户端、或节点间同步实体状态所发送的数据总量。
- **同步 / 转交 / 所有权**：在 MultiPaper 架构下，某些 chunk/实体可能由某节点“负责”，而其他节点通过同步来显示状态。
---
## 2. 兼容性机制假设与证据
### 2.1 MultiPaper 的实体与 chunk 同步机制
- MultiPaper 的 README 指出：各服务器节点缓存其所需的 chunk，并同步缓存状态给其他节点。 :contentReference[oaicite:2]{index=2}
- 在 “How It Works” 里，MultiPaper 强调节点之间采用点对点通信实时同步状态（包括实体等）以支持跨服务器交互。 :contentReference[oaicite:3]{index=3}
- 在其配置文档 `MULTIPAPER_YAML.md` 中，有项 `sync-entity-ids` 用以控制实体 ID 在服务器间的同步（以便插件/客户端识别同一实体）。 :contentReference[oaicite:4]{index=4}
由此可判断：MultiPaper 原生具备将实体状态在节点间同步的基础设施。
### 2.2 ItemsAdder 家具实体类型与优化特性
- IA 在其家具模型介绍中指出，它支持 `item_display` 类型实体，这比传统的 armor_stand 更轻量，并且允许通过 `render_size` 参数来控制渲染区域、剔除视野外实体以减少负载。 :contentReference[oaicite:5]{index=5}
- 在 ItemsAdder 的 issue #2458，有社区建议使用 `item_display` 替代 armor_stand 以减轻性能负载（显示实体、动画更新、客户端同步更低开销）。 :contentReference[oaicite:6]{index=6}
- IA 的家具配置允许设定 `max_per_chunk` 等参数，以控制每区块最大家具数量。 :contentReference[oaicite:7]{index=7}
因此，IA 本身具备一些性能控制手段。
### 2.3 兼容路径（推测）
综合上述，跨节点家具兼容可能的流程：
1. 在节点 A 上，玩家触发放置家具 → IA 插件生成实体 + 更新其内部状态持久化。
2. MultiPaper 负责该 chunk 的节点 A 将该实体 /块状态变更通知 master /其他节点。
3. 其他节点接收到同步后，在其本地创建 /更新该实体映像，以便其节点内玩家可见。
4. 玩家在其他节点拆除或交互时，发送交互事件到该节点 → 节点映射到 IA 插件处理 → 插件再触发同步变更到其它节点 → 撤除实体。
这种同步既包括实体在节点间的“镜像拷贝”，也可能包括实体 ID 对应（由 `sync-entity-ids` 配置支持）。
这种兼容方式目前没有官方明确文档声明，但你的实测效果就是这一机制在你环境中“刚好能用”。
---
## 3. 性能开销模型：CPU / Tick 与 带宽
下面我给出详细的计算模型、基准假设、公式，以及估算方法与优化建议。
### 3.1 CPU / Tick 成本模型
每个服务器节点对家具实体要做 Tick 处理（如位置、碰撞检测、动画、插件逻辑等）。可近似模型：
\[
\Delta MSPT = N_e \times c_{tick}
\]
- \( \Delta MSPT \)：每 tick 因家具实体导致的毫秒开销
- \( N_e \)：该节点负责模拟的家具实体数量
- \( c_{tick} \)：单个家具每 tick 平均处理成本 (ms)
举例估算假设：
- 若实体为 armor_stand / 带动画 /碰撞检测复杂，假定 \(c_{tick} ≈ 0.02 \, \text{ms} = 0.02\)
- 若为更轻量的 `item_display`，可假定 \(c_{tick} ≈ 0.005 \, \text{ms}\)
若 \(N_e = 120\)，则：
- armor_stand 模式：\(\Delta MSPT = 120 \times 0.02 = 2.4 \, \text{ms}\)
- item_display 模式：\(\Delta MSPT = 120 \times 0.005 = 0.6 \, \text{ms}\)
如果服务器基础 tick 数为 5 ms，则合计 7.4 ms 或 5.6 ms，仍在 50 ms 上限内有余量。
> **注意**：这些是假设值。真实 \(c_{tick}\) 与插件复杂度、逻辑分支、碰撞检测等高度相关，建议实测。
### 3.2 带宽 / 网络包量模型
实体状态变化要推送给客户端（玩家）以及跨节点同步。网络开销模型：
\[
\text{Bandwidth (bytes/s)} = N_e \times N_p \times f_u \times B_{avg}
\]
- \(N_e\)：实体数量
- \(N_p\)：跟踪 / 看到这些实体的玩家数量（即在线玩家或处于视距玩家数）
- \(f_u\)：每秒更新频率（updates per second），即实体向客户端发送状态的次数
- \(B_{avg}\)：每次更新包平均字节数
示例假设：
- \(N_e = 120\)
- \(N_p = 100\)
- \(f_u = 1\)（静态实体，一秒一次或客户端请求时更新）
- \(B_{avg} = 200\) bytes
代入：
\[
120 \times 100 \times 1 \times 200 = 2,400,000 \, \text{bytes/s} ≈ 2.29 \, \text{MB/s}
\]
如果更新频率提高（如 \(f_u = 2\)），或包体积更大，带宽需求成比例增长。
此外，还要考虑节点间同步实体状态时的带宽（主节点 → 从节点）类似模型，每当状态变化就会跨节点推送实体变更包。这个开销通常比客户端推送低（玩家数量通常比节点少），但在高交互场景也可能显著。
对于 Minecraft / Bukkit / Spigot / Paper 类服务器，每个实体更新包可能包含位置、旋转、metadata、NBT 数据等（数十到几百字节）。在 “Entities & Packets” 讨论中，客户端在 chunk load 时会接收到实体 spawn 包、metadata 包等。 :contentReference[oaicite:8]{index=8}
因此上面的模型虽简化，但在 Minecraft 插件环境下是合理的第一阶估算。
### 3.3 总开销比较与负载分布
- **Tick / CPU 开销**：与玩家数量无关，只看实体数量与实体复杂度
- **客户端带宽开销**：与玩家数量成正比
- **节点间同步开销**：与实体变更频率 + 节点数 + 状态同步包大小有关
- 在 MultiPaper 架构下，理想还应加上“实体所有权转移 / 主控协调”开销，但它通常是偶发性的且低频。
---
## 4. 风险点、边界案例与优化建议
### 4.1 风险点
- **实体同步冲突 / 所有权错乱**：当 chunk 控制权在节点间切换时，实体可能会在切换过程中被删除或重复。
- **同步延迟 / 丢包**：网络延迟或丢包可能导致某节点短暂看不到家具或状态不同步。
- **高并发操作冲突**：多个玩家同时在多个节点操作同一区家具，可能导致状态冲突、覆盖或错误。
- **带宽峰值瓶颈**：在玩家密集区域，如果 many 家具同时改动，瞬时带宽需求可能超出带宽上限。
- **客户端渲染压力**：即使服务器能承担，客户端也可能因过多实体渲染而卡顿。
### 4.2 优化建议（再细化）
- 优先使用 `item_display` 类型家具以减少 `c_{tick}` 与包体积开销。
- 在家具配置中使用 `render_size`、`hitbox` 限制视距外剔除（让实体在玩家看不到时不发送更新）。
- 设置合理的 `max_per_chunk` 与 `custom_entities.max_per_chunk`，不要让某一区块家具密度过高。
- 对高交互 / 高实体密度区域做节点局部化（让一个节点专责处理），减少多节点同步转交风险。
- 启用 MultiPaper 的 `sync-entity-ids` 以保证节点间实体 ID 对应一致。 :contentReference[oaicite:9]{index=9}
- 在交互操作上（放置/拆除）做短时锁 / 互斥 / 重试保护，避免冲突。
- 使用 `/spark profiler` 或 `/timings` 定期监测 `entity-ticking`、`netty write` 等模块负载。
- 若可能，对节点间同步流量做压缩 / 差分更新（仅发送变化部分，而不是整实体 metadata），以减少带宽。
---
## 5. 完整的增强版说明文档（Markdown 保存版）
（你可以把下面整段复制为 `.md` 文档）
```markdown
# MultiPaper 与 ItemsAdder 兼容性与性能分析（增强版）
## 摘要
在无官方兼容保证下，实测表明 MultiPaper 与 ItemsAdder 可实现跨节点家具有视与交互。本文通过机制分析、性能模型、风险点评估与优化建议，给出更详尽说明。
## 背景与术语
- MultiPaper：一种将 Minecraft 世界跨多服务器分布的方法，节点通过点对点通讯与主控数据库同步 chunk/实体数据。
> 各服务器缓存所需 chunk，并与其他节点同步状态。 :contentReference[oaicite:10]{index=10}
> 在 “How It Works” 中，实体 / 块状态同步是核心机制。 :contentReference[oaicite:11]{index=11}
> 在配置中，`sync-entity-ids` 控制实体 ID 在节点间同步。 :contentReference[oaicite:12]{index=12}
- ItemsAdder：Bukkit/Spigot 插件，用于添加自定义家具、实体、物品等。家具通过实体 + 插件数据层实现。
> 支持多种实体类型（`item_display`、`armor_stand`、`item_frame`）及渲染优化选项。 :contentReference[oaicite:13]{index=13}
> 社区建议 `item_display` 可显著减轻性能开销。 :contentReference[oaicite:14]{index=14}
> 支持设定 `max_per_chunk` 等限制。 :contentReference[oaicite:15]{index=15}
## 兼容机制假设与证据
- MultiPaper 原生支持实体/状态同步功能
- IA 家具实体 + 插件数据结构允许跨节点同步
- 实现路径可能是：实体在一个节点生成 → 同步给其他节点 → 各节点再本地镜像实体 → 玩家跨节点互动事件同步 → 插件处理 → 再广播变更
## 性能开销模型
### CPU / Tick 成本模型
\[
\Delta MSPT = N_e \times c_{tick}
\]
- 假设 armor_stand 模式 \(c_{tick} = 0.02\) ms
- 假设 item_display 模式 \(c_{tick} = 0.005\) ms
- 若 \(N_e = 120\)，则：armor_stand 模式开销 ≈ 2.4 ms/tick，item_display 模式 ≈ 0.6 ms/tick
### 带宽 / 网络包量模型
\[
\text{Bandwidth (bytes/s)} = N_e \times N_p \times f_u \times B_{avg}
\]
- 示例：\(N_e=120\)，\(N_p=100\)，\(f_u=1\)，\(B_{avg}=200\) bytes → ≈ 2.4 MB/s
- 若频率或包体变大，则成比例增长
- 需同时考虑节点间同步流量（实体状态广播）
### 总成本组成
- Tick / CPU：与实体数量、实体复杂度有关
- 客户端带宽：与在线人数、视距、更新频率有关
- 节点间同步：与同步频率、节点数、状态变化有关
## 风险点与边界案例
| 风险 | 描述 | 可能后果 |
|---|---|---|
| 实体所有权转移异常 | chunk 控制权切换时实体归属不稳定 | 家具丢失或重复 |
| 同步延迟 / 丢包 | 节点间通讯不及时 | 短暂不同步 |
| 并发操作冲突 | 多节点同时操作同一区家具 | 状态覆盖或错误 |
| 带宽峰值 | 家具频繁更新 | 带宽饱和 |
| 客户端渲染压力 | 大量实体渲染 | 客户端卡顿 |
## 优化建议
- 使用 `item_display` 类型家具，降低 CPU 与包体积
- 配置 `render_size`、`hitbox` 剔除视野外实体
- 调整 `max_per_chunk`、`custom_entities.max_per_chunk` 控制密度
- 局部化高交互区域至单节点处理
- 启用 `sync-entity-ids` 确保实体 ID 对应 :contentReference[oaicite:16]{index=16}
- 操作加锁 / 重试以避免冲突
- 定期使用 `/spark` 或 `/timings` 监测 `entity-ticking`、`netty write` 等指标
- 若可能，对同步包做差分/压缩优化
---
## 结束语
这份增强版说明结合公开文档与社区讨论，配合你实地验证出来的跨节点家具交互现象，提供一个有据可测的模型与风险分析。
建议你用这份作为基础，在你的真实服务器环境里替换假设为实际硬件参数，做对比测量，以得出你那套系统的“真实承受极限”。
附加补充：
说人话就是，multi paper端再多 该加载的ia家具仍然会造成负载，但不会被人数影响，假设mp的VCmaster那里的ia家具会被加载1000个实体家具，那么无论你下面的multipaper有多少人 只要被服务器加载了，1个人也是这么多，100个人也是这么多 不会影响tps 因为他只是个原版实体而已。
至于ia的兼容性，也只是兼容而已 俩官方我并没有找到对应的兼容 反而近期mm生物倒是兼容了个folia。
需要注意的是如果你不太了解multi paper 又想往里塞meg为驱动的生物/怪物。别想了 会丢失ai的，在mp的不同核心分片区域的时候的一瞬间，生物将会丢失该分片插件控制，但因为另一分片的区域接受不到这个生物负责的插件信息[比如mm，比如mcpets]，导致瞬间变成了原版生物，也就是后台配置中的这个生物的原版ai。但荒谬的是如果你短时间内把这个走到其他分片的meg生物推回原来的生成分片区域，他还是可以正常显示。
你也仍然需要注意 即便ia资源包每个分片核心都能调整一样，但每次meg生物生成的时候，另一分片的玩家们看到的只是一个原版生物头顶了个mm生物名称。
比如你使用pets召唤了你的一个中世纪守卫，他的后台mm写的生物是wolf，那么你生成这个守卫meg实体的时间，另一个multipaper分片的玩家们看到的，只是一个原版的狼 但ai在离开你召唤的分片区域之前还被你所在分片的核心插件 比如mcpets 比如mm 所控制而已。
以及根据一些同样实操测试过的服主，所反馈的类似于同步数据的问题。我没测过，因为篝火是全程封闭的大世界，地图提前定制跑好了，不会出现地图加载或者所谓相关服主反馈的问题需求。所以如果你是要用这个玩意开服且玩家会在里面跑图生成新区块，其稳定性我没测试过，如有结果可以留在此帖造福后人。
