3 ms·
Go is usually used for microservices, and for that scenario, Ristretto is not applicable since it's a library, and not a "shared server" like Redis. Am I right?
by wiradikusuma 7y ago
Go is usually used for microservices, and for that scenario, Ristretto is not applicable since it's a library, and not a "shared server" like Redis. Am I right?
- kasey_junk 7y agoIf you mean will it persist across restarts, then no. If you mean does it have a built in network protocol, then no. But neither of those are requirements for micro services. I certainly will try this out the next time I need a cache in my microservice.
- sethammons 7y agoMicroservices are long lived and having an in-memory cache can alleviate network calls and improve response time, depending on the kind of work being done. A shared cache like redis requires a network call obviously. One of our caching libs does just that: check memory, then check redis, then do the expensive data collection from source.
- mrjn 7y agoOne way to make Ristretto act as a server would be to bake it into Group cache. Which is the equivalent of memcached in Go.
- wrnr 7y agoVery much to the contrary, why go over the network to get a value from a key-value store when you can have a mutex protected map that only hods the values that where accessed by that node. The "lets have a shared memory between our services" architecture makes things easy only to make it much harder again.
- hinkley 7y agoI’ve been trying to convince my coworkers that we should have a cache per node, but so far they aren’t biting. Alternatively I think within the decade we are going to expect every service to contain its own fault prevention logic instead of just the web tier. At which point every service has its own reverse caching proxy in front of it.