memcached replication

[Dustin Sallings]

On Sep 5, 2007, at 19:04, Aaron Stone wrote:

> I have thought about doing this, too -- the issues I'm raising are the
> ones that were raised to me when I started talking about the idea...
>
> A major design goal of memcache is to have all operations be roughly
> order 1. A notification system would be order n with the number of
> listeners on that key. Also, where would the memory for keeping  
> track of
> listeners go?

	I wasn't thinking about doing per-key notifications.  I just want a  
stream of invalidations.

	The memory overhead would be roughly the same as any other  
connection, although you'd want some simple structure you could use  
to know what subscribers existed without having to look through *all*  
connections.

	I imagine the process would be triggered off of anything that would  
reclaim space for a given key and basically queue an event for all  
listeners to write out the key that got invalidated.  It should be  
possible for them all to share the same instance of the structure to  
send and just decrement a reference count such that the last one  
releases the structure.

	So yeah, you'd be O(listeners), but the cost should be really low  
there.  Mostly  just ensuring they're in a write state and have  
something to write.

> I had originally thought that this would make the most sense with
> per-key notifications. Maybe it would be better to do this as a global
> notification system? That might entail adding one new keyword to the
> protocol which puts a TCP session into notification mode until the end
> of the session.

	Right, this is what I was imagining.

-- 
Dustin Sallings