memcached 高可用研究

Memcached如何处理容错的？
不处理！:) 在memcached节点失效的情况下，集群没有必要做任何容错处理。如果发生了节点失效，应对的措施完全取决于用户。节点失效时，下面列出几种方案供您选择：
* 忽略它！ 在失效节点被恢复或替换之前，还有很多其他节点可以应对节点失效带来的影响。
* 把失效的节点从节点列表中移除。做这个操作千万要小心！在默认情况下（余数式哈希算法），客户端添加或移除节点，会导致所有的缓存数据不可用！因为哈希参照的节点列表变化了，大部分key会因为哈希值的改变而被映射到（与原来）不同的节点上。
* 启动热备节点，接管失效节点所占用的IP。这样可以防止哈希紊乱（hashing chaos）。

memcached的简单限制就是键（key）和item的限制。最大键长为250个字符。可以接受的储存数据不能超过1MB，

1. magent 


last version ： magent-0.6.tar.gz 
  Apr 15, 2010


  没人维护 的东西了。。。




安装   【依赖libevent 而且对版本还有要求 最好是1.*】
cd /usr/local/
mkdir ./magent
cd ./magent
wget -c http://memagent.googlecode.com/files/magent-0.6.tar.gz
tar xzvf ./magent-0.6.tar.gz
/sbin/ldconfig
sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile
make
cp ./magent /usr/bin/magent


编译安装magent 遇到的问题：
1、在ketama.h中加入 
vim ./ketama.h 
#ifndef SSIZE_MAX 
#define SSIZE_MAX 32767 
#endif 
2、安装依赖库
yum install -y glibc-devel 
\cp /usr/lib64/libm.so /usr/lib64/libm.a 
ln -s /usr/lib/libevent* /usr/lib64/ 
3、编辑Makefile 
vim ./Makefile 
CFLAGS = -Wall -g -O2 -I/usr/local/include $(M64) 
修改为 
CFLAGS = -lrt -Wall -g -O2 -I/usr/local/include $(M64) 
4、重新编译
/sbin/ldconfig 
sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile 
make 
\cp magent /usr/bin/magent 



ok 安装 完成  进行测试


  magent -u root -n 51200 -l 127.0.0.1 -p 12000 -s 127.0.0.1 :11218 -b 127.0.0.1 :11219 




  最简结构 一主一备

  -bash-4.2$ telnet 0 12000
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
set userId 0 0 5
11111
STORED
get userId
VALUE userId 0 5
11111
END


看看 还是蛮好的
但是 TMD set第二次的时候 就 CPU 100%了，无响应了


查了一下，有问题 而且没人解决 链接如下

http://bbs.csdn.net/topics/390570402 这个人也遇到同样的问题 ，而且，他的CSDN头像和我的 qq空间头像一样，哈哈，太圆粪 了，

magent 内存泄漏
https://code.google.com/archive/p/memagent/issues/4

还有一个方案是使用Repcached 但是Repcached 在安装的时候 有些问题 ，加之 也是一个第三方写的，

LASET VERSION 2011-12-13  也是个古老的东西了，算了不浪费时间 了，还是去玩好redis吧。

   Repcached 假设主从节点都挂掉，则数据就丢失了！因此，这是 Repcached 的一个短板，不过后期我们可以通过结合其它的工具来弥补这个缺点。

相关链接 http://www.cnblogs.com/zhoujinyi/archive/2013/04/23/3036862.html

Least Recently User（LRU）：

　　我是 LRU 缓存算法，我把最近最少使用的缓存对象给踢走。

　　我总是需要去了解在什么时候，用了哪个缓存对象。如果有人想要了解我为什么总能把最近最少使用的对象踢掉，是非常困难的。

　　浏览器就是使用了我（LRU）作为缓存算法。新的对象会被放在缓存的顶部，当缓存达到了容量极限，我会把底部的对象踢走，而技巧就是：我会把最新被访问的缓存对象，放到缓存池的顶部。

　　所以，经常被读取的缓存对象就会一直呆在缓存池中。有两种方法可以实现我，array 或者是 linked list。

　　我的速度很快，我也可以被数据访问模式适配。我有一个大家庭，他们都可以完善我，甚至做的比我更好（我确实有时会嫉妒，但是没关系）。我家庭的一些成员包括 LRU2 和 2Q，他们就是为了完善 LRU 而存在的。

顺便比较了一下使用近的几个缓存 找了下资料

Redis

代码在  redis.c的activeExpireCycle()里，看过文档的人都知道，它会在主线程里，每100毫秒执行一次，每次随机抽20条Key检查，如果有1/4的键过期了，证明此时过期的键可能比较多，就不等100毫秒，立刻开始下一轮的检查。不过为免把CPU时间都占了，又限定每轮的总执行时间不超过1毫秒。

Memcached

Memcached里有个文不对题的  LRU爬虫线程，利用了之前那条LRU的队列，可以设置多久跑一次(默认也是100毫秒)，沿着列尾一直检查过去，每次检查LRU队列中的N条数据。虽然每条Key设置的过期时间可能不一样，但怎么说命中率也比Redis的随机选择N条数据好一点，但它没有Redis那种过期的多了立马展开下一轮检查的功能，所以每秒最多只能检查10N条数据，需要自己自己权衡N的设置。

Guava Cache

在Guava Cache里，同一个Cache里所有元素的过期时间是一样的，所以它比Memached更方便，顺着之前那条LRU的Queue检查超时，不限定个数，直到不超时为止。而且它这个检查的调用时机并不是100毫秒什么的，而是每次各种写入数据时的  preWriteCleanup()方法中都会调用。

吐槽一句，Guava的Localcache类里面已经4872行了，一点都不轻量了。

Ehcache

Ehcache更乱，首先它的内存存储中只有惰性检查，没有主动检查过期的，只会在内存超限时不断用近似LRU算法(见上)把内存中的元素刷到磁盘中，在文件存储中才有超时检查的线程，  FAQ里专门解释了原因。

然后磁盘存储那有一条8小时左右跑一次的线程，每次遍历所有元素.....见  DiskStorageFactory里的DiskExpiryTask。 一圈看下来，Ehcache的实现最弱。

如果 是做会话缓存，有一定程度 的永久保存的 用意，并不是 纯缓存的 memcached 还是不适合，至少官方没有提供一套高可用 的方案，完成暴露给客户端，大家实现的 不靠谱，信不太过，会话缓存 ，还是redis吧，好好研究 redis吧，，， 明天研究一下server-side的 docker方式部署的sentinal redis集群 。