[erlang-questions] Help creating distributed server cache

[Anthony Molinaro]

I mention riak because it gets you furthest quickest.  It solves the problems you outlined (REST API and LRU style caching), while avoiding the problems (assuming you use a player id for your key riak will route requests to the appropriate node, and it has LRU style caching).  In addition you get distributed caching which works even when nodes go down.

So it just seemed to fit your problem as described.

-Anthony

On Dec 6, 2012, at 2:26 PM, David Fox <david@REDACTED> wrote:

> So you'd suggest going with #2 instead of #1? Could you tell me why?
> 
> Thanks for pointing out riak's memory backend. Had forgotten about that :)
> 
> -David
> 
> On 12/6/2012 15:53, Anthony Molinaro wrote:
>> You might consider just using riak with the memory backend.  It already
>> has a REST API
>> 
>> http://docs.basho.com/riak/latest/tutorials/querying/Basic-Operations/
>> 
>> and with the memory backend you can set a ttl
>> 
>> http://docs.basho.com/riak/latest/tutorials/choosing-a-backend/Memory/
>> 
>> There's no need to keep processes running or do much of anything
>> other than install it on a few machines, configure it and go.
>> 
>> -Anthony
>> 
>> On Thu, Dec 06, 2012 at 03:43:22PM -0600, David Fox wrote:
>>> I'm currently developing a gaming server which stores player
>>> information that can be accessed from any of our games via a REST
>>> API.
>>> 
>>> So far I've thought of two ways to structure and cache player data:
>>> 
>>> 1. When a client requests data on a player, spawn 1 player process.
>>> This process handles: all subsequent requests from clients for this
>>> player, retrieving the player data from the DB when created and
>>> periodically updating the DB with any new data from clients. If the
>>> player is not requested by another client within... say 30 minutes,
>>> the player process will terminate.
>>> 
>>> 2. Just keep previously requested data in a distributed LRU cache
>>> (e.g., memcached, redis, mnesia)
>>> 
>>> Out of the two, I prefer #1 since it would allow me to separate the
>>> functionality of different "data types" (e.g., player data, game
>>> data).
>>> 
>>> There are just 2 problems with doing it this way that I'd like your
>>> thoughts and help with:
>>> I. I would have to implement some sort of "LRU process cache" so I
>>> could terminate processes to free memory for new ones.
>>> II. If a load balancer connects a client to node #1, but the process
>>> for the requested player is on node #2, how can the player process
>>> on node #2 send the data to the socket opened for the client on node
>>> #1. Is it possible to somehow send an socket across nodes? The
>>> reason I ask, is that I'd like to prevent sending big messages
>>> across nodes.
>>> 
>>> Thanks for the help!
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions