写在前面：前不久在工作中被问到关于MC一致哈希的问题，由于时隔太久差点儿忘记，特前来恶补一下MC，下面是前几年在工作中学习MC时的一些资料，来历不明，特整理一下，希望对大家的学习也能有帮助。
的圆（continuum）上。然后用同样的方法求出存储数据的仍然找不到server，就会保存到第一台memcached server上。
从上图的状态中加入一台memcached server。余数分布式算法由于保存键的server会发生巨大变化，而影响缓存的命中率，但Consistent Hashing中，仅仅有在continuum 上添加server的地点逆时针方向的第一台server上的键会受到影响
Consistent hashing 的基本思想就是将对象和 cache 都映射到同一个 hash 数值空间中，并且使用同样的 hash 算法。
如今 cache 和对象都已经通过同一个 hash 算法映射到 hash 数值空间中了，接下来要考虑的就是如何将对象映射到 cache 上面了。
在这个环形空间中，假设沿着顺时针方向从对象的 key 值出发，直到遇见一个 cache ，那么就将该对象存储在这个 cache 上，由于对象和 cache 的 hash 值是固定的，因此这个 cache 必定是唯一和确定的。这样不就找到了对象和 cache 的映射方法了吗？
Consistent Hashing：加入server
因此，Consistent Hashing 最大限度地抑制了键的又一次分布。并且，有的Consistent Hashing 的实现方法还採用了虚拟节点的思想。使用一般的hash函数的话，server的映射地点的分布非常不均匀。因此，使用虚拟节点的思想，为每一个物理节点（server）在continuum上分配100～200 个点。这样就能抑制分布不均匀，最大限度地减小server增减时的缓存又一次分布。
通过上文中介绍的使用Consistent Hashing 算法的memcached client函数库进行測试的结果是，由server台数（n）和添加的server台数（m）计算添加server后的命中率计算公式例如以下：
(1 n/(n+m)) * 100
存储命令
<command name> <key> <flags> <exptime> <bytes>\r\n
- <command name> 是set, add,或者repalce
- <key> 是接下来的client所要求储存的数据的键值
- <flags> 是在取回内容时，与数据和发送块一同保存server上的随意16位无符号整形（用十进制来书写）。client能够用它作为“位域”来存储一些特定的信息；它对server是不透明的。
- <exptime> 是终止时间。假设为0，该项永只是期(尽管它可能被删除，以便为其它缓存项目腾出位置)。假设非0（Unix 时间戳或当前时刻的秒偏移），到达终止时间后，client无法再获得这项内容。
- <bytes> 是随后的数据区块的字节长度，不包含用于分野的“\r\n”。它能够是0（这时后面尾随一个空的数据区块）。
- <data block> 是大段的8位数据，其长度由前面的命令行中的<bytes>指定。
• set 意思是“储存此数据”
• add 意思是“储存此数据，仅仅在server*未*保留此键值的数据时”
• replace 意思是“储存此数据，仅仅在server*曾*保留此键值的数据时”
发送命令行和数据区块以后，client等待回复，可能的回复例如以下：
- "STORED\r\n"表明成功.
- "NOT_STORED\r\n"表明数据没有被存储，但不是由于错误发生。这通常意味着add或replace 命令的条件不成立，或者，项目已经位列删除队列（參考后文的“delete”命令）。
取回命令
get <key>*\r\n
- <key>* 表示一个或多个键值，由空格隔开的字串这行命令以后，client的等待0个或多个项目，每项都会收到一行文本，然后跟着数据区块。全部项目传送完成后，server发送下面字串："END\r\n"来指示回应完成,server用下面形式发送每项内容：
VALUE <key> <flags> <bytes>\r\n
<data block>\r\n
- <key> 是所发送的键名
- <flags> 是存储命令所设置的记号
- <bytes> 是随后数据块的长度，*不包含* 它的界定符“\r\n”
- <data block> 是发送的数据
假设在取回请求中发送了一些键名，而server没有送回项目列表，这意味着server没这些键名（可能由于它们从未被存储，或者为给其它内容腾出空间而被删除，或者到期，或者被已client删除）。
删除
delete <key> <time>\r\n
- <key> 是client希望server删除的内容的键名
- <time> 是一个单位为秒的时间（或代表直到某一刻的Unix时间），在该时间内server会拒绝对于此键名的“add”和“replace”命令。此时内容被放入delete队列，无法再通过“get”得到该内容，也无法是用“add”和“replace”命令（可是“set”命令可用）。直到指定时间，这些内容被终于从server的内存中彻底清除。<time>參数是可选的，缺省为0（表示内容会立马清除，并且随后的存储命令均可用）。
此命令有一行回应：- "DELETED\r\n"表示执行成功
- "NOT_FOUND\r\n"表示没有找到这项内容
添加/降低
命令“incr”和“decr”被用来改动数据，当一些内容须要替换、添加或降低时。这些数据必须是十进制的32位无符号整新。假设不是，则当作0 来处理。改动的内容必须存在，当使用“incr”/“decr”命令改动不存在的内容时，不会被当作0处理，而是操作失败。
client发送命令行：
incr <key> <value>\r\n或decr <key> <value>\r\n
- <key> 是client希望改动的内容的建名
- <value> 是client要添加/降低的总数。
回复为下面集中情形：
- "NOT_FOUND\r\n"指示该项内容的值，不存在。
- <value>\r\n ，<value>是添加/降低。
注意"decr"命令发生下溢：假设client尝试降低的结果小于0 时，结果会是0。"incr" 命令不会发生溢出。
状态
命令"stats" 被用于查询server的执行状态和其它内部数据。有两种格式。不带參数的：
stats\r\n
这会在随后输出各项状态、设定值和文档。还有一种格式带有一些參数：
stats <args>\r\n
通过<args>，server传回各种内部数据。由于随时可能发生变动，本文不提供參数的种类及其传回数据。
各种状态
受到无參数的"stats"命令后，server发送多行内容，例如以下：
STAT <name> <value>\r\n
server用下面一行来终止这个清单：END\r\n，在每行状态中，<name> 是状态的名字，<value>使状态的数据。下面清单，是全部的状态名称，数据类型，和数据代表的含义。
在“类型”一列中，"32u"表示32 位无符号整型，"64u"表示64 位无符号整型，"32u:32u"表示用冒号隔开的两个32 位无符号整型。
名称 | 类型 | 含义 |
pid | 32u | server进程ID |
uptime | 32u | server执行时间，单位秒 |
time | 32u | server当前的UNIX时间 |
version | string | server的版本号号 |
rusage_user | 32u | 该进程累计的用户时间(秒:微妙) |
rusage_system | 32u | 该进程累计的系统时间(秒:微妙) |
curr_items | 32u | server当前存储的内容数量 |
total_items | 32u | server启动以来存储过的内容总数 |
bytes | 64u | server当前存储内容所占用的字节数 |
curr_connections | 32u | 连接数 |
total_connections | 32u | server执行以来接受的连接总数 |
connection_structures | 32u | server分配的连接结构的数量 |
cmd_get | 32u | 取回请求总数 |
cmd_set | 32u | 存储请求总数 |
get_hits | 32u | 请求成功的总次数 |
get_misses | 32u | 请求失败的总次数 |
bytes_read | 64u | server从网络读取到的总字节数 |
bytes_written | 64u | server向网络发送的总字节数 |
limit_maxbytes | 32u | server在存储时被同意使用的字节总数 |
假设不想每次通过输入stats来查看memcache状态，能够通过echo "stats" |nc ip port 来查看，比如：echo "stats" | nc 127.0.0.1 9023。