12 Performance and Concurrency

12 性能与高并发说明

中文版本 | English version

这一页说明当前版本在高并发传送场景下的大致行为。它不是调参手册，但可以帮助管理员理解哪些设置会影响服务器负担。

基本原则

Minecraft 服务端世界逻辑以主线程为核心。这个模组会尽量把可以异步处理的工作移出主线程，但真正执行传送、读取关键世界状态、向玩家反馈结果时，仍然需要遵守 Minecraft 的线程限制。

因此性能目标不是“所有事情都异步”，而是：

• 批量传送时削峰填谷。
• 避免不必要的区块加载。
• 对高并发 RTP 做专门处理。
• 对长距离 Wild 做全服预算内的分批区块加载。
• 对共享 home 广播限制每 tick 的分发工作。
• 默认关闭额外日志。

已知目标传送

home、sharedhome、warp、back、worldspawn 属于已知目标传送。

这类传送会经过统一的 delay、cooldown、pending 管理和批处理逻辑。大量玩家同一时间触发传送时，系统会分批处理，避免在单 tick 内做过多工作。

如果启用了目标安全检查，安全检查会读取目标点附近方块信息，因此只在目标预加载开启时执行。默认情况下，目标预加载和默认目标安全检查都关闭。

RTP

RTP 的性能特征和已知目标传送不同。它需要在随机范围内尝试寻找安全落点，因此主要消耗来自落点选择与安全判断。

当前 RTP 会按请求数量选择合适的处理方式：

• 普通负载下按受控批次处理。
• 高并发 backlog 较大时使用并行工作线程处理安全落点查找。

RTP 使用独立安全逻辑，不受已知目标传送的 defaultSafetyCheck 和目标预加载开关影响。

Wild

Wild 的主要成本不是在已加载区域读取大量候选，而是准备远距离区块。为避免一个玩家或一批同时请求在单 tick 内集中加载过多区块，Wild 把每次搜索拆成有限批次，并限制每 tick 处理的就绪批次数量。

每批只抽取少量区块，并在每个区块内检查固定数量的随机地表列。区块 ticket、未完成加载和取消状态都由 Wild 自己管理；玩家离线、切换维度、取消操作或停服时会清理对应资源。增大 Wild 半径只会改变候选区块可能出现的距离，不会增加每次操作的批次数和候选数。

共享 Home

共享 home 的发布和订阅状态是轻量内存数据。向在线玩家发送发布信息时不会在一个 tick 内无上限遍历和发送，而是通过有容量和时效限制的队列分批处理。重复广播同一个发布会合并到已有待发送项。

TPA

TPA 请求本身较轻量。接受后的实际传送会按请求接受顺序处理，并受到 delay/cooldown 等通用规则影响。

TPA 请求过期清理不会要求管理员手动处理；过期请求会被自动清理。

预加载半径

teleporting.preloadRadiusChunks 控制目标预加载半径，有效范围为 0 到 3。半径越大，一次传送可能保留的目标区块越多。

建议：

• 小型服务器通常保持默认即可。
• 只在确实需要目标附近更平滑落地时开启预加载。
• 不要把预加载半径设置得过大。

调试日志

debugEnabled=false 是默认值。额外调试日志主要用于排查问题，不建议长期打开。

排查时开启：

/tpc debug true

排查结束后关闭：

/tpc debug false

管理员排查方向

如果服务器在传送高峰出现压力，建议按顺序检查：

1. 是否开启了目标预加载。
2. preloadRadiusChunks 是否过大。
3. 是否开启了默认目标安全检查。
4. RTP 半径是否过小导致有效落点过少。
5. Wild 是否频繁把目标推向大量尚未生成的远处区块。
6. 共享 home 广播冷却是否被设置得过低。
7. 是否长期打开 debug 日志。