从今年早些时候开始关注 MultiPaper，到现在 MultiPaper 的完成度终于值得让我写一篇文章赞美一下了（好欸！
MultiPaper 诞生的背景
TPS 的概念
每个架设过 Minecraft 的服主都多多少少要和 TPS (ticks per second) 打交道，MC 这个游戏的游戏世界所有内容都基于一个循环进行计算，每一个循环称为 1 个tick，每秒循环 20 次，如果这一秒循环次数不够 20 次，则会出现卡顿的情况，服务器会在下一秒尝试多循环补偿 tick 丢失。
由于每个部分（方块、生物、AI等等）他们之间都互相关联引用，这也导致了所有计算都必须在同一个线程上进行，也就是 MC 常被人吐槽是个单线程游戏的原因。
游戏的优化
说实话，Minecraft 游戏的优化可以说是相当糟糕，仅限于 <10 人能玩的程度。
随着版本的更新，越来越多的内容被加入到游戏中，Server Thread（负责逻辑运算的线程，下称主线程）越来越不堪重负，以至于在最近几个版本，不使用第三方服务端的情况下，几乎无法多人游玩的情况下达到 20 TPS 的程度。
组建一个像是 CDN 一样的 Minecraft 网络
在 MultiPaper 诞生之前，大部分服务器都通过诸如 BungeeCord 或者 Velocity 等的代理软件，通过区域切割、架设子服务器等手段，将玩家分散到不同的 MC 服务器实例中，抑或是对部分内容进行异步计算以减轻单个服务器实例的负载压力。
然而，这种手段割裂了玩家的游戏体验 —— 每个实例都单独管理和计算，玩家几乎不可能做到在同一个地图内互相交互 —— 而异步计算的内容有限，主线程仍然成为了性能瓶颈。
水平拓展
垂直拓展已无空间，那么为什么不水平拓展呢？
Minecraft 的主线程设计导致水平拓展要考虑大量的互相通信和数据同步问题，在此之前，不要说多实例，甚至多线程的服务端都寥寥无几。
而 MultiPaper 正是为此而生的。
主从设计
MultiPaper 采用了常见的主从设计，如果不熟悉的话 —— 类似 MySQL 的 Master & Slave 之间的关系。
Master 主管调度和数据存储与同步，可以单独运行或者作为 BungeeCord/Velocity 插件运行。
各个 Slave 各持有一部分区块的 “控制权”，每个 Slave 之间通过 Socket 方式相互通信。
当需要跨服务器读取数据时，Slave 会根据情况选择向 Master 请求目标区块的控制权，或者进行 P2P 通信；而更改也会通知到其他所有需要更新的服务器中。
区块控制权
区块控制权是 MultiPaper 的核心 —— 它决定了一个区块是被哪个 Slave 负责 tick 和管理。
对于复杂操作例如 TNT、双箱、红石等（或者频繁操作），Slave 会向 Master 申请目标区块的控制权。
一旦成功，该区块的 tick 和管理权限将由原 Slave 转交给发起请求的 Slave，也就完成了 “区块控制权的转移” 同时也是 “负载的转移”，这样就完成了负载均衡的目标 —— 即将负载平均到多个实例中。
除了上述提到的情况会请求控制权外，如果某个 Slave 意外下线，另一个 Slave 也会按需要将其接管。
实例间的 P2P 通信
除了控制权争夺外，还有另一种通信方式：Peer Connection。
在控制权争夺失败，或者少量交互的情况下，MultiPaper 会使用一种 P2P 的方式互相通信。
常见的，部分情况下 AI 寻路、PVE等就是 P2P 形式进行的。
缺点也非常明显，P2P的形式会出现网络通信不可避免的延迟问题。
不过好在除了抛掷物以外，其他的延迟基本不可感知。
体验衔接
MultiPaper 跨服务器几乎是完全不可感知的，不论是生物寻路、跨服务器大箱子打开、漏斗、火焰蔓延、刷怪笼、原版命令、Allay 寻找物品、村民跨服获取职业和操作方块，一切都是无缝的体验。
不过 P2P 的抛掷物会出现一些延迟和不同步问题，大概以后会解决：
MultiPaper 是大型 Minecraft 网络的 【目前来说】的最佳解决方案
正如官方 Github 所讲，MultiPaper 构建的 Slave 集群可以轻松托管超过 1000 个玩家（当然，CPU核心数 和内存得管够）。
官方的 Master 内置的代理可以把玩家分散到负载较低的服务器中达到负载均衡的效果。
（至少是一个Slave TPS崩塌了不会影响其他 Slave）
对 MultiPaper 进行 LambdaAttack 压力测试，共有 4 个 Slave，双视距为 10 chunks，不修改任何配置和打开优化开关，每个玩家进入服务器时都随机传送，测试玩家人数 1000 人，效果如下。
关于有人问到的 “玩家怎么无缝跨 Slave 的，是传送吗？” —— 玩家永远不会更改自己的 Slave 服务器，进去哪个就一直是哪个，都是跨服通信而已。
为什么说 MultiPaper 是未来
以 Paper 为首的社区目前仍然在积极的提升单实例的性能，目前已经被引入的异步区块生成、异步区块加载和IO、AI控制、重写的照明引擎等等已经对比 Vanilla 服务端有了相当大的提升。而且也在致力于引入新的性能补丁——例如区块系统重写的补丁。
然而，就像 CPU 的制程提升是有限的一样，无论在单个实例上做出多少优化，最终都会被软件或是硬件的性能瓶颈所限制。
对于大型 Minecraft 服务器来说，这种水平拓展的能力仍然是必要的。
来自 MultiPaper 官方的演示视频
- 1000 player hide and seek: https://www.youtube.com/watch?v=GRXQDYGWVn8
- 550 players demo on 3x 64GB Linode nodes, with 5 shards per node (15 total shards). Had more capacity than 550 players, but we got unlucky with one of the nodes, which had a significantly slower cpu than the other two. https://youtu.be/4FifTg8UVgo
- 1000 Players Simulate Prison in Minecraft: https://www.youtube.com/watch?v=t0rxOfr77YQ
国内可能无法访问↑
请问是怎么进行测试的？读完感觉很有趣就上手试了试，顺着试到这个LambdaAttack时发现好像只有1.16.5。
我用的BungeeCord+ViaVersion+Via Backwards
当然你可以选择其他直接支持的测试工具。
如果使用这样的形式，如何做到插件数据库同步？
同步不了，必须插件自己实现同步逻辑。
不支持就用不了。
有可能做到登录服务器控制客户端连接哪个slave吗（登录服务器作为类似dns服务器的存在）。如果这样倒是可以支撑大量玩家。
我记得应该可以
感觉看到了MC服务器的未来∠( ᐛ 」∠)＿
MultiPaper 可以说是在完全重写服务端和单纯的优化单端性能之间找到了一个比较完美的解决方法，他的架构设计也非常现代——可弹性伸缩、多节点、多物理机入口。目前唯一的问题是不兼容大部分插件，相信随着 MultiPaper 的开发和更多插件作者的加入，MC 的多人游戏又会有很多新的可能性
居然在这里相见你quq
就连粘液科技这种插件都兼容，不过不同服务器数据不同步是问题