SSBProxyBridge
为 SuperiorSkyBlock2 添加多服同步
这是一个添加了群组（如 Velocity 或 BungeeCord）兼容的附属。这个模块可以用于单个子服无法负荷的群组服中。
常见问题
它是免费的吗？
抱歉，不是。这个附属是付费的，且按月订阅，每个月大约 30$。原因是这个模块只针对大型服务器（所以有足够的收入用于购买本插件），且开发团队在这里投入了很多精力。插件不依赖 SuperiorSkyblock2，另外购买用户也会获得付费支持（帮助搭建、漏洞修复、提供问答等等）。
世界是否可以被保存至服务器中？
抱歉，不行。岛屿不可以被序列化并存入数据库中，因为附属无法修改世界处理的方式。
附属是否能实现“一岛一服”？
附属只会将玩家引流至现有的服务器，并确保他们均匀分散。
附属是否支持 SlimeWorldManager 或其他相似的世界管理插件？
是的，附属不会破坏现有的世界管理模块。
是否能随时间添加更多服务器？
是的，你可以添加新的服务器，这样玩家就会被引入其中。
但是，移除服务器可能会导致岛屿无法加载，且玩家无法传送。
玩家是否可以访问其他子服的玩家并与之交互？
当然！模块旨在不妨碍玩家正常的游玩体验。
服务器关闭时会发生什么？
当服务器出现问题时，玩家会转回大厅服，他们将无法回到自己的岛屿。这听起来可能有点问题，但这就像服务器维护——等维护结束自然可以进入游玩。这种情况不应常出现，空岛实例应当与整个群组服持续存在。但好处是数据不会损坏——如果服务器关闭不是崩溃导致的，那么数据不会受到影响。
内部
在我们开始讲解模块内部机制之前，我们需要先了解 SuperiorSkyBlock2 保存数据的方式。每个对象都可以被保存至数据库（岛屿、玩家等）都有一个对应类用于处理数据库交互，且对象之间独立。这个类就是数据库与对象间的桥梁，即“DatabaseBridge”。
在玩家作出需要交互数据库的改动时，对象先调用数据库桥的方法，之后再与数据库异步交互。这可以让插件不必担心数据库的实现，即与任意种类的数据库兼容——SQL、MongoDB 以及能实现数据库桥所需方法的其他数据库。
你可能会问自己，为何这么重要？这就是奇妙的地方。新附属会处理插件中的对象与数据库桥——因此，它会将数据导向别处而非存入数据库进行处理。因为这个过程完全异步，所以无需担心性能问题。
既然我已经解释了附属的目的，我们需要理解并处理我们接下来碰到的一系列问题：
- 负载平衡；我们需要将岛屿分散在各个子服，而不是让它们全部堆积在同一服务器。
- 附属兼容；例如 SlimeWorldManager 世界等。我们仍然需要支持其他模块（除了一并修改数据库桥的那些）。
- 数据同步；我们需要邀请、聊天消息能在服务器之间显示。
- 支持多群组；现在单个群组可能不足以支撑足够的玩家，多群组组成的网络才能胜任。
- 性能；最重要的就是让服务器保持在性能最佳状态。否则，附属的意义何在？
我将会在之后的篇幅中详细解释这些问题，并给出相应的解决方案。
负载平衡
为了让服务器能有较好的性能表现，这个附属会将玩家分散至子服。为了实现这个功能，它在玩家一侧表现得像负载均衡器，寻找条件最优的服务器并将玩家的空岛创建在此处。
在空岛实例中的附属还会有一些额外效果——它也是一个群组插件，能够查询服务器。群组端会试图搜寻每个服务器的岛屿，并会记录其活跃状态。总而言之，拥有更多活跃空岛的服务器更有可能卡顿。因此，创建岛屿时，附属会寻找活跃岛屿最少的服务器，并与服务器上的插件沟通从而创建岛屿。之后，玩家就会被传送至对应的服务器。
附属兼容
正如上文所述，附属只会修改插件的数据库层，并将原本转入数据库的数据转至其他远程服务器。这使得修改其他内容的附属不会受该附属的影响。只要你保持空岛实例的配置与附属同步，所有功能都会如常运转。
数据同步
本附属的最大功能就是在多个子服间同步数据。为了实现这个功能，服务器必须先与其他子服沟通，才可在其间同步数据。问题是“这如何实现”，那么在本段中我们就会着重讲述。
在我们详细了解之前，我们首先需要考虑一些事：
- 岛屿可以被任何服务器修改，因此改动应当被同步（多个对同一岛屿的改动应当包含所有改动）
- 我们需要一个能让空岛实例在服务器间相互沟通的组件（信息队列/中断器）
- 我们需要一个处理数据保存的组件（数据库）
消息队列/代理
这是一种设计模式，用于处理服务之间的异步沟通。例如，当一个服务想要通知其他服务事件时，它会向第三方组件发送消息，之后其他服务即可从该组件读取消息，而非直接与它们沟通。这样的设计会破坏服务之间的硬链接，并允许多个服务器相互沟通——这个组件就称为消息代理（Message Broker）。消息代理以一个队列存储它收到的信息（首条收到的消息即为首条读取的消息），服务可订阅消息代理并读取它收到的消息。因为服务之间没有直接连接，服务只能在它们被允许的时候读取来自代理的消息，这有助于提升性能。
在我们的示例中，空岛实例会让其他实例收到某些事件——岛屿创建、岛屿数据解读等。之后，其他空岛示例会监听消息并更新数据，同时完成其他必要的操作。这样的一个例子就是创建岛屿。
数据库
为了在重启之后仍能保留数据，我们需要通过某种方法将其存储在数据库中。在普通插件中为 SQL 数据库，可本地也可远程。而在本附属的情况下，数据库必须使用远程类型——这样所有空岛实例都可与其交互。数据库除了必须为远程类型以外，没有任何限制或条件。最理想的数据库是 Redis，它既可以是数据库，也可以是消息代理（上文提及），但所有选择都取决于你。
多群组
如今，大型网络群组并不能只依赖一个群组（无论 Velocity 或 BungeeCord）来承载所有玩家，因此他们需要多个群组。这使我们面临着一个新的挑战——我们如何在多个群组之间同步所有数据？
一开始这听起来可能会很吓人，但在了解多群组的搭建后，这其实会非常简单。群组都会连接至同一服务器，因此来自于群组 A 的玩家可以一起与群组 B 的玩家游玩。玩家无法感知这种安装方式，因此也不会注意到什么——因此，剩下的只有了解附属如何与群组交互，以及我们如何安装它。附属需要与群组交流，并做两件事——首先是在服务器间迁移玩家，其次是知晓玩家的新岛屿创建在哪个服务器。
管理器
在多个群组服中，我们需要一个能够管理所有群组下空岛的第三方服务。管理器会等待空岛实例并与之交流，并在之后自行处理一切。它会记录岛屿所属服务器，并通过岛屿活跃状态自动选择创建新岛屿的最优服务器。
在玩家创建岛屿时，附属会先向管理器发送请求并选择创建岛屿的最优服务器，而非直接在服务器上创建岛屿。之后，它会检查选中的服务器是否为自己所在服务器——如果是，那么将进行正常的岛屿创建流程，之后便会将玩家传送至新岛屿。
管理器负责处理如下内容：
- 注册新服务器
- （当服务器关闭时）注销服务器
- 选择创建岛屿的最优服务器
- 该过程应当检查活跃数量最少的岛屿。
- 获取岛屿所在的服务器
安装教程
第一步：下载 zip 文件。
下载本拓展后，你得到的是一份包含多个文件的压缩包：
SSBProxyBridge-X.Y.Z.jar- 此即为拓展 jar 文件本身。它应当安装在所有子服上。SSBProxyBridge-Manager-X.Y.Z_standalone.jar- 此为独立管理器 jar 文件。它应当以启动服务器核心的方式使用。
第二步：初次运行
运行管理器及所有子服实例。这个操作会生成附属的所有配置文件，以及初始化管理器。
第三步：配置
管理器配置
你可以配置管理器监听的 IP 及端口，以及 keep-alive 间隔和不会生成岛屿的服务器，无需将未安装附属的子服列入该列表。
附属配置
附属的配置文件比管理器的更复杂。它包含两个需要配置的主要部分：messaging-service 和 manager。这些部分决定了附属于其他子服和管理器的通信方式。在运行服务器之间正确配置这些内容很重要。
警告
在配置 server 不分是，确保填入的 ID 与群组（Velocity 或 BungeeCord）配置下的子服名称相同。
贡献者
SnowCutieOwO