Redis基础（下）

Linux命令

1.cd：更改目录
cd~回到初始目录
cd … 回到上级目录
2.mkdir 创建目录
3.cp 拷贝文件
eg：cp redis 5.06/redis.conf myredis/
4. ll 查看目录内的文件
5.vim 文本编辑器
两种模式：命令模式，编辑模式
打开文件时默认时命令模式，可以查看文件的内容，输入i可以切换为编辑模式，此时才可以更改文件。按esc可以从编辑模式再切换为命令模式，此时才可以退出。
退出方式：输入：+q(如果文件被修改，会提醒未保存)
不保存，输入：q！
保存，输入：wq

Redis配置文件

1.单位的问题
1k/1kb/1m/1mb/1g/1gb是不同的，没有b的时候取整，单位的大小写是不敏感的
网络相关
2.bind 127.0.01 绑定IP地址的意思(能够访问服务端的地址) 当前的redis服务只能被本机访问
3.protect - mode yes 开启保护模式
当bind没有配置且登录不需要密码时，启动保护模式（启动保护模式）
4.port 6379 端口号
5timeout 0 客户端超过了 timeout的时间 0代表不断掉连接一直保持
6. tcp - keeplive 300 服务端对客户端的健康检查单位是秒，每300s去检查一次客户端的健康情况，避免服务端一直阻塞
7.tcp - backlog 511 队列数量(未完成3次握手和已完成三次握手的)
通用相关
8.daemonize no 后台运行开关
改为yes后重启redis验证，
redis配置文件的方式为：redis - server /root /myredis /redis.conf
9.pidfile/var/run/redis_6379.pid 当守护进程开启时，写入进程id的连接地址
10loglevel notice 四种级别，noctice生产环节
11logfile“”日炽存储的位置
12.databases16初始化数据库16个

Redis安全和淘汰策略

安全

config命令

是一种从客户端查看配置项信息的方式，使用 config get，属于危险命令，可以限制使用
安全命令
1.config get requirepass 查看密码
2.config set requirepass${password}操做密码
3.auth ${password}再执行命令前需要授权
4.config set requirepass “” 设置空串后恢复

限制配置

1.maxclients 最大客户端连接数，默认1w
2.maxmemory 最大内存设置
3.maxmemory - policy 缓存清除策略

安全校验配置

requirepass 代表是否设置密码，如果需要设置密码 config set requirepass${password}操做密码
此时输入命令前，需要先校验auth ${password}再执行命令前需要授权然后才能执行其他操作

危险命令限制

包含config/flushdb/flushall/keys
rename - command + 命令 +“”将此命令置为不可用

其他限制

1.maxclients 10000 最大并发数
2.maxmemory 最大内存
3.maxmemory - policy 缓存淘汰策略默认值 noeviction （不删除只报错）
其他策略主要分两种情况
allkeys（所有键值都可能删除）
volatile（只删除设置了过期时间的键值）

缓存有效期和过期策略

有效期叫做TTL（time to live）
设置有效期的作用：节省空间和数据弱一致性–有效期失效后保证数据的一致性

过期/淘汰策略：

当内存使用达到最大值时，需要使用某种算法来决定清理掉那些数据，以保证新数据的存入
FIFO
First In First Out 先进先出。判断被存储的时间，离目前最远的数据优先被淘汰。
LRU
Least Recently Used
最近最少使用，判断最近被使用的时间，目前最远的数据优先被淘汰
LFU
Least Frequently Used
最不经常使用。在一段时间内，数据被使用次数最少的，优先被淘汰
Redis缓存淘汰策略
volatile(不稳定的)，代表会过期的策略，等价于设置了exprire的数据

六种策略

1.noeviction：不删除策略，达到最大内存限制时，如果需要更多内存，直接返回错误信息。大多数写命令都会导致占用更多的内存（有极少数的会例外，如DEL）
2.allkeys-lru：所有key通用；优先删除最近最少使用（less recently used ，LRU）的key。
3.volatile-lru：优先删除最近最少使用（less recently used，LRU）的key（限于会过期的key）
4.allkeys-random：所有key通信；随机删除一部分key
5.volatile-random：随机删除一部分key（限于会过期的key）
6.volatile-ttl：优先删除剩余时间（time to live，TTL）短的key（限于会过期的key）
如果分为热数据，冷数据，推荐使用allkeys-lru策略

近似LRU算法

因为LRU算法需要消耗大量的内存，所采用近似LRU算法，并且是懒处理
算法原理：（使用随机采样法淘汰元素）
首先给每一个key增加一个额外24bit 的字段，记录最后被访问的时间戳。然后当内存超出maxmemor时，随机采样出5个key（通过maxmemory——samples设置），采样范围取决于时allkeys还是volatile，淘汰掉醉酒的key，如果仍然超出，继续采样淘汰
算法分析
采样范围越大，月接近严格LRU，redis3.0中增加了淘汰池，进一步提升了效果。淘汰池是一个大小为maxmemory_samples数组，每一次淘汰循环中，新随机出的key会和淘汰池中的key列表融合，淘汰掉最旧的key，剩余较旧的key列表放在淘汰池中等待下一次循环

Redis持久化

持久化–将数据（如内存中的对象）保存到可永久保存的存储设备中
方式一RDB：在指定的时间间隔内对数据进行快照存储，先将数据集心如临时文件，写入成功后，再替换之前的文件，用二进制压缩存储，是一次全量的备份
方式二AOF：以日志文本的形式记录服务器所处理的每一个数据更改指令，然后通过重放来恢复数据，是连续的增量备份

RDB

1.RDB触发和恢复（Redis DataBase）

命令触发

1）save，会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用
2）bgsave，该触发方式会fork一个人紫禁城，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候

自动触发

1）根据我们的save m n 配置规则自动触发；
2）从节点全量复制是，主节点发送rdb文件给从节点完成复制操作，主节点会触发bgsave；
3）执行debug reload 时；
4）执行shutdown时，如果没有开启aof，也会触发

恢复方式

将备份文件移动到redis安装牡蛎并启动服务即可

RDB-Fork原理

执行RDB时，服务器执行以下操作
1.redis调用系统函数（），创建一个子进程
2.子进程将数据集写入到一个临时RDB文件中
3.当子进程完成对临时RDB文件的写入时，redis用新的临时RDB文件替换原来的RDB文件，并删除旧的RDB文件
执行fork时，操作系统会使用写时复制（copy-on-write）策略，即fork函数发生的一颗父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响。新的RDB文件存储的时执行fork那一刻的内存数据在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的。任何时候RDB文件都是完整的

RDB性能分析

优点
1.通过RDB文件恢复数据比较快
2.RDB文件非常紧凑，适合于数据备份
3.通过RDB进行数据备份，由于使用子进程生成，所以对Redis服务器性能影响较小
缺点
1.采用RDB的方式可能会造成某个时间内数据的丢失，比如还没达到触发条件时服务器就死机了，那么这个时间段的数据就会丢失
2.使用save命令会造成服务器阻塞，直接数据同步完成才能接受后续请求
3.使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外forks子进程会耗费内存

AOF（Append Only File）

以日志的形式记录服务器所处理的每一个更改操作，但操作过多，aof文件过大时，加载文件回复数据会非常慢，为解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集。整个流程大体分两步，一是命令的实时写入。二是aof文件的重写
命令写入流程：命令写入—>追加到aof磁盘—>同步到aof磁盘

触发

命令触发：bgrewriteaof
自动触发：根据配置规则来触发
在写入aof日志文件时，如果redis服务宕机，则日志文件回出格式错位u，重启服务器时，服务器会拒绝载入这个aof文件，此时可以通过以下命令修复aof并恢复数据
redis-check-aof-fix.file.aof

AOF原理

再重写期间，由于主进程依然在相应命令，为了保证最终备份的完整性；因此他依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失。
为了把重写期间相应的写入信息也写道新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据，重写时直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令的合并AOF文件直接采用文本协议，主要是兼容性好、追加方便、可读性高。

AOF性能分析

优点
1.AOf只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少，
2.数据安全性高
缺点
1.AOF方式生成的日志文件太大，即使通过AFo重写，文件体积依然很大
2.数据恢复的速度比RDB慢

当RDB与AOF两种方式都开启时，Redis启动时会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整
Redis4.0提供了一个混合持久化的选择，将rdb文件的内容和增量的aof日志存在一起，重启时先加载rdb，在重放aof，以达到最大效率

Redis管道与事务

管道

首先管道技术时客户端提供的，与服务器无关，服务器始终使用，收到-执行-回复的顺序处理消息。而客户扼断通过对管道中的治领列表改变读写顺序，而节省答复IO时间，指令越多，效果越好。
管道测试：redis - benchmark（-p）
管道可以将多个命令打包，一次性的发送给服务器端处理

事务

一个成熟的数据库当然一定要支持事务，以保障多个操作的原子性。同时，事务还能保证一个事务中的命令依次执行而不会被其他命令插入
所有事务的基本用法，都是begin，commit，rollback
redis事务指令时，multl，exec，discard，虽然可以使用DISCARD取消事务，但是不支持回滚
当输入MULTL命令后，服务器返回ok表示事务开始成功，，然后依次输入需要在本次事务中执行的命令，每次输入一个命令，服务器并不会马上执行，而是返回“QUEUED”，这表示命令已经被服务器接受并且暂时保存起来，最后输入EXEC命令后，本次事务中的所有命令才会被依次执行
事务错误处理
1.语法错误，全不执行
2.运行草屋，出错后仍然继续执行
事务监测
将其中一条命令的执行结果作为另一条命令的执行参数，如i++，需要使用watch命令
WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令
执行EXEC命令之后会取消监控使用WATCH命令监控的键，如果不想执行事务中的命令，也可以使用UNWATCH命令来取消监控
使用方式 watch -> multi-> command->exec
注意：由于WATCH命令的作用只是当被监控的键被修改后取消之后的事务，并不能保证其他客户端不修改监控的值，所以当EXEC命令执行失败后需要手动重新执行整个事务
本质上时一种乐观锁

Redis分布式锁

乐观锁与悲观锁

悲观锁（Pessimistic Lock）：灭磁去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁。这样别人想拿数据就会被挡住，直到悲观锁被释放。
乐观锁（Optimistic Lock）：每次去拿数据的时候都认为别人不会修改。所以不会上锁，但是如果想要更新数据，则会在更新前检查在读取至更新这段时间别人有没有修改过这个数据。如果修改过，则重新读取，再次尝试更新，循环上述步骤直到更新成功
悲观锁VS乐观锁
1.悲观锁阻塞事务，了所灌输回滚重试
2.乐观锁适用于写比较少的情况下，即冲突很少发生时，可以省区锁的开销，加大了系统吞吐量
3.悲观锁适用于写比较多的情况下，因为如果乐观锁经常冲突，应用要不断进行重试，反倒降低性能

CAS算法

1.比较：读取到了一个值A，在将其更新为B之前，检查原址是否为A（未被其他线程改动）
2.设置：如果是，将A更新为B，结束，如果不是，则什么都不做
允许多个线程同时读取（因为根本没有加锁操作），但是只有一个线程可以成功更新数据，并导致其他要更新数据的线程回滚重试。也叫非阻塞同步（Non-blocking Synchronization）
乐观锁策略也被称为无锁编程。换句话说，乐观锁其实不是锁，它仅仅是一个循环重试的算法

乐观锁的缺点 – ABA问题

如果一个变量V初次读取的时候时A值，并且准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？不能，因为你在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的ABA问题

分布式锁

在很多场景中，我们为了保证数据的最终一致性，需要很多的计数方案支持。有时我们需要一个方法在同一时间内只能被同一个线程执行。再单击环境中，java中有很多处理并发的API,但是这个API在分布式场景中无能为力。单纯的java API 并不能提供分布式锁的能力。
分布式锁时控制分布式系系统之间同步访问共享资源的一种方式。分布式锁一般有三种实现方式
1.数据库乐观锁
2.基于Redis的分布式锁
3.基于Zookeeper的分布式锁
分布式锁的可靠性需满足以下四个条件
1.互斥性。在任意时刻，只有一个客户端能持有锁
2.不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后序其他客户端能加锁
3.具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁
4.加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁解掉。

Setnx + Lua

使用Redis实现分布式锁原理：
Redis为单进程单线程模式，采用队列模式将并发访问编程串行访问，且多客户端对Redis的连接并不存在竞争关系，基于此，Redis中可以使用SETNX命令实现分布式锁
SETNX–SET if Not exists(如果不存在，则设置)
若给定的key已经存在，则SETNX不做任何动作；如果需要解锁，使用key命令就能解锁

Redis集群

主从模式

为了保证高可用，redis - cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机时，就会启用从节点。。当其他主节点ping一个主节点A时，如果或半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和他的从节点A1都宕机了，那么该集群就无法提供服务了
优点
1.支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
2.为了分在Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
3.Slave同样可以接受其他Slaves的连接和同步请求，这样可以有效的分载Master的同步压力
缺点
1.Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端IP才能恢复
2.主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性
3.Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂

主从复制

在Redis中，用户可以通过执行SlAVEOF命令或者设置slaveof选项，让一个服务器去复制另一个服务器，我们称呼被复制的服务器为主服务器，而对主服务器进行复制的服务器被称为从服务器。

哨兵模式

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供给服务，但这个过程需要人工手动来操作。为此，Redis2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能
哨兵的作用就是监控Redis系统的运行情况，它的功能包括两个
1.监控主服务器和从服务器是否正常运行
2.主服务器出现故障时自动将从服务器转换为主服务器
优点
哨兵模式时基于主从模式的，所有主从模式的优点，哨兵模式都具有，主从可以自动切换，系统更健壮，可用性更高
缺点
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂

总结

Redis vs Memcached

总的来说，可以把Redis理解为是对Memcached的拓展。
1.性能上
性能上都和出色，具体到细节，由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached的性能要高于Redis。
2.内存空间和数据量大小
Memcached可以修改最大内存。采用LRU算法。Redis增加了VM的特性，突破了物理内存的限制
3.操作便利上
Memcached数据结构单一，仅用来缓存数据，而Redis支持更加丰富的数据类型，也可以在服务器直接对数据进行丰富的操作，这样可以减少网络IO次数和数据体积
4.可靠性上
Memcached不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的。Redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价

Redis支持的数据类型

详见上

Redis有哪几种数据淘汰策略

6种淘汰策略
1.noeviction：不删除策略，达到最大内存限制时，如果需要更多内存，直接返回错误信息。大多数写命令都会导致占用更多的内存（有极少数的会例外，如DEL）
2.allkeys-lru：所有key通用；优先删除最近最少使用（less recently used ，LRU）的key。
3.volatile-lru：优先删除最近最少使用（less recently used，LRU）的key（限于会过期的key）
4.allkeys-random：所有key通信；随机删除一部分key
5.volatile-random：随机删除一部分key（限于会过期的key）
6.volatile-ttl：优先删除剩余时间（time to live，TTL）短的key（限于会过期的key）
如果分为热数据，冷数据，推荐使用allkeys-lru策略

什么是Redis持久化?Redis哪几种持久化方法？优缺点是什么

RBD和AOF

Redis有哪些架构模式？各自特点？

主从
哨兵

什么是缓存穿透？如何避免？什么是缓存雪崩？如何避免？

缓存穿透
访问一个不存在的key，缓存不起作用，请求会穿透到DB，流量大时DB会挂掉
解决方案：采用布隆过滤器，使用一个足够大的bitmap,用于存储可能访问key，不存在的key直接被过滤
缓存雪崩
大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬间DB请求量大、压力骤增，引起雪崩
解决方案：给缓存设置过期时间时加上一个随机值时间，是的每个key的过期时间分不开来，不会集中在同一时刻失效
缓存击穿：
一个存在的key，再换粗过期的一刻，同时又大量的请求，这些请求都会击穿到DB，造成瞬间DB请求量过大，压力骤增
解决方案：在访问key之前，采用SETNX来设置一个短期key来所著当前key的访问，访问结束再删除该短期key

Redis基础笔记（上）

Redis基础笔记（下）相关推荐

Redis基础笔记--自认为很详细(●ˇ∀ˇ●)
1.Redis 学习笔记 2.Redis 简介 Redis 是我们在互联网应用中使用最广泛的一个 NoSQL 数据库,基于 C 开发的键值对存储数据库, Redis 这个名字是 Remote Dict ...
Java核心基础笔记(下)
09 枚举类与*注解一.枚举类的使用 1.枚举类的理解:类的对象只有有限个,确定的.我们称此类为枚举类 2.当需要定义一组常量时,强烈建议使用枚举类 3.如果枚举类中只有一个对象,则可以作为单例模式 ...
Redis基础笔记（二）
2019独角兽企业重金招聘Python工程师标准>>> 其他事务 Redis中事务是一组命令的集合, 一个事务中的命令要么都执行, 要么都不执行 > MULTI > S ...
Redis学习笔记①基础篇_Redis快速入门
若文章内容或图片失效,请留言反馈.部分素材来自网络,若不小心影响到您的利益,请联系博主删除. 资料链接:https://pan.baidu.com/s/1189u6u4icQYHg_9_7ovWmA( ...
Redis学习笔记~Redis在windows环境下的安装
Redis是一个key-value的存储系统,它最大的特点就是可以将数据序列化到文件中. redis存储在服务器的内存或者文件中,它不是session,不是cookies,它只是个更安全,更稳定,更可 ...
redis基础命令和数据操作命令学习笔记
redis基础命令和数据操作命令学习笔记基础命令安装成功后,redis的启动命令:先修改配置文件.将服务改成默认运行.然后以配置文件启动服务 redis-server config/redis-c ...
Andrew Ng-机器学习基础笔记（下）-Python实现代码
目录前言: 10. 应用机器学习的建议 10.1 决定下一步做什么 10.2 评估一个假设 10.3 模型选择和交叉验证集 10.4 诊断误差和方差 10.5 正则化和偏差/方差 10.6 学习曲线 ...
Redis基础2（Centos7 下安装redis）
Centos7 下安装redis redis是一个软件,帮助开发者对一台机器的内存进行操作. 1.安装redis 第一步:下载redis安装包命令 :wget http://download.re ...
20200624SparkStreaming学习笔记+redis基础
数据可视化 Spring Boot整合Echarts动态获取HBase的数据 1) 动态的传递进去当天的时间 a) 在代码中写死 b) 让你查询昨天的.前天的咋办? 在 ...

Redis基础笔记（下）