Olric: Distributed in-memory data structures in Go
github.com
github.com
Or in-process distributed rate limiting: https://github.com/mailgun/gubernator
https://github.com/golang/groupcache: groupcache is in production use by dl.google.com (its original user), parts of Blogger, parts of Google Code, parts of Google Fiber, parts of Google production monitoring systems, etc.
There was also a paper by google that I can't find right now.
Edit: Found it https://blog.acolyer.org/2019/06/24/fast-key-value-stores/
https://web.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf
* It is embeddable.
* Seems easy to install, even without Kubernetes.
I am just missing performance number to answer questions like: Is it significantly faster than etcd? Is it faster than tikv? And finally, is it faster than Redis Cluster?
What's the underlying algo/impl used for this? According to the release notes it uses a DTopic data structure. While interesting, I'm not really sure if this is a unique/new structure by the author (buraksezer) or if it is an impl. from a paper I'm not aware of.
If anyone has more information about it, let me know!
What would be the alternative to using a library like this? I’ve been looking for a good way to distribute workload to many machines and don’t want to invent it myself or jump into a very heavy system.
https://github.com/buraksezer/olric#golang-client
var clientConfig = &client.Config{
Addrs: []string{"localhost:3320"},
DialTimeout: 10 * time.Second,
KeepAlive: 10 * time.Second,
MaxConn: 100,
}
client, err := client.New(clientConfig)
if err != nil {
return err
}
dm := client.NewDMap("foobar")
err := dm.Put("key", "value")
// Handle this errorI would think a green build CI should be required for merge to master, even if perhaps the tests don’t all pass.
Bad response status from coveralls: 422
{"message":"service_job_id (716381595) must be unique for Travis Jobs not supplying a Coveralls Repo Token","error":true}
In projects I'm involved with, the vast majority of CI errors were due to stupid things, not actual code problems. For example, last week our tests were failing because the east coast IBM data center that ran the tests was offline due to extended power outages from the weather.
The modern trend is that master is sacred and should always pass.
Why justify this with some categorical normative? In the last 7 or 8 years of my development life the master branch on every project I've worked on has always been clean. Breaking changes live in a branch and those branches are becoming shorter and shorter lived (previously lived for months, then weeks, now days).
That doesn't necessarily mean master is at all time ready to release (although some hold that extreme position). But it does mean that whenever you want to start work on some new feature you can be sure that branching from master is safe. And rebasing against master at any point should be safe.
In fact, almost all repos I've worked with recently explicitly deny merges into master unless a suite of tests pass, including basic builds, unit tests, and static code linting. The very idea that I could ever pull master and get a build failure makes me shudder.