HuskLegacy
/
HuskSync
forked from public-mirrors/HuskSync
1
0
Fork 0
Code Pull Requests Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
master
dependabot/gradle/xyz.jpenilla.run-paper-2.3.1
dependabot/gradle/org.junit.jupiter-junit-jupiter-api-5.11.0
dependabot/gradle/com.google.guava-guava-33.3.0-jre
dependabot/gradle/org.junit.jupiter-junit-jupiter-params-5.11.0
dependabot/gradle/org.junit.jupiter-junit-jupiter-engine-5.11.0
feat/data-edit-commands
1.3
1.3.2
1.4
1.4-SNAPSHOT
1.4.1
2.0
2.0.1
2.0.2
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.2.8
3.0
3.0.1
3.0.2
3.1
3.1.1
3.1.2
3.2
3.2.1
3.3
3.3.1
3.3.2
3.3.3
3.4
3.5
3.5.1
3.5.2
3.5.3
3.6
3.6.1
3.6.2
3.6.3
3.6.4
3.6.5
3.6.6
3.6.7
3.6.8
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '29d8f2ecf4'
${ noResults }
HuskSync/docs/Sync-Modes.md

3.5 KiB
Raw Blame History

HuskSync offers two built-in synchronization modes that utilise Redis and MySQL to optimally sync data as users change servers (illustrated below). These sync modes change the way data is synced between servers, and can be changed in the config.yml file.

Overall architecture of the synchronisation systems

Available Modes

  • The LOCKSTEP sync mode is the default sync mode. It uses a data checkout system to ensure that all servers are in sync regardless of network latency or tick rate fluctuations. This mode was introduced in HuskSync v3.1, and was made the default in v3.2.
  • The DELAY sync mode uses the network_latency_miliseconds value to apply a delay before listening to Redis data

You can change which sync mode you are using by editing the sync_mode setting under synchronization in config.yml.

Warning: Please note that you must use the same sync mode on all servers (at least within a cluster).

Changing the sync mode (config.yml) 
synchronization:
  # The data synchronization mode to use (LOCKSTEP or DELAY). LOCKSTEP is recommended for most networks. Docs: https://william278.net/docs/husksync/sync-modes
  mode: LOCKSTEP

Lockstep

The LOCKSTEP sync mode works as described below:

  • When a user connects to a server, the server will continuously asynchronously check if a DATA_CHECKOUT key is present.
    • If, or when, the key is not present, the plugin will set a new DATA_CHECKOUT key.
  • After this, the plugin will check Redis for the presence of a DATA_UPDATE key.
    • If a DATA_UPDATE key is present, the user's data will be set from the snapshot deserialized from Redis contained within that key.
    • Otherwise, their data will be pulled from the database.
  • When a user disconnects from a server, their data is serialized and set to Redis with a DATA_UPDATE key. After this key has been set, the user's current DATA_CHECKOUT key will be removed from Redis.

Additionally, note that DATA_CHECKOUT keys are set with the server ID of the server which "checked out" the data (taken from the server.yml config file). On both shutdown and startup, the plugin will clear all DATA_CHECKOUT keys for the current server ID (to prevent stale keys in the event of a server crash for instance)

LOCKSTEP has been the default sync mode since HuskSync v3.2, and is recommended for most networks.

Delay

The DELAY sync mode works as described below:

  • When a user disconnects from a server, a SERVER_SWITCH key is immediately set on Redis, followed by a DATA_UPDATE key which contains the user's packed and serialized Data Snapshot.
  • When the user connects to a server, they are marked as locked (unable to break blocks, use containers, etc.)
  • The server asynchronously waits for the network_latency_miliseconds value (default: 500ms) to allow the source server time to serialize & set their key.
  • After waiting, the server checks for the SERVER_SWITCH key.
    • If present, it will continuously attempt to read for a DATA_UPDATE key; when read, their data will be set from the snapshot deserialized from Redis.
    • If not present, their data will be pulled from the database (as though they joined the network)

If your network has a fluctuating tick rate or significant latency (especially if you have servers on different hardware/locations), you may wish to use LOCKSTEP instead for a more reliable sync system.