原文地址:redis简析html
Redis是一个基于C语言开发的开源的高性能内存数据库,通常用做缓存和消息中间件,属于NoSQL的一种。
做为内存数据库,其优点有:
一、性能强悍,数据存储在内存中,读写速度很是快,支持并发10W QPS
二、单进程单线程,是线程安全的,采用IO多路复用机制;
三、丰富的数据类型,支持字符串(Binary-safe strings),哈希(Hashes),列表(Lists),集合(Sets),有序集合(Sorted sets)等;
四、支持数据持久化。可将内存中的数据保存在磁盘中,重启时加载;
五、主从复制,哨兵,高可用;
六、能够用做分布式锁;
七、能够做为消息中间件使用,支持发布订阅。redis
redis使用redisObject对象来表示全部的key和value:
redisObject中type表示value对象具体是哪一种数据类型,encoding是不一样数据类型在redis中的存储方式。如type=string表示value存储的是一个普通字符串,那么encoding能够适raw或int。算法
string是redis是最基本、最经常使用的数据类型,和memcached的k-v结构相似。value不只能够适字符串,也能够是数字。string类型是二进制安全的,就是说redis的string类型能够包含任何数据,好比图片或者序列化对象。string类型的value最大能存储512M。数据库
hash是一个键值(k-v)的集合。redis的hash是一个string类型的key和value的映射表,hash特别适合存储对象。经常使用的命令:hget,hset,hgetall等。api
list列表是简单的字符串列表,按照插入顺序排序。能够添加一个元素到列表的头部(左边)或尾部(右边)。经常使用的命令:lpush,rpush,lpop,rpop,lrange(获取列表片断)等。
应用场景:list是Redis中最重要的数据结构之一,如社交网站的关注列表,粉丝列表等均可以用list来实现。
数据结构:list属于链表,能够用来作消息队列。Redis提供了list的push和pop操做,还提供了操做某一段的api,能够直接查询或删除某一段的元素。
实现方式:Redis list的实现是一个双向链表,支持反向查找和遍历。缓存
set是string类型的无序集合。集合经过hash table实现,set中的元素无序不重复。经常使用的命令:sadd,spop,smembers、sunion等。
应用场景:Redis set对外提供的功能和list同样是一个列表,特别之处在于set是自动去重的,并且set提供了判断某个成员是否在一个set集合中的方法。安全
zset和set同样是string类型元素的集合,且不容许重复的元素,经过score参数来排序,经常使用的命令:zadd,zrange,zrem,zcard等。
应用场景:有序集合sorted set经过用户提供的score参数来为成员排序,而且是插入有序的,即自动排序。当须要一个有序且不重复的集合列表时,能够选择有序集合结构。和set相比,sorted set关联了一个double类型权重的参数score,使得集合中的元素可以按照score进行有序排列,Redis正是经过分数来为集合中的成员进行从小到大的排序。
实现方式:Redis sorted set内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里存放的是成员到score的映射,而跳跃表中存放的是全部的成员,排序依据是HashMap里存的score,使用跳跃表的结构能够得到比较高的查找效率,而且在实现上比较简单。服务器
类型 | 简介 | 特性 | 场景 |
---|---|---|---|
string(字符串) | 二进制安全 | 能够包含任何数据,如图片、序列化对象 | |
hash(哈希字典) | 键值对集合 | 适合存储对象,而且能够像数据库中的update同样,只修改某一项属性值 | 存储,读取,修改用户属性 |
list(列表) | 链表(双向链表) | 增删快,提供了操做某一元素的api | 最新消息排行;消息队列 |
set(集合) | hash表实现,元素无序不重复 | 添加,删除,查找的复杂度都是O(1),提供了求交集,并集,差集的操做 | 共同好友;利用惟一性,统计访问网站的全部ip |
sort set(有序集合) | 将set中的元素增长一个权重参数score,元素按score有序排列 | 数据插入集合时,已经进行了自然排序 | 排行榜;带权重的消息队列 |
分布式环境下,不可避免的存在数据库和缓存数据不一致的问题,若是项目要求数据必须是强一致性的,那么就不要使用缓存。咱们只能采起合理的策略去下降缓存和数据库间数据不一致的几率,而没法保证绝对一致。合理的策略包含合适的缓存更新策略,更新数据库后及时更新缓存、缓存失败时增长重试机制。网络
若是缓存在一段时间内失效,发生大量的缓存穿透,全部的查询都落在数据库上,形成缓存雪崩。
因为原有缓存失效,因此新缓存未到期间,全部本来应该访问缓存的请求都去查询数据库了,对数据库的CPU和内存形成巨大压力,严重的会形成数据库宕机。
解决方案:
a、加锁排队:用mutex锁(互斥锁)解决,用Redis的setnx去设置一个key,当返回成功时,进行加载数据库的操做并设置缓存,不然就重试获取缓存。
b、缓存预热:缓存预热就是系统上线前,将相关的缓存数据直接加载到缓存系统中,这样能够避免在用户请求的时候直接查询数据库而后回写缓存的问题,用户直接能够查询到缓存。
c、双层缓存:C1为原始缓存,C2为拷贝缓存,C1失效时,能够访问C2,C2的缓存失效时间设置为长期。
d、定时更新缓存:对时效性要求不高的缓存,能够采用定时任务去更新或移除缓存。
e、设置不一样的过时时间,避免同一时间点缓存集体失效。【此方式方便高效】数据结构
在高并发的系统中,大量的请求同时查询一个key时,此时这个key正好失效了,就会致使请求全都打到数据库上面去,这种现象就是缓存击穿。
缓存击穿和缓存雪崩有点像,缓存雪崩是由于大面积的缓存失效,打崩了数据库,而缓存击穿则是指一个key很是热点,在不停的扛着大量的请求,当这个key失效的瞬间,持续的请求直接打到数据库上。
解决方案:
设置热点数据永不过时,或者加上互斥锁,请求击穿缓存要查询数据库时则获取锁而后去查,其余请求获取不到锁则等待,而后尝试请求缓存。
缓存穿透是指缓存和数据库中都没有的数据,却不断有请求想要获取。好比:不断有请求获取id<=0的数据,这样缓存没有,进入数据库查询,数据库虽然也没有,可是不断的去查询返回,致使数据库压力增大,可能致使数据库宕机。
解决方案:
a、基本校验:接口层增长校验,如用户鉴权,参数校验(如id是否大于0),不知足直接返回。
b、缓存空值:若查询返回为空(不管是数据真的不存在仍是系统故障),咱们仍然缓存空值,并设置其过时时间较短(通常不超过5分钟)。这样就避免每次请求都穿透缓存直达数据库。
c、采用布隆过滤器(BloomFilter)
原理是利用高效的数据结构和算法快速判断查询key是否存在数据库中,不存在则直接返回空,存在则去查数据库并刷新缓存。
Redis是单进程单线程的模型,由于Redis彻底是基于内存的操做,CPU不是Redis的瓶颈,Redis的瓶颈是机器内存的大小或者网络带宽。既然单线程容易实现,并且CPU不会成为瓶颈,那么采用单线程的方案比多线程少不少麻烦(如各类锁)。
a、Redis彻底基于内存,绝大部分请求是纯粹的内存操做,很是迅速,数据存在内存中,相似于HashMap,而HashMap的优点就是查询和操做的时间复杂度是O(1)。
b、数据结构简单,对数据的操做也简单。
c、采用单线程,避免多线程致使的CPU切换和各类加锁释放锁的操做和死锁问题。
d、使用多路复用IO模型,非阻塞IO。四大点,搞懂Redis到底快在哪
一、存储方式上:memcached数据所有存在内存中,断电即丢失,数据不能超过内存大小。Redis有部分数据存在硬盘上,保证数据的持久性。
二、数据类型上:memcached只有k-v数据类型,Redis支持多种数据结构。
三、使用底层模型不一样:它们之间底层实现方式以及与客户端之间通讯的应用协议不同。Redis直接本身构建了VM机制,由于通常的系统调用系统函数时,会浪费必定的时间去移动和请求。
四、value的大小:Redis可达1GB,memcached只有1MB。
策略 | 描述 |
---|---|
volatile-lru | 从已设置过时时间的kv集合中,优先对最近少使用(less recently used)的数据淘汰 |
volitile-ttl | 从已设置过时时间的kv集合中,优先对剩余时间短(time to live)的数据淘汰 |
volitile-random | 从已设置过时时间的kv集合中,随机选择数据淘汰 |
allkeys-lru | 从全部kv集合中,优先对最近最少使用(less recently used)的数据淘汰 |
allkeys-random | 从全部kv集合中,随机算则数据淘汰 |
noeviction | 不淘汰策略,若超过最大内存,返回错误信息 |
volatitle-lfu | (4.0+)从已设置过时时间的kv集合中,优先对最近频率低(less frequency use)的数据淘汰 |
allkeys-lfu | (4.0+)从全部的kv集合中,优先对最近频率低(less frequency use)的数据淘汰 |
Redis为了保证效率,数据缓存在内存中,可是会周期性的把更新的数据写入磁盘或者把修改的操做写入追加的记录文件中,以保证数据的持久化。
Redis的持久化策略有两种:
一、RDB:快照形式是直接把内存中的数据保存到一个dump的文件中,定时保存。
二、AOF:把全部的对Redis的服务器进行修改的命令集合都追加在一个文件中。
Redis默认是快照RDB的持久化方式。
当Redis重启时,它会优先使用AOF文件来还原数据集,由于AOF文件保存的数据集一般比RDB文件所保存的数据集更完整。持久化详解
默认Redis是会以快照RDB的形式将数据持久化到磁盘的一个二进制文件dump.rdb中。
当Redis须要作持久化时,Redis会fork一个子进程,子进程将数据写到磁盘上一个临时的RDB文件中,当子进程完成临时文件后,将原来的RDB替换掉,这样的好处是能够copy-on-write。
优势:
RDB文件紧凑,适合用于备份。如能够根据业务状况在不一样的时间点对Redis数据进行RDB备份,这样遇到问题时能够还原到不一样时间版本的数据,很是适合容灾恢复。
缺点:
若须要尽可能避免在服务器故障时丢失数据,那么RDB不合适。
使用AOF作持久化,每个写命令都经过write函数追加写到appendonly.aof中。
appendonly yes appendfsync always #每次有数据修改发生时都会写入AOF文件 appendfsync everysec #每秒同步一次,该策略为AOF的缺省策略
AOF能够作到全程持久化,只须要在配置中开启appendonly yes。这样redis每执行一个修改数据的命令,都会把它添加到AOF文件中,当redis重启时,将会读取AOF文件进行重放,恢复到Redis关闭前的样子。
优势:
使用AOF的优势是会让Redis变得很是耐久,能够设置不一样的fsync策略,AOF的默认策略是每秒fsync一次,在这种配置下,就算发生故障停机,也最多丢失一秒钟的数据。
缺点:
缺点是对于相同的数据集来讲,AOF的文件体积一般大于RDB文件的体积,根据所使用的fsync策略,AOF的速度可能慢于RDB。
若业务能够承受几分钟内数据的丢失,那么能够只使用RDB持久化数据。AOF将Redis执行的每一条命令追加到磁盘中,处理巨大的写入会下降Redis的性能。
定时生成RDB快照很是便于进行数据库备份,而且RDB恢复数据集的速度也要比AOF恢复的速度快。
固然,Redis支持同时开启RDB和AOF,系统重启后,Redis会优先使用AOF来恢复数据,这样丢失的数据最少。
Redis单节点存在单点故障问题,为了解决单点问题,通常都须要对Redis配置从节点,而后使用哨兵来监听主节点的存活状态,若是主节点挂掉,从节点能继续提供缓存功能。
主从配置结合哨兵模式能解决单点故障问题,提升Redis可用性。从节点仅提供读操做,主节点提供写操做。对于读多写少的情况,可给主节点配置多个从节点,从而提升响应效率。
关于复制过程:
一、从节点执行slaveof[masterIP][masterPort],保存主节点信息;
二、从节点的定时任务发现主节点信息,创建和主节点的socket链接;
三、从节点发送ping信号,主节点返回pong,两边互通;
四、创建链接后,主节点将全部数据发送给从节点(数据同步);
五、主节点把当前数据同步给从节点,便完成了复制的创建过程。接下来,主节点就会持续的把命令发送给从节点,保证主从一致性。
Redis2.8以前使用sync[runID][offset]同步命令,Redis2.8以后使用psync[runID][offset]命令。Redis集群和MySQL主从同步
两种方式的不一样在于,sync命令仅支持全量复制过程,psync支持全量和复制。
其中:
runID:每一个Redis节点启动都会生成惟一的uuid,每次Redis重启后,runID都会发生变化。
offset:主节点和从节点都各自维护本身的主从复制偏移量offset,当主节点有写入命令时,offset=offset+命令的字节长度。从节点在收到主节点发送的命令后,也会增长本身的offset,并把本身的offset发送给主节点,这样主节点同时保存本身的offset和从节点的offset,经过对比offset来判断主从节点数据是否一致。
repl_backlog:保存在主节点上的一个固定长度的先进先出队列,默认是1MB,名为复制积压缓冲区。(可设置)
Redis主从同步
主节点发送数据给从节点过程当中,不只会把写命令发送给从节点,还会降写命令入队到复制积压缓冲区内,主从服务器重连时,从服务器发送同步命令和offset,主服务器检测到offset在复制积压缓冲区内,则开始部分复制,不然全量复制。
主服务器发送写命令:
psync执行流程:
从节点发送psync[runID][offset]命令,主节点有三种响应:
一、fullresync:第一次链接,进行全量复制
二、continue:进行部分复制
三、err:不支持psync命令,进行全量复制