You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 1, 2024. It is now read-only.
Snowflake includes a configuration file that allows you to set:
43
-
44
-
1. The data center number.
45
-
2. The worker node number.
46
-
3. The starting timestamp.
47
-
4. The sequence resolver.
48
-
49
-
Most developers won't need to alter these values unless they need to set up a distributed architecture for generating Snowflakes.
50
-
51
-
If you want to change any of the values, publish the configuration file using Artisan:
42
+
Snowflake includes a configuration file with several settings that you can use to initialize the Snowflake service. You should begin by publishing this configuration file:
52
43
53
44
```bash
54
45
php artisan vendor:publish
55
46
```
56
47
48
+
### Distributed architecture
49
+
50
+
The service allows for the use of a distributed architectural setup involving data centers and worker nodes that are each responsible for generating Snowflakes according to their own designated identifiers. For maximum flexibility, as well as backward compatibility, this is the default configuration.
51
+
52
+
If you do not intend to run a distributed architectural setup, then your first step should be to set the corresponding configuration value to `false`.
53
+
54
+
### Data centers and worker nodes
55
+
56
+
When using a distributed architectural setup, you'll need to set the data center and worker node that the application should use when generating Snowflakes. These are both set to `1` by default, as that is a good starting point, but you are free to increase these numbers as you add more centers and nodes.
57
+
58
+
The maximums for each of these configuration values is `31`. This gives you up to 31 nodes per data center, and 31 data centers in total. Therefore, you can have up `961` worker nodes each generating unique Snowflakes.
59
+
60
+
> If you have disabled distributed architecture, then you can skip the data center and worker node values as they will be ignored by the service.
61
+
62
+
### Starting timestamp
63
+
64
+
The service compares the Unix Epoch with the given starting timestamp as part of the process in generating a unique Snowflake. As a result, Snowflakes can be generated for up to 69 years using any given starting timestamp.
65
+
66
+
In most cases, you should set this value to the current date using a format of `YYYY-MM-DD`.
67
+
68
+
> Do not set the timestamp to a date in the future, as that won't achieve anything. You should also avoid using a date in the past, as that may reduce the number of years for which you can generate timestamps.
69
+
70
+
### Sequence resolver
71
+
72
+
In order to handle the generation of unique keys within the same millisecond, the service uses a sequence resolver. There are several to choose from, however they each have dependencies, such as Redis. You are free to use any of them, however the default option is a good choice, as it **doesn't** have any dependencies.
73
+
57
74
## Usage
58
75
59
76
You can generate a Snowflake by resolving the service out of the container and calling its `id` method:
0 commit comments