Redis原理解析

Redis：

    Nosql缓存技术：支持多种数据结构类型，如set（集合），list（链表），string（字符串），zset（有序集合），hash（哈希），但是key都是String类型的。Nosql技术那么就必须要遵循CAP原则，但是我们都知道三者不能够都同时满足，所以Redis大力支持了AP（avaliable，persistence）。

应用场景：

    set（无序集合）：hash表实现，插入，查找复杂度都为O1，不可以重复

    list（双向链表）：可以用来实现，栈，队列，堆等

    String：可用于存储json类型的对象，图片等，计数器，一些累计操作，最大能存储512MB。

    zset（有序集合）：set的升级，但是zset内部自己维护一个score，用来排序。

    hash：就一个key后面对应一堆key-value ，适用于可分组的对象。

redis采用的是单线程的技术，但是他采用了多路IO复用的机制，所以速度很快.

多路IO复用:详情见我的博客

数据的存储：

    Redis是通过常见的键值对方式来存储数据的，字符串、哈希、集合、有序集合、列表这五种常见的数据结构类型被Redis所支持，且同时，这五种数据类型是Redis已经经过包装处理对外部使用人员提供的，在Redis的数据类型的实现机制中，它是通过两种不同的内部实现方式来事先对数据类型进行封装的，最为典型的例子就是RedisObject，RedisObject存储了数据类型和数据指针，同时还有存储数据键值的SDS数据结构，可见Redis并不是简单的将数据放入内存中。

                                     

内存分配算法：

    默认采用jemalloc算法：根据字符串的大小分配了合适的的内存，因为redis采用自己的jemalloc算法，能够提高效率，但是并不会实时的清理内存碎片，因此如果你多次的修改字符串的大小，那么就会造成碎片的回收不妥。

    jemalloc有三个分配机制，分别为small，large，hudge

Redis持久化：

    方式有AOF,RDB（默认方式），在操作数据多的情况下，rdb性能比aof好，因为AOF保存了大量的操作指令。

    AOF（Append-only file）:将某一时刻的操作指令写到磁盘上去，格式为redis通讯协议(RESP )格式的命令。

    RDB（Redis DataBase）:将某一时刻的数据写到磁盘上去。

Redis通信协议（RESP）：

     对每一个信息都会有规定的抬头如 ：回复的时候第一个字节为 “+”，错误第一个字节为“-”，整数第一个字节为“:”，字符串第一个字节为“$”，数组第一个字节为“*”  

 

Redis集群：分布式集群保证高可用性。可实现分布式锁，分布式队列等应用。

    架构：

        单机模式：一个redis单机

        主从模式：master与slaver模式，slaver会同步master的数据。

        哨兵模式：在主从模式的情况下，监听master的情况，会自动从slaver中选举出一个master

        代理模式：代理模式，利用其他的Twemproxy的代理服务器实现，让代理服务器来切换主机。

        集群模式（redis-cluster）：常用的，数据按照slot方式存储在多个节点上，主机宕机，slaver可以自动切换，实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，利用领头选举算法从slaver中选出master。

缓存穿透：

    大量的请求key不存在的数据，然后数据库压力太大，造成缓存穿透。

    解决方案：

        1：利用分布式锁机制，如果是分布式的环境下，需要取得锁的同时，采取数据库获取

        2：利用MQ队列机制或者redis队列，如果缓存为空，那么将该请求放入到队列中去处理，较少数据库的压力。

        3：设置永不过期的key

缓存击透：

    一直访问一个不存在key，造成数据库的压力过大。

    解决方案：

        访问key未在数据库查询到值，也将空值写进缓存，但可以设置较短过期时间。

缓存雪崩：

    所谓的缓存雪崩，即在某一时间段内，大量的key值失效了，请求都落在了数据库上，造成了缓存雪崩的现象。

    解决方案:

        1： 对每个key值设定不均匀的过期时间，或者设置永不过期

        2：当缓存雪崩的时候，利用队列和分布式锁的机制，减少数据库的请求压力。

        3：配置二级缓存。

转载于:https://my.oschina.net/u/4189935/blog/3098274