<commit_before># nMemcached

nMemcached is a fully featured Memcached client for node.js. nMemcached implements consistent hashing to store the data across server nodes. Consistent hashing is a scheme that provides a hash table functionality in a way that adding or removing of node slot does not significantly change the mapping of the keys to nodes. You can use nMemcached if you have single or a cluster of Memcached servers.

## nMemcached vs ..

### Single server interfaces

There are Memcached clients available for node.js that only provide you with a single server interface. This might be great if you only have one Memcached server, but what if your project becomes successful and you need *more* Memcached servers to function in a fast and responsive manner. Than you are usually f*ck'd, you would need to find a new Memcached client and change countless lines of code because the API's aren't consistent between libraries. nMemcached does not suffer from this limitation, the client is constructed with scaling in mind, it sees no difference between a single or clustered Memcached server. The only change required would be updating the constructor of nMemcached with the new servers:

	// Arrays, Strings or Objects it doesn't matter we all parse it down internally to the format we need
	var memcache = new nMemcached('192.168.0.102:11212');
	var memcache = new nMemcached([ '192.168.0.102:11212' ]);
	var memcache = new nMemcached({ '192.168.0.102:11212': 1 });

Would become:

	var memcache = new nMemcached([ '192.168.0.102:11212', '192.168.0.103:11212', '192.168.0.104:11212' ]);
	var memcache = new nMemcached({ '192.168.0.102:11212': 1, '192.168.0.103:11212': 2, '192.168.0.104:11212': 1 });
	

### Basic commands only

Most Memcached clients only support the most basic commands of the Memcached server. These are primary GET/SET/ADD INCR/DECR and REPLACE/DELETE. But there are much more commands available for Memcached our goal is provide support for them all. Including the multi GET/SET.

## Project status

"Work in progress" is probably the best to describe the current state of the project. Feel free to contribute for / watch and comment on the changes.<commit_msg>Updated readme with new layout, more to come<commit_after>#nMemcached

nMemcached is a fully featured Memcached client for node.js. nMemcached is build with scaling, high availablity and exceptional performance in mind. We use consistent hashing to store the data across different nodes. Consistent hashing is a scheme that provides a hash table functionality in a way that adding or removing a server node does not significantly change the mapping of the keys to server nodes. The algorithm that is used for consistent hashing is the same as libketama.

There are different ways to handle errors for example, when a server becomes unavailable you can configure the client to see all requests to that server as cache misses untill it goes up again. It's also possible to automatically remove the affected server from the consistent hashing algorithm or provide nMemcached with a failover server that can take the place of the unresponsive server.

When these issues occure the nMemcached client will emit different events where you can subscribe to containing detailed information about the issues.

The client is configurable on different levels. There's a global configuration that you update so all you Memcached clusters will use the same failure configuration for example, but it's also possible to overwrite these changes per nMemcached instance.

## Setting up the client

The constructor of the nMemcached client is designed to work with different formats. These formats are all internally parsed to the correct format so our consistent hashing scheme can work with it. You can either use:

1.	**String**, this only works if you have are running a single server instance of Memcached.
	It's as easy a suppling a string in the following format: `hostname:port`. For example
	`192.168.0.102:11212` This would tell the client to connect to host `192.168.0.102` on
	port number `11212`.

2.	**Array**, if you are running a single server you would only have to supply one item in the array.
	The array format is particually usefull if you are running a cluster of Memcached servers. This will
	allow you to spread the keys and load between the different servers. Giving you higher availablity for
	when one of your Memcached servers goes down.

3	**Object**, when you are running a cluster of Memcached servers it could happen to not all server can
	allocate the same amount of memory. You might have a Memcached server with 128mb, 512, 128mb. If you would
	the array structure all servers would have the same weight in the consistent hashing scheme. Spreading the
	keys 33/33/33 over the servers. But as server 2 has more memory available you might want to give it more weight
	so more keys get stored on that server. When you are using a object, the `key` should represent the server
	location and the value the weight of the server. By default all servers have a weight of 1. 
	`{ '192.168.0.102:11212': 1, '192.168.0.103:11212': 2, '192.168.0.104:11212': 1 }` would generate a 25/50/25 
	distirbution of the keys.
{'fraction_non_alphanumeric': 0.049664429530201344, 'fraction_numerical': 0.046596356663470756, 'mean_word_length': 4.427679500520291, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 14, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1610743', 'n_tokens_mistral': 1467, 'n_tokens_neox': 1283, 'n_words': 797}