[almighty] Cache solution for Almighty core

Aslak Knutsen aslak at redhat.com
Tue Nov 8 10:11:24 UTC 2016


We're talking about 2 different things here:

1. Local cache

The original intent for the Cache in question was to avoid fetching the WIT
for each WI from the DB, especially for List operations where we fetch 100
WIT's per page. And 99 of them are the same WIT.

Moving this to a centralized Cache server makes no sense, as the intended
purpose is to avoid network traffic on immutable objects.

2. Global cache

Microservices solutions would normally have a 'Reverse Proxy cache' on the
'consumer' side to cache aggregated data from multiple services.


-aslak-



On Tue, Nov 8, 2016 at 9:41 AM, Thomas Mäder <tmader at redhat.com> wrote:

> Hi Alexey,
>
> If you're talking about a "cache server" are you talking about a separate
> process, possibly on a different machine or an in-process service like
> groupcache?
>
> How I understand microservices, they DON'T have a shared DB behind them.
> They have a relatively simple datamodel that is loosely coupled to the
> other microservices via a well defined API (no peeking at the internals!).
> Multiple instances of the same service may share a common DB, but not
> different microservices. As a consequence of this, it doesn't make sense
> for multiple different services to share the same cache in my opinion.
> Instead of asking any shared cache service, you might as well ask the
> original service and let that one take care of caching.
>
> /Thomas
>
>
> On 11/08/2016 01:15 AM, Alexey Kazakov wrote:
>
>> Hi all,
>>
>> At some point we will probably need some universal cache solution which
>> we could use different types of objects in almighty core. I'm going to
>> spend some time on researching in this area but there are a few questions I
>> would like to discuss with the team.
>> There are some solutions like Memcached or Redis which could be used but
>> they require to have a server with the cache service (on a dedicated
>> container?) where we could keep WIT, WI and any other artefacts which we
>> want to access some value by a key. Some solutions like Memcached are pure
>> in-memory some like Redis can be persistent but my biggest concern for now
>> is what approaches are best for microservices world.
>> In monolith world we could have a shared cache server. One DB - one cache
>> service. But I'm not sure if it's worth having an internal dedicated cache
>> server for each relevant microserver.
>> Currently we are kinda building a monolith and a cache server could work.
>> But how our cache system should evolve when we start splitting/introducing
>> microservices in almighty-core? Is there any concept of shared cache
>> between microservices or it's always hidden by the microservice
>> implementation and the microservice just takes care of synchronization of
>> its internal model/DB and uses some internal fully independent cache if
>> needed.
>>
>> Any thoughts?
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161108/d3dbbac3/attachment.htm>


More information about the almighty-public mailing list