memcache的原理及应用

    memcache的操作
我这里都是围绕zhangsan这个键操作的
//增
add zhangsan 0 0 4  添加一个存在的键,则添加失败
hell
//删
delete zhangsan [int]这是一个时间参数如果有值了意思是多少秒之后不能用这个键了
//改
replace zhangsan 0 0 4 对于一个不存在键不能修改
aaaa
//查
get zhangsan
2
再说一个比较霸道的命令
set 相当于add和replace
如果设置键了就变成修改了
set zhangsan 0 0 4
bbbb
如果没有设置就变成添加了
set zhangsan 0 0 4
haaa
            统计命令 stats
pid：memcache服务器进程ID
uptime：服务器已运行秒数
time：服务器当前Unix时间戳
version：memcache版本
pointer_size：操作系统指针大小
rusage_user：进程累计用户时间
rusage_system：进程累计系统时间
curr_connections：当前连接数量
total_connections：Memcached运行以来连接总数
connection_structures：Memcached分配的连接结构数量
cmd_get：get命令请求次数
cmd_set：set命令请求次数
cmd_flush：flush命令请求次数
get_hits：get命令命中次数
get_misses：get命令未命中次数
delete_misses：delete命令未命中次数
delete_hits：delete命令命中次数
incr_misses：incr命令未命中次数
incr_hits：incr命令命中次数
decr_misses：decr命令未命中次数
decr_hits：decr命令命中次数
cas_misses：cas命令未命中次数
cas_hits：cas命令命中次数
cas_badval：使用擦拭次数
auth_cmds：认证命令处理的次数
auth_errors：认证失败数目
bytes_read：读取总字节数
bytes_written：发送总字节数
limit_maxbytes：分配的内存总大小（字节）
accepting_conns：服务器是否达到过最大连接（0/1）
listen_disabled_num：失效的监听数
threads：当前线程数
conn_yields：连接操作主动放弃数目
bytes：当前存储占用的字节数
curr_items：当前存储的数据总数
total_items：启动以来存储的数据总数
evictions：LRU释放的对象数目
reclaimed：已过期的数据条目来存储新数据的数目    
                
            两个经常用到秒杀的命令        
incr (32位无符号的整数型)增加
decr 减少
flush_all 清空所有的对象值
            
                 memcached内存分配机制    
memcached用slab allocator 机制来管理内存.
slab allocator 原理: 预告把内存划分成数个 slab class 仓库.(每个 slab class 大小 1M)各仓库,切分成不同尺寸的小块(chunk)需要存内容时,判断内容的大小,为其选取合理的仓库.
系统如何选择合适的 chunk?
memcached 根据收到的数据的大小, 选择最适合数据大小的 chunk
如果缓存的内容没有把chunk占满 那将浪费掉,是无法避免的
如果缓存的内容把chunk占满 那把老的数据给删除既是永久的也不行 后面会说的删除机制
memcached 此处用的 lru 删除机制.
固定大小 chunk 带来的内存浪费.
对于 chunk 空间的浪费问题,无法彻底解决,只能缓解该问题.
开发者可以对网站中缓存中的 item 的长度进行统计,并制定合理的 slab class 中的 chunk 的大小.
可惜的是,我们目前还不能自定义 chunk 的大小,但可以通过参数来调整各 slab class 中 chunk
大小的增长速度. 即增长因子, grow factor!

                   memcached 的过期数据惰性删除
memcached 此处用的 lru 删除机制.
如果以 122byte 大小的 chunk 举例, 122 的 chunk 都满了, 又有新的值(长度为 120)要加入, 要挤掉谁?
memcached 此处用的 lru 删除机制.
(操作系统的内存管理,常用 fifo,lru 删除)
lru: least recently used 最近最少使用
fifo: first in ,first out
原理: 当某个单元被请求时,维护一个计数器,通过计数器来判断最近谁最少被使用.
就把谁 t 出.
注: 即使某个 key 是设置的永久有效期,也一样会被踢出来!
即--永久数据被踢现象

                     缓存雪崩现象
描述:缓存雪崩一般是由某个缓存节点失效,导致其他节点的缓存命中率下降, 缓存中缺失的数据去数据库查询.短时间内,造成数据库服务器崩溃.
重启 DB,短期又被压跨,但缓存数据也多一些.
DB 反复多次启动多次,缓存重建完毕,DB 才稳定运行.
或者,是由于缓存周期性的失效,比如每 6 小时失效一次,那么每 6 小时,将有一个请求”峰值”,严重者甚至会令 DB 崩溃.
解决方案:把缓存设置为随机3到9小时的生命周期,这样不同时失效,把工作分担到各个时间点上去.

                     缓存的无底洞现象 multiget-hole
描述:该问题由 facebook 的工作人员提出的, facebook 在 2010 年左右,memcached 节点就已经达3000 个.缓存数千 G 内容.
他们发现了一个问题---memcached 连接频率,效率下降了,于是加 memcached 节点,
添加了后,发现因为连接频率导致的问题,仍然存在,并没有好转,称之为”无底洞现象”.
解决方案: 这样,许多相同信息的 key,都落在同 1 个节点上,访问个人主页时,只需要连接 1 个节点.

                    永久数据被踢现象
描述:有开发人员许多人反馈为"memcached 数据丢失",明明设为永久有效,却莫名其妙的丢失了.
其实,这要从 2 个方面来找原因:
①即前面介绍的 惰性删除,与 LRU 最近最少使用记录删除.
如果 slab 里的很多 chunk,已经过期,但过期后没有被 get 过, 系统不知他们已经过期.
②永久数据很久没 get 了,不活跃,如果新增 item,则永久数据被踢了.
当然,如果那些非永久数据被 get,也会被标识为 expire,从而不会再踢掉永久数据
解决方案: 永久数据和非永久数据分开放