If you are doing this in Java, you can use ehcache server. Actually, your clients don't need to be java based. The last time I looked there were no clients for doing the partitioning of requests to servers. I think there is a diagram and description of this scenario on the ehcache web site. I'm not using ehcache server myself though, so I can't say how good it is. I prefer a combination of ehcache and memcache. Cheers, John
On Fri, Jul 3, 2009 at 7:22 AM, sven bommezijn <[email protected]>wrote: > > Well, I do not want to kick against any religion, but in grid > computing (like for example Java Spaces) memory is the new harddisk. > Since memory gets cheaper and processors are becoming faster I think > there IS some cause for a memcached like mechanism to be used in a > distributed, replicated way. > > I am thinking of a configuration where different memcached servers > maintain a copy of themselves on secondary (or even more) machines. > In the unlikely event of one primary server going down the client just > refers to a secondary server. > > Memcached entries might replicate themselves after a put or replace > operation is completed. > Particularly when Memcached is used for sessions it is unlikely that a > get operation will follow in the instant that a put or replace > operation has completed on the same entry. > > I realize that this takes up extra network bandwidth and cycles but it > definately offers an interesting mechanism for load balanced > webservers hitting the same cache to retrieve session data. And if I > am not mistaken such an architecture would still be of O(1), that is > it still would grow lineairly with web traffic. > > Anyone interested in a discussion about this? seems a nice optional > feature for Memcached. >
