标签：
首先说明下memcached存在如下问题
本身没有内置分布式功能，无法实现使用多台Memcache服务器来存储不同的数据，最大程度的使用相同的资源；无法同步数据，容易造成单点故障。（memagent代理实现集群）
在 Memcached中可以保存的item数据量是没有限制的，只要内存足够 。
Memcached单进程最大使用内存为2G，要使用更多内存，可以分多个端口开启多个Memcached进程
最大30天的数据过期时间,设置为永久的也会在这个时间过期，常量REALTIME_MAXDELTA
60*60*24*30控制
最大键长为250字节，大于该长度无法存储，常量KEY_MAX_LENGTH 250控制
单个item最大数据是1MB，超过1MB数据不予存储，常量POWER_BLOCK 1048576进行控制，
它是默认的slab大小
最大同时连接数是200，通过 conn_init()中的freetotal进行控制，最大软连接数是1024，通过
settings.maxconns=1024 进行控制
跟空间占用相关的参数：settings.factor=1.25, settings.chunk_size=48, 影响slab的数据占用和步进方式
memcached是一种无阻塞的socket通信方式服务，基于libevent库，由于无阻塞通信，对内存读写速度非常之快。
memcached分服务器端和客户端，可以配置多个服务器端和客户端，应用于分布式的服务非常广泛。
memcached作为小规模的数据分布式平台是十分有效果的。
memcached是键值一一对应，key默认最大不能超过128个字 节，value默认大小是1M，也就是一个slabs，如果要存2M的值（连续的），不能用两个slabs，因为两个slabs不是连续的，无法在内存中 存储，故需要修改slabs的大小，多个key和value进行存储时，即使这个slabs没有利用完，那么也不会存放别的数据。
集群配置
由于Memcached服务器与服务器之间没有任何通讯，并且不进行任何数据复制备份，所以当任何服务器节点出现故障时，会出现单点故障，如果需要实现HA，则需要通过另外的方式来解决。
通过Magent缓存代理，防止单点现象，缓存代理也可以做备份，通过客户端连接到缓存代理服务器，缓存代理服务器连接缓存连接服务器，缓存代理服 务器可以连接多台Memcached机器可以将每台Memcached机器进行数据同步。如果其中一台缓存服务器down机，系统依然可以继续工作，如果 其中一台Memcached机器down掉，数据不会丢失并且可以保证数据的完整性。具体可以参考：http://code.google.com/p /memagent/
memcache集群的实现
memcached尽管是“分布式”缓存服务器，但服务器端并没有分布式功能。各个memcached不会互相通信以共享信息。那么，怎样进行分布式呢？这完全取决于客户端的实现。
memcached的分布式
Memcached作为集中式Cache，就存在着集中式的致命问题：单点问题，Memcached支持多Instance分布在多台机器上，仅仅 只是解决了数据全部丢失的问题，但是当其中一台机器出错以后，还是会导致部分数据的丢失，一个篮子掉在地上还是会把部分的鸡蛋打破。
因此就需要实现一个备份机制，能够保证Memcached在部分失效以后，数据还能够依然使用，当然大家很多时候都用Cache不命中就去数据源获 取的策略，但是在SIP的场景中，如果部分信息找不到就去数据库查找，那么要把SIP弄垮真的是很容易，因此SIP对于Memcached中的数据认为是 可信的，因此做Cluster也是必要的。
1.应用传入需要操作的key，通过CacheManager获取配置在Cluster中的客户端。
2.当获得Cache Client以后，执行Cache操作。
3. A.如果是读取操作，当不能命中时去集群其他Cache客户端获取数据，如果获取到数据，尝试写入到本次获得的Cache客户端，并返回结果。（达到数据恢复的作用）
B.如果是更新操作，在本次获取得Cache客户端执行更新操作以后，立即返回，将更新集群其他机器命令提交给客户端的异步更新线程对列去异步执行。（由于如果是根据key来获取Cache，那么异步执行不会影响到此主键的查询操作）
存在的问题：如果是设置了Timeout的数据，那么在丢失以后被复制的过程中就会变成永久有效的内容。
越来越感觉到DB力不从心，在面对千万级用户量的应用时，DB面对平凡的curd，特别是查询的时候，早已不堪重负！如何解决高并发下数据的查询效率，在应用中显的越来越重要，好了废话不多说，首先介绍下magent与memcached
一、 magent
magent是一款开源的Memcached代理服务器软件，其项目网址为：http://code.google.com/p/memagent/
1. 安装：
1.mkdir magent
2.cd magent/
3.wget http://memagent.googlecode.com/files/magent-0.5.tar.gz
4.tar zxvf magent-0.5.tar.gz
5./sbin/ldconfig
6.sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile
7.make
8.cp magent /usr/bin/magent
9.cd ../
2. magent 命令参数说明：
1.-h this message
2.-u uid
3.-g gid
4.-p port, default is 11211. (0 to disable tcp support)
5.-s ip:port, set memcached server ip and port
6.-b ip:port, set backup memcached server ip and port
7.-l ip, local bind ip address, default is 0.0.0.0
8.-n number, set max connections, default is 4096
9.-D do not go to background
10.-k use ketama key allocation algorithm
11.-f file, unix socket path to listen on. default is off
12.-i number, max keep alive connections for one memcached server, default is
20
13.-v verbose
二、memcached http://memcached.org/
1. 安装libevent
2. 安装memcached
configure 需要加 libevent的安装路径
启动： /usr/local/bin/memcached -d -m 512 -u root -p 11211 -c 10000 -M -f 1.1 -P /tmp/memcached.pid
三、配置memcached 与 magent，无图无真相，一图抵千言：
magent与memcached 是可以混搭的，不必死板的一个magent s-memcached s-memcached b-memcached
上图此模型已经能够很好的解决一个节点，一组服务器的缓存数据服务，但是如果在北方网通架设了一组服务器，同时在南方电信又架设了另外一组服务器，那么这两组相对独立的节点之间如何做到数据的同步与共享，基于magent与memcached的解决方案如下：
需要注意的是，两组magent的配置最好完全一致，比如：
北方的magent配置为：magent s-memcached1 s-memcached2 b-memcached3
那么南方的magent配置也为：magent s-memcached1 s-memcached2 b-memcached3
其顺序都是一致的，因为magent在分配key到memcached上时只是简单的使用散列余数算法。
当然如果你够懒，那么你可以直接连接备份magent，因为所有的数据上面都有。
有个特别要注意的地方是：
1:其中一台Memcached死掉，从magent取数据，数据会从备份的Memcached取出，保证用户不受影响.
2:Memcached重启复活，由于这两台Memcached重启后无数据，因此magent取得的将是空值，尽管备份Memcached还有数据。可采用定时维护服务器，恢复memcached。
3。如果Memcached死掉,备份机同时死掉，那么只能说明你够倒霉，此时此刻你或许能见到上帝。
四、java客户端
推荐使用：xmemcached
http://code.google.com/p/xmemcached/
五、缓存与DB的同步
比较保险的做法是：查询的时候从缓存中取，add、updae、delete的时候同时操作缓存与DB。
当然你也可以定时同步缓存与DB的数据，个人认为不同的业务应该有不同的选择！
我在实际的应用中是同时使用这两种方式，比如用户个人信息之类的内容，就用定时同步的方式。
六、搜索引擎+缓存+DB
这个主题比较大，可以分为：
1。文件结构的存储代替DB持久化存储。
2。缓存在搜索引擎中的使用--文本库与索引库的缓存实现。
3。使用搜索引擎进行统一的数据查询。
4。文件同步读写。
标签：
原文地址：http://www.cnblogs.com/nuanxin/p/5730433.html
