mirror of
https://github.com/hanzokv/lock.git
synced 2026-10-30 15:07:01 +00:00
zeekayandHanzo Dev
1ad510e19d
github.com/hanzokv/go/v9 v9.22.0 renamed its Go package from "redis" to "kv"; the import path is unchanged. A lock library is typed against the client it wraps -- the adapter's NewPool takes the client's UniversalClient and compares against the client's Nil sentinel -- so the qualifier change is load bearing, not cosmetic. Client-driven: - go.mod: github.com/hanzokv/go/v9 v9.21.1 -> v9.22.0 - the adapter for our client speaks kv.UniversalClient / kv.Nil, imported unaliased as in hanzokv/go's own sources Our own vocabulary follows: - redis/ -> kv/, package redis -> package kv. This is redsync's own Pool/Conn/Script abstraction over a KV backend, not anyone's product. - redis/goredis/v9 -> kv/kvgo (package kvgo). That adapter wraps hanzokv/go, not go-redis; the old name said the wrong thing. Its example moves with it: examples/goredis/v9 -> examples/kvgo. - import alias redsyncredis -> redsynckv - RedisError -> KVError (and its tests) - comments and README speak kv Deliberately NOT renamed, because they name foreign things: - the redigo, rueidis, valkeygo and go-redis v6/v7/v8 adapters, which target genuinely different clients, keep their names and their own "redis." qualifiers (redigo's redis.Conn, go-redis's redis.Nil) - the server-side Lua in scripts.go: redis.call is the store's scripting API. Rewriting it would change the script source and therefore the SHA1 hashes pinned in scripts.go, which TestScripts_Hash verifies against a live server. - upstream links (redis.io distlock post, redigo attribution) Import paths move from .../v4/redis/... to .../v4/kv/...; the module major stays v4 by policy. Verified with a local redis-server: go build ./..., go vet ./..., go test -count=1 ./... and go test -race -count=1 ./... all pass, TestScripts_Hash included. Co-authored-by: Hanzo Dev <[email protected]>
3.5 KiB
3.5 KiB
Redsync
Redsync provides a KV-based distributed mutual exclusion lock implementation for Go as described in this post. A reference library (by antirez) for Ruby is available at github.com/antirez/redlock-rb.
Installation
Install Redsync using the go get command:
$ go get github.com/hanzokv/lock/v4
Driver implementations for several clients are installed; however, only the one used will be included in your project.
See the examples folder for usage of each driver.
Documentation
Usage
Error handling is simplified to panic for shorter example.
package main
import (
kvlib "github.com/hanzokv/go/v9"
"github.com/hanzokv/lock/v4"
"github.com/hanzokv/lock/v4/kv/kvgo"
)
func main() {
// Create a pool with hanzokv/go (or redigo) which is the pool redsync will
// use while communicating with the KV store. This can also be any pool that
// implements the `kv.Pool` interface.
client := kvlib.NewClient(&kvlib.Options{
Addr: "localhost:6379",
})
pool := kvgo.NewPool(client) // or, pool := redigo.NewPool(...)
// Create an instance of redsync to be used to obtain a mutual exclusion
// lock.
rs := redsync.New(pool)
// Obtain a new mutex by using the same name for all instances wanting the
// same lock.
mutexname := "my-global-mutex"
mutex := rs.NewMutex(mutexname)
// Obtain a lock for our given mutex. After this is successful, no one else
// can obtain the same lock (the same mutex name) until we unlock it.
if err := mutex.Lock(); err != nil {
panic(err)
}
// Do your work that requires the lock.
// Release the lock so other processes or threads can obtain a lock.
if ok, err := mutex.Unlock(); !ok || err != nil {
panic("unlock failed")
}
}
Contributing
Contributions are welcome.
License
Redsync is available under the BSD (3-Clause) License.
Disclaimer
This code implements an algorithm which is currently a proposal, it was not formally analyzed. Make sure to understand how it works before using it in production environments.
Real World Uses
Below is a list of public, open source projects that use Redsync:
- Sourcegraph: Universal code search and intelligence platform. Uses Redsync in an internal cache implementation.
- Open Match by Google: Flexible, extensible, and scalable video game matchmaking. Uses Redsync with its state store implementation.
- Gocron by go-co-op: gocron is a job distributed scheduling package which lets you run Go functions at pre-determined intervals using a simple, human-friendly syntax. Uses Redsync with its distributed job scheduler implementation.
If you are using Redsync in a project please send a pull request to add it to the list.