Memcached快速入门

1.基本概念
    基于高性能的key-value的内存数据库。单进程多线程，协议简单，使用文本行的协议，支持数据类型简单，不支持持久化，轻量级锁CAS机制，集群互不通信，缓存策略(LRU,FIFO,LFU)只支持LRU
2.与redis对比
    redis:      线程模型-单进程单线程,QPS/TPS-10w+/10w-,数据支持类型-丰富,持久化-支持,  支持数据备份-支持, 能否集群-能,数据一致性-支持事务,     list排序支持-支持,  缓存策略-LRU,FIFO,LFU,jcache支持-支持,单条数据约束-不同数据结构有不同约束
    memcached:  线程模型-单进程多线程,QPS/TPS-10w+/10w-,数据支持类型-简单,持久化-不支持,支持数据备份-不支持,能否集群-能,数据一致性-轻量级CAS机制,list排序支持-不支持,缓存策略-LRU,         jcache支持-支持,单条数据约束-默认值：key最大长度250字符，value容量<=1M
3.安装及使用
    参考：http://www.runoob.com/memcached/memcached-install.html

    wget http://memcached.org/latest
    tar -zxvf memcached-1.x.x.tar.gz
    cd memcached-1.x.x
    ./configure && make && make test && sudo make install

    启动：./memcached -p 11211 -d -c 1024 -u root (-p 表示端口，-d 表示后台运行， -u 指定用户)
    停止：ps aux|grep memcached 查到进程id,然后 kill -9 pid

    客户端：没有专门的客户端，使用telnet ip port

    集群：在同一台机器上可以通过指定不同的端口来运行，如
         ./memcached -p 11211 -d -c 1024 -u root
         ./memcached -p 11212 -d -c 1024 -u root
         ./memcached -p 11213 -d -c 1024 -u root

4.memcached客户端使用
    1.memcached-java-client
        引入pom:
            <!-- memcached-java-client -->
            <!-- https://mvnrepository.com/artifact/com.whalin/Memcached-Java-Client -->
            <dependency>
              <groupId>com.whalin</groupId>
              <artifactId>Memcached-Java-Client</artifactId>
              <version>3.0.2</version>
            </dependency>

        详见：MemcachedJavaClientTest

    2.spymemcached
        引入pom:
            <!--spymemcached-->
            <!-- https://mvnrepository.com/artifact/net.spy/spymemcached -->
            <dependency>
              <groupId>net.spy</groupId>
              <artifactId>spymemcached</artifactId>
              <version>2.12.3</version>
            </dependency>

        详见：MemcachedJavaClientTest

    3.xmemcached
        引入pom:
            <!-- xmemcached -->
            <!-- https://mvnrepository.com/artifact/com.googlecode.xmemcached/xmemcached -->
            <dependency>
              <groupId>com.googlecode.xmemcached</groupId>
              <artifactId>xmemcached</artifactId>
              <version>2.4.5</version>
            </dependency>
        详见：MemcachedJavaClientTest

    4.springcache与xmemcached 整合
        引入pom:
            <!-- xmemcached -->
            <!-- https://mvnrepository.com/artifact/com.googlecode.xmemcached/xmemcached -->
            <dependency>
              <groupId>com.googlecode.xmemcached</groupId>
              <artifactId>xmemcached</artifactId>
              <version>2.4.5</version>
            </dependency>
            <!-- spring cache 与 xmemcached 整合 采用simple-spring-memcached实现 -->
            <dependency>
              <groupId>com.google.code.simple-spring-memcached</groupId>
              <artifactId>simple-spring-memcached</artifactId>
              <version>2.0.0</version>
            </dependency>
        配置：applicationContext-cache.xml

        详见：SpringCacheMemcachedTest
5.原理（重点理解）

    5.1.hash算法
        memcached单节点是有存储局限的，所以可以使用集群的方式。这里就有分布式存取的问题。不管是写入还是读取，肯定要通过某种算法，这种算法负责定位到某个固定的节点

        1.余数分散：m = hash(key) mod n  (其中key为传入的数据,n为机器的个数 ，将计算得到的m值 就是对应第几台机器，将key存入改机器中)
            优点：算法简单，分散性好
            缺点：当新增或者删除机器时，缓存重组的代价很大。当新增或删除机器时，余数会有很大的变化，这样就无法获取与保存时同样的机器，从而导致缓存的命中率很低
            代码详见：HashTest

        2.一致性hash算法
            一致性hash算法就是为了解决余数分散 增加或删除机器时命中率低的问题
            步骤：1.构建hash环 2.把数据映射到hash环 3.把机器节点映射到hash环  4.把数据映射到机器节点
            优点：解决了余数分散算法增加或删除节点命中率大幅下降的问题
            缺点：算法实现比较复杂，需要构建hash环
            代码详见：ConsistentHashTest ConsistentHashNodeServiceImpl

        3.一致性hash算法 + 虚拟节点
            一致性hash算法有个缺点：数据分布不均，有倾斜性，即有些节点存的数据很多，有些则很少。
            为了解决这个问题，于是有了增加虚拟节点的方案：
            可以在原来缓存的机器的基础上，增加相应的虚拟节点，这样数据就会均匀的打散到其他节点中。这个时候客户端进行数据存取的时候找的就是虚拟节点，而不是真实的物理节点服务器，这样增加节点会删除节点虽然命中率会降低，却很好的解决了数据倾斜问题
            代码详见：ConsistentHashTest  ConsistentHashNodeServiceImpl2

    5.2内存管理策略
        Memcached采用Slab Allocator(Slab分配器)进行内存管理
            内存被拆分成多个Slab class
            每个Slab class 有多个Slab,每个Slab=1M
            每个Slab下有多个大小相等的Chunk
            不同Slab中的Chunk的大小不一样
            数据存储在Chunk中

        使用./memcached -p 11211 -d -u root -vv 可以观察内存分配情况
        客户端Telnet使用stats slabs查看内存分布情况

        增长因子：
            启动时指定增长(growth factor)因子（-f 2），就可以在某种程度上控制slab之间的差异，默认值为1.25
            如果增加-f 2参数即 ./memcached -p 11211 -f 2 -d -u root -vv   那么表示每一个slab的chunk size 都比上一个slab大了一倍

            注意：真实项目中，要均衡数据的大小，如果数据之间大小差别不大建议增长因子设置比较小，而数据之间大小悬殊，数据的增长因子可以考虑增大

    5.3缓存过期策略
        MC不会主动删除过期数据，而是采用lazy策略
        Memcached不会释放已分配的内存，其存储空间可以重复使用
        Memcached内部不会监视数据是否过期，而是在get时查看数据的时间戳，查看数据是否过期。被称为lazy expiration(惰性过期)
        Memcached内存空间不足，即无法从slab class中获取到新的空间时，就从最近未被使用的数据中搜索，将其空间分配给新的数据。（如果要禁用LRU，使用-M参数，超出会报错）


6.问题

    1.什么是一致性hash,他和普通hash有什么不同（hash环，虚拟节点干什么的）？
       一致性hash是为了解决普通hash算法（余数分散算法）因增加或删除节点导致命中率大幅下降的问题 而产生的
       与普通hash不同点：
          1.构建hash环 2.将数据映射到hash环上 3.将节点映射到hash环上 4.将数据映射到节点上
       虚拟节点：是为了解决一致性hash中节点个数少导致数据分布不均问题而产生的，通过增加虚拟节点，可以使得数据均匀的打散到其他节点。
    2.一致性hash在上面情况下使用，单节点情况下用一致性hash是否合适？
       单节点不适用，因为使用一致性hash算法性能比较低，单节点使用普通的hash算法就行了
    3.slab内存模型是什么样的，对于增长因子来说，他对性能有什么影响？
       slab内存模型：
       内存被拆分成多个slab class
       每个slab class 有多个slab,每个slab=1M
       每个slab下有多个大小相等的chunk
       不同slab中chunk大小不一样
       数据存储在chunk中

       增长因子：
       用于控制slab之间的差异。默认是1.25，可以根据实际情况，设置增长因子（在启动memcached时加参数 -f 设置）
          如果数据之间的大小差别不大，就设置小点，如果大小差别很大，就可以设置大点

    4.增长因子对性能影响：
            如果数据间隔小，而设置很大的话，就浪费空间。
            如果数据间隔大，而设置很小的话，那就存不了数据，也是浪费空间
            如果增长因子设置过大，代表的每个slab里面chunk大小跨度很大。 但数据却很小，经常导致只有一部分chunk被使用 而且经常导致内存的清理，导致性能降低，如果数据跨度不大，可以考虑把增长因子设置得小一点的

    5.一致性hash环的大小为什么是2^32
        因为，java中int的最大值是2^31-1最小值是-2^31,2^32刚好是无符号整形的最大值；
    为什么java中int的最大值是2^31-1最小值是-2^31
        int的最大值最小值范围设定是因为一个int占4个字节，一个字节占8位，二进制中刚好是32位
    hash环：
        把二的三十二次方想象成一个圆，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到2^32-1,也就是说0点左侧的第一个点代表2^32-1，我们把这个由2的32次方个点组成的圆环称为hash环

    6.如果服务器计算出的hash值相同，那么数据不是被放在相同的服务器上了吗？
        这个问题其实就是hash 碰撞，而在一致性hash里面hash碰撞的几率不大，理论上有hash碰撞的可能性，任何hash的有可能。
        就像md5值，如果数据量足够大，足够长，算出的md5理论上可能重复，但并不影响它使用。 这是种出现概率极低的情况
    7.每个slab大小是1M,为什么slab class有39个？
        slab class有39个 只是显示它会这么分配，这个是由增长因子确定，但并没真的这么分配。具体的分配你应该在服务器运行的时候基于指定的内存分配，可以stats slabs命令查看

    8.一致性hash算法应用场景：
        memcached的客户端，redis中的hash slot（hash槽）,nginx的负载均衡
        hash一致性算法是为了在分布式环境下 动态增加或删除节点 而尽量减少对数据存取的影响即命中率低的问题 而产生，具体的算法在不同的应用场景中不太一样

    9.缓存过期策略
        FIFO(First In First Out):先见先出，淘汰最先近来的页面，新进来的页面最迟被淘汰，完全符合队列
        LRU(least recently used):最近最少使用，淘汰最近不使用的页面
        LFU(least frequently used):使用次数最少， 淘汰使用次数最少的页面
        memcached 采用的是LRU