Make Memcached available as a message store about nchan HOT 8 CLOSED

Yup - this would be awesome... ++

from nchan.

The trouble with this is that memcached uses a strictly one-way protocol (like HTTP, but without the ability to exploit it for long-polling). It would therefore be impossible to sync up multiple instances of NHPM using a shared memcached server without having each instance interval-poll the memcached servers.
(That is, there'd be no way to instantly notify other NHPM instances of a newly received message)

In light of that, I'm not sure memcached support should be too high-priority.

from nchan.

Agree with slact's analysis re having to poll memcached. You can already run a distributed NHPM if you use logic similar to the client logic that memcache uses. Publish to a range of load balanced URL's and calculate which URL the publish or subscribe request should go to by using a hash of some value (a key) that both the publisher and subscriber know about.

e.g. If you're running a chat application with different rooms, both the publisher and subscriber know which room they're in. So you use the room name to generate an CRC32 or decimal md5 hash. Then you append the first digit of that hash to the url. e.g. /chatpub/4/ or /chatsub/4/

That request to /chatpub/4/ is handled by a load balancer or front-end nginx that routes it to a back-end NHPM server at IP address 10.1.0.4.

You can use a conditional like the following in your nginx.conf for load balancing to different back-end IP addrs:

if ($request_uri ~* '^/chatSub/(\d+)/$') {
set $nhpmBackEndDigit $1;
}
Then use it in a:
proxy_pass http://10.1.0.$nhpmBackEndDigit:80/someUrl/:

I currently use this in production for our proprietary long polling server to load balance.

from nchan.

That's rather hackishly elegant.

from nchan.

Yes, memcached storage should be a good thing but it's not sufficient to build the ideal clustered chat system, because of the lack of native notification sharing mechanism outlined by slact.

Thus, it may be interesting to consider a more generic option where the persistent storage operation is delegated to a local/network proxy script. In the chat system case, this script would do something like :

• store the received data in memcached and in database (for memcached repopulation after server reboot/restart)
• flag the message as already stored in memcached/database in order to avoid redundant storage/dispatch operations by "slave" NHPM instances (it may be done by inserting custom patterns at the end of the message, not displayed by the web clients)
• dispatch the received data to other NHPM instances by subscribing as a client to the same chat channel on theses instances and pushing the data (faking the same chat origin nickname)

from nchan.

Not gonna happen, memcached doesn't do pub/sub. Besides, there's Redis support now.

from nchan.

I'll just like to add that Redis is quite bug prone mainly because it tries to do too much. Ideally, it's better to write a mini driver for flushing to disk and add cluster functionality directly to nchan than relying on Redis. I don't really see why one has to rely on another software to scale Nchan. Message store wise, I believe memcached is also just fine since it's better suited for storing stuff in memory than nchan which lives inside Nginx. In practice, memcached would also outperform Redis in this regard in combination with a client like mcrouter.

from nchan.

So I just happened to remember KeyDB is trying to solve some of the pitfalls of Redis, I strongly believe Nchan will benefit better from focusing on KeyDB support rather than Redis since KeyDB supports the same APIs. This can at least give a close performance alternative to a manual mcrouter/memcached implementation.

from nchan.