Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: replicated cache #16

Merged
merged 32 commits into from
Apr 17, 2024
Merged

feat: replicated cache #16

merged 32 commits into from
Apr 17, 2024

Conversation

jdockerty
Copy link
Owner

@jdockerty jdockerty commented Apr 10, 2024

Closes #12

Supersedes #9 in terms of providing some sense of non-local caching to the project.

TODO

  • The replication compilation flag should be enabled by default.

jdockerty and others added 24 commits April 11, 2024 12:25
* feat: implement wrapper client

* feat: impl Client trait
As part of the replication, we'll need a version/generation number or
similar in order to distinguish between later versions of a value on
various remote stores. We can use the timestamp for this and the
most recent (highest) value will win, i.e. last-write wins.
As part of the replication, we'll need a version/generation number or
similar in order to distinguish between later versions of a value on
various remote stores. We can use the timestamp for this and the
most recent (highest) value will win, i.e. last-write wins.
The initial implementation of this was slightly backwards with the
naming. The ReplicationClient which also served requests does not
make much sense. The better way to understand this is this commit
entails, that is a ReplicatedServer which contains its own store
and a client with an awareness of other server stores.
Need to fix deadlocks
Simplify to 3 nodes max for logic and try impl with futures Either/select functionality
Move to static node count within cluster
The replication with 3 `ReplicatedServer`'s is an infinite loop for
retrieval and setting. The replication strategy should actually be a
single server that is configured to replicate to other nodes, static to
2 for now.
@jdockerty jdockerty force-pushed the feat/cache-replication branch from 1ef3038 to b4a2847 Compare April 15, 2024 19:03
@jdockerty jdockerty force-pushed the feat/cache-replication branch from b4a2847 to b102616 Compare April 15, 2024 19:36
Simplify architecture for replication mode such that we use a simple
leader/follower model. Leader will simply replicate to followers.

This can be altered in the future for smarter replication strategy
or even distribution via consistent hashing etc.
@jdockerty jdockerty merged commit 06707ec into main Apr 17, 2024
1 check passed
@jdockerty jdockerty deleted the feat/cache-replication branch April 17, 2024 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Replicated k-v
1 participant