一、redis部署
二、redis命令工具
1、redis-server: 用于启动Redis 的工具
2、redis-benchmark: 用于检测Redis在本机的运行效率
3、redis-check-aof: 修复AOF持久化文件
4、redis-check-rdb: 修复RDB持久化文件
5、redis-cli: Redis 命令行工具
6、rdb 和aof 是redis服务中持久化功能的两种形式RDB AOF
7、redis-cli 常用于登陆至redis 数据库
三、redis-Cli命令行工具(远程登陆)
1、语法
redis-cli -h host -p port -a password
2、具体描述
2.1、-h 指定远程主机 2.2、-p 指定redis服务的端口号 2.3、-a 指定密码 未设置数据库密码可以省略-a选项 若不添加任何选项则表示使用127.0.0.1:6379连接本机上的redis数据库
四、redis-benchmark测试工具
Redis-benchmark是官方自带的redis性能测试工具,可以有效的测试redis服务的性能基本的测试语法:redis-benchmark[选项][选项值] -h:指定服务器主机名 -p:指定服务器端口 -s:指定服务器socket(套接字) -c:指定并发连接数 -n:指定请求数 -d:以字节的形式指定SET/GET值的数据大小 -k:1=keep alive 0=reconnect -r:SET/GET/INCR使用随机key,SADD使用随机值 -p:通过管道传输请求 -q:强制退出REDIS。仅显示query/sec值 –csv:以CSV格式输出 -l:生成循环,永久执行测试 -t:仅运行以逗号分隔的测试命令列表 -I:idle模式,仅打开N个idle连接并等待 Set:存放数据 Get获取数据 Keys* 显示当前数据库中以M开头的数据 M?显示当前数据库中以M开头后面包含任意一位的数据 V??查看当前数据库中以V开头V开头后面包含任意两个 Exitsts判断该键是否存在 删除del 查看value的数据类型 Rename 重写 Dbsize当前数据库的数据多少 清空
查看redis性能管理
五、分布式锁
问题:关键数据在修改时出现脏读现象,两条请求同时修图同一条数据,数据则被死锁
1、解决死锁的方式是使用setnx,使用该方式当有数据时不写入数据,当无数据时则写入数据。
2、当第一条请求抵达数据时,在数据前加锁,其他请抵达时,在锁前等待,等待锁释放,第一种等待锁过期(过期时间[固定值])
3、使用watch dog监听锁的到期日期,在任务未完成时为其续期。
4、释放锁的方式:固定释放时间+watch dog lock.unlock(提高性能、尽可能的避免死锁)当多个客户端访问redis同一个关键数据时,客户端的请求修改数据时均会使用setnx,当第一个客户端的请求任务在执行修改过程中,redis会对此数据进行加锁,可以通过固定过期时间/watch dog的形似续期+通知lock.unlock释放锁的机制进行释放,在锁定期间,第二个客户端的请求任务不会被修改数据,而是会等待。目的是解决或者缓解高并发的压力,因为本身redis,使用的是单线程epoll+i/o复用的机制,所以第二个任务请求socket所被分配的文件描述符,不是就绪状态,所以不会消耗太多资源,不会占用太多资源。
六、redis高可用
在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务,但是在redis语境中,高可用的含义似乎要宽泛一些,除了保证提供正常服务,如主从分离,快捷容灾技术,还需要考虑数据容量的扩展,数据安全不会丢失等。在redis中,实现高可用的技术主要包括持久化,主从复制,哨兵+集群。
1、持久化:是最简单的高可用,有时甚至不被归类于高可用的手段,主要作用是数据备份,即将数据存储在硬盘中,保证数据不会因为进程退出而丢失。
2、主从复制:是高可用redis的基础,哨兵和集群(cluster)都是在主从复制基础上实现高可用的,主从复制主要实现了多机备份,以及对于读操作的负载均衡和简单的故障修复,缺点是故障修复无法自动化,写操作无法负载均衡,存储能力受到单机的限制(非常吃资源)
3、哨兵:在主从复制的基础上,哨兵实现了自动化的故障切换和修复,缺点:写操作无法负载均衡受到单机的限制
4、集群:通过集群,redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。
七、reids持久化
1、持久化的功能:redis是内存数据库,数据都是存储在内存中,为了避免服务器断电等导致redis进程异常退出后数据的永久丢失,需要定期将redis中的数据以某种形式(数据或命令)从内存中保存到磁盘中,当下次redis重启时,利用持久化文件实现数据恢复,除此之外,为了进行灾难备份,可以将持久化文件copy到一个远程位置(NFS/rsync)。
2、redis提供的两种方式进行持久化
2.1、RDB持久化:原理是将redis在内存中的数据库记录定时保存到磁盘上(类似快照) 2.2、AOF持久化:原理是将redis的操作日志以追加的方式写入文件,类似于mysqld的binlog(基于日志持久化)
八、缓存漏洞
1、缓存穿透缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞。
1.1、解决办法有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法(我们采用的就是这种),如果一个查询返回的数据为空(不管是数 据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。
2、缓存雪崩缓存雪崩是指在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发到DB,DB瞬间压力过大导致雪崩
2.1、解决方案缓存失效时的雪崩效应对底层系统的冲击非常可怕,大多数系统设计者考虑到使用加锁或者队列的方式保证缓存的单线程写,从而避免失效时大量的并发请求落到底层存储系统上,该处分享一个简单方案将缓存失效时间分散开,比如我们可以在原有的失效时间基础上增加一个随机数,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。
3、缓存击穿对于一些设置了过期时间的key,如果这些key可能会在某些时间点被超高并发地访问,是一种非常“热点”的数据。这个时候,需要考虑一个问题:缓存被“击穿”的问题,这个和缓存雪崩的区别在于这里针对某一key缓存,前者则是很多key。缓存在某个时间点过期的时候,恰好在这个时间点对这个Key有大量的并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮
3.1、使用互斥锁解决方案业界比较常用的做法就是使用MUTEX,简单来说,就是在缓存失效的时候(判断拿出来的值是否为空),不是立即去load db,而是先使用缓存工具的某些带成功操作返回值的操作,例如redis的setnx或者memcache的add,去set一个mutex key,当操作返回成功时,再进行load db的操作并回设缓存,否则就重试整个GET缓存的方式。
3.2、”提前”使用互斥锁在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候,马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。
九、AOF和RDB
700行 704行 796行 1、文件追加append redis先将写命令追加到缓冲区,而不是直接写入文件,主要是为了避免每次有写命令都直接写入硬盘,导致硬盘IO成为redis负载的瓶颈。命令追加的格式是redis命令请求的协议格式,它是一种纯文本格式,具有兼容性好,可读性强,容易处理,操作简单避免二次开销等优点,在AOF文件中,除了用于指定数据库的select命令是由redis添加的,其他都是客户端发送来的写命令。
2、文件写入和文件同步 redis提供了多种AOF缓存区的同步文件策略,策略涉及到操作系统的write函数和fsync函数。AOF缓存区的同步文件策略存在三种同步方式,它们分别是**:no;always;everysec.**
729
十、redis具有以下几个优点
1、具有极高的数据读写速度,数据读取的速度最高可达到110000次/s,数据写入速度最高可达到81000次/S。
2、支持丰富的数据类型,支持key-value,string、lists、hashes(散列值)、sets及ordered sets等数据类型操作
2.1、string 字符串(可以为整形,浮点和字符型,统称元素) 2.2、list 列表(实现队列,元素不唯一,先入先出原则) 2.3、set 集合(各不相同的元素) 2.4、hash hash散列值(hash的key必须是唯一的) 2.5、set /ordered sets 集合/有序集合
3、支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。
4、原子性:redis所有操作都是原子性的
5、支持数据备份,即master-salve模式的数据备份
十一、算法
1、漏通算法
漏桶算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,可以看出漏桶算法能强行限制数据的传输速率。
2、令牌通算法
对于很多应用场景来说,除了要求能够限制数据的平均传输速率外,还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了,令牌桶算法更为适合。令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌,而如果请求需要被处理,则需要先从桶里获取一个令牌,当桶里没有令牌可取时,则拒绝服务。
3、区别
漏桶算法与令牌桶算法的区别在于:漏桶算法能够强行限制数据的传输速率。令牌桶算法能够在限制数据的平均传输速率的同时还允许某种程度的突发传输。需要说明的是:在某些情况下,漏桶算法不能够有效地使用网络资源。因为漏桶的漏出速率是固定的,所以即使网络中没有发生拥塞,漏桶算法也不能使某一个单独的数据流达到端口速率。因此,漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常,漏桶算法与令牌桶算法结合起来为网络流量提供更高效的控制。不能说令牌桶一定比漏洞好,它们使用场景不一样。令牌桶可以用来保护自己,主要用来对调用者频率进行限流,为的是让自己不被打垮。所以如果自己本身有处理能力的时候,如果流量突发(实际消费能力强于配置的流量限制),那么实际处理速率可以超过配置的限制。而漏桶算法,这是用来保护他人,也就是保护他所调用的系统。主要场景是,当调用的第三方系统本身没有保护机制,或者有流量限制的时候,我们的调用速度不能超过他的限制,由于我们不能更改第三方系统,所以只有在主调方控制。这个时候,即使流量突发,也必须舍弃。因为消费能力是第三方决定的。
十二、redis性能管理
1、内存碎片率
操作系统分配的内存值used_memory_rss 除以redis使用的内存值used_memory计算得出内存碎片是由操作系统低效的分配/回收物理内存导致的。跟踪内存碎片率对理解redis实例的资源性能是非常重要的;1)内容碎片率稍大于1是合理的,这个值表示内存碎片率比较低;2)内存碎片率超过1.5说明redis消耗了实际需要的物理内存的150号,其中50号是内存是内存碎片率,需要在redis-cli工具上输入shutdown save命令,并重启redis服务器;3)内存碎片低于1的,说明redis内存分配超出了物理内存,操作系统正在进行内存交换,需要增加可用物理内存或者减少redis内存占用。
2、内存使用率
redis实例的内存使用率超过可用最大内存,操作系统将开始进行内存与swap空间交换。为了避免内存交换发生的办法:针对缓存数据大小选择安装redis实例;尽可能的使用hash数据结构存储;设置key的过期时间。
3、过期时间
为了保证合理分配redis有限内存资源,当达到设置的最大阈值时,需选一种key的回收策略,默认情况下回收策略是禁止删除。
4、删除策略
十三、数据类型
string 数据类型:最大存储512MB的数据,是二进制安全的,即可以存储任何数据,比如数字,图片,序列化对象等
1、set/get/append/strlen Append追加 Exists判断是否存在 Strlen获取指定的key的字符长度
2、GETSET 3、setex设置指定key的过期时间 4、MSET/MGET/MSETNX 5、五种数据类型合集
|