Redis详细教程应以官方文档为标准
常用命令
启动redis服务 :redis-server
启动redis客户端:redis-cli
redis默认有16个数据库
切换数据库：select 0 切换至第0个数据库
查看数据库大小：dbsize
设置key：set name1 xhf
获得value：get name1
查看数据库所有的key：keys *
清空当前数据库：flushdb
清空所有数据库：flushall
判断key是否存在：exists name1
将key移动到1号数据库：move name1 1
使key 10秒后过期：expire name1 10
查看key还有几秒过期：ttl name1
查看key的类型：type name1
redis-Key基本类型
String
在value后添加字符hello：append name1 hello（如果没有key，相当于set
获取字符串的长度：strlen name1
使value自增 1 / 减 1：incr name1 / decr name1
使value自增 n / 减 n ：incrby name1 10 / decrby name1 10
获取字串：getrange name1 1 3（获取1-3的字串）
替换字串：setrange name1 1 xxx（替换第一个字符开始的三个字符为xxx）
设置key，并在30秒后过期：setex name1 30 "hello"
如果key不存在，设置key：setnx name1 xhf（如果key已经存在了，就会设置失败，分布式锁中常用！）
批量设置：mest k1 v1 k2 v2 k3 v3（原子性操作：要么全部成功，要么全部失败）
mset user:1:name xhf（可以设置id）
批量获取：mget k1 k2 k3
如果存在批量设置：msetnx
先get再set：getset name1 xhf（先返回原来的值，然后设置新的值）
List
相当于双端队列，两边插入改动元素效率最高，中间元素的改动效率低。
可以实现消息队列和栈。
将一个值one插入列表头部：lpush list one
将一个值two插入列表尾部：rpush list two
查看列表区间0-1的值：lrange list 0 1（0 -1 表示全部）
从头部 / 尾部移除值：lpop / rpop
通过下表获取值： lindex list 0
获取列表长度：llen
移除指定的1个one值：lrem list 1 one
移除下标之间的值：ltrim list 2 4
移除列表最后一个元素，添加到新列表中：lpoplpush list list2
给指定下标赋值：lset list 0 one（若列表不存在或者下标值不存在，则赋值失败）
在指定元素前或后插入值：linsert list before "word" "new"（在word前插入new、在后面插入用after）
set
无序不重复集合
添加一个元素：sadd myset "hello"
删除一个元素： srem myset hello
查看元素：smembers myset
判断元素在set中：sismember myset hello
获取元素个数：scard myset
随机获取一个元素：srandmember myset 随机获取3个元素：srandmember myset 3
删除随机元素：spop myset
将指定元素移动到另外的集合中：smove myset myset2 "hello"
求集合并集：sunion mylist1 mylist2
求集合交集：sinter mylist1 mylist2
求集合差集：sdiff mylist1 mylist2 （mylist1 - mylist2)
hash
相当于一个map集合 key - value，和string很像，可以存储一些经常变更的数据，适合对象的存储
添加元素：hset myhash field1 xhf
查看元素：hget myhash field1
批量赋值：hmset myhash field1 x field2 y field3 z
删除一个key：hdel myhash field1
获取长度：hlen myhash
判断值是否存在：hexists myhash field1
查看所有key：hkeys myhash
自增自减：hincr myhash field1 1 / hdecr myhash field1 3
如果不存在创建：hsetnx myhash field1 hello
Zset
有序集合 myset score value （score可用来排序）和set几乎一样
添加一个元素：zadd myset 1 one （1表示在第一个位置，或者表示值为1）
查看所有元素：zrange myset
按照score排序范围查看所有元素：zrangebyscore myset -inf +inf（从小到大排序，±inf可以换成具体值）
从大到小排序：zrevrange myset
删除一个元素：zrem myset hello
查看集合元素个数：zcard myset
查看区间内的元素数量：zcount myset 1 6
geospatial
地理位置，本质是一个Zset，可以用Zset的命令
添加地理位置：geoadd china:city 116.40 39.90 beijing （经度、纬度、名称）
查询地点的位置：geopos china:city beijing
查询两地点之间的距离：geodist china:city beijing shanghai
查询某位置半径1000km内的地点：georadius china:city 110 30 1000 km
withcoord显示查询出的经纬信息、withdist显示到某位置的直线距离、count n 只查询出n个
查询某地点半径1000km内的地点：georadiusbymember china:city beijing 1000 km
hyperloglog
基数统计的算法，速度快，占用内存较小，是固定的，有0.81%的错误率。
添加元素：pfadd mykey a b c d e
统计数量：pfcount mykey
合并两组元素：pfmerge newkey mykey1 mykey2
bitmaps
位存储，适合存储用户打卡信息等，只有2个状态的信息。
添加一个元素：setbit sign 0 1 （设置sign第0位的值为1）
获取某一位的值：getbit sign 3 （查看第3为状态）
统计1的数量：bitcount sign 0 4（统计第0-4位的1数量）
spingboot 整合reids
- redis被封装在springdata中
- 在springboot2.x后，原来的jedis被替换成为了lettuce
jedis：采用直连的方式，多个线程操作是不安全的，想要避免这种情况需要使用jedis pool连接池！
lettuce：采用netty，实例可以在多个线程中共享，不存在线程不安全的情况！可以存在线程数量 - 默认配置类是<object, object>，需要自己创建配置类，对RedisTemplate进行一些配置
- 使用autowired注入RedisTemplate类，就可以直接对redis进行操作
- 在对redis数据库操作时，传入的所有对象需要进行序列化，企业开发过程中，一般会将redis的操作封装成一个工具类，RedisUtils，使用工具类进行操作，简化代码逻辑
redis.config配置文件
- 配置文件对unit单位大小写不敏感
- 可以在里面再添加其他配置文件
daemonize yes：以守护进程的方式运行，默认是 no，我们需要自己开启为yes!
pidfile /var/run/redis_6379.pid：如果以后台的方式运行，我们就需要指定一个 pid 文件!
loglevel notice：日志的类型
logfile ""：日志文件位置名
database 16：默认数据库的数量
save 900 1：持久化：在规定时间内执行了多少次操作，则会持久化到.rdb .aof文件中
stop-writes-on-bgsave-error yes：持久化如果出错，是否还需要继续工作!
rdbcompression yes： 是否压缩 rdb 文件，需要消耗一些cpu资源!
rdbchecksum yes：保存rdb文件的时候，进行错误的检查校验!
dir ./： rdb 文件保存的目录!
Redis持久化
RDB（Redis DataBase）：
- 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话进的Snapshot快照，它恢复时是将快照文件直接读到内存里
- Redis会单独创建( fork)一个进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何10操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢。
- rdb保存的文件是dump.rdb
- save的规则满足的情况下，会自动触发rdb规则
- 执行 flushall 命令，也会触发我们的rdb规则!
- 退出redis，也会产生 rdb 文件!
备份就自动生成一个 dump.rdb
- 优点 :
- 适合大规模的数据恢复!
- 对数据的完整性要不高 !
- 缺点:
- 需要一定的时间间隔进程操作! 如果redis意外宕机了，这个最后一次修改数据就没有的了!
- fork进程的时候，会占用一定的内容空间 !
AOF（Append Only File）：
- 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
- aof保存的是 appendonly.aof 文件
- 默认是不开启的，需要取配置文件手动开启：
appendonly yes - appendonly.aof 文件被破坏后，redis不能启动，可以使用redis-check-aof工具进行修复，但可能对原本的数据产生一些错误
- 如果 aof 文件大于默认的 64m!，会fork一个新的进程来将文件进行重写!
appendfsync always
appendfsync everysec
appendfsync no- 优点:
- 每一次修改都同步，文件的完整会更加好 !
- 每秒同步一次，可能会丢失一秒的数据
- 从不同步，效率最高的 !
- 缺点:
- 相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢 !
- Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化!
扩展
- RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
- AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
- 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
- 同时开启两种持久化方式
- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
- RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢 ?作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份 )，快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
- 性能建议
- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
- 如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价是带来了持续的I0，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
- 如果不Enable AOF，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大第10，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。
Redis发布订阅
一般被用于构建即时通信应用，比如网络聊天室、实时广播、实时提醒等
订阅一个频道：subscribe mychannel
退订一个频道：unsubscribe mychannel
在一个频道发布信息：publish mychannel "hello"
订阅多个给定模式的频道：psubscribe pattern
退订多个给定模式的频道：punsubscirbe pattern
原理：
- Redis是使用C实现的，通过分析 Redis 源码里的 pubsub.c 文件，了解发布和订阅机制的底层实现，籍此加深对 Redis 的理解。
- Redis 通过 PUBLISH、SUBSCRIBE 和 PSUBSCRIBE 等命令实现发布和订阅功能.
通过 SUBSCRIBE 命令订阅某频道后，redis-server 里维护了一个字典，字典的键就是一个个 channel，而字典的值则是一个链表，链表中保存了所有订阅这个 channel 的客户端。SUBSCRIBE 命令的关键，就是将客户端添加到给定 channel 的订阅链表中 - 通过 PUBLISH 命令向订阅者发送消息，redis-server 会使用给定的频道作为键，在它所维护的 channel 字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者
- Pub/sub 从字面上理解就是发布 (Publish ) 与订阅( Subscribe )，在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。
Redis主从复制
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower); 数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave 以读为主。
默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点或没有从节点)，但一个从节点只能有一个主节点。主从复制的作用主要包括:
- 数据冗余: 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的几余。
- 负载均衡:在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务(即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点)，分担服务器负载，尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
- 高可用基石:除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的(宕机)，原因如下:
- 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。
- 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
复制原理
- Slave启动成功连接到 master 后会发送一个sync命令。
- Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
- 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步。
- 但是只要是重新连接master，一次完全同步(全量复制)将被自动执行。
测试：将一个节点设置为端口6379的节点的从机：slaveof 127.0.0.1 6379
一主二从：
- 主机断开连接，从机依旧连接到主机的，但是没有写操作，这个时候，主机如果回来了，从机依旧可以直接获取到主机写的信息!
- 如果是使用命令行，来配置的主从，这个时候如果重启了，就会变回主机!
- 这时只要再变为从机，立马就会从主机中获取值!
主从链路：
- 主节点连接一个从节点，从节点再连接一个从节点，当第一个主节点宕机后，第二个从节点依旧还是从节点，可以通过
slaveof no one使自己成为主节点 - 当原先的主节点连接回来后，第二个节点依旧是主节点。
上面两种模式在实际开发中并不常用，一般使用哨兵模式自动进行主从切换。
哨兵模式
- 主从切换技术的方法是:当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel( 哨兵)架构来解决这个问题。
- 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令 ，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
- 优点
- 哨兵集群，基于主从复制模式，所有的主从配置优点，它全有
- 主从可以切换，故障可以转移，系统的可用性就会更好
- 哨兵模式就是主从模式的升级，手动到自动，更加健壮 !
- 缺点
- Redis 不好啊在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦!
- 实现哨兵模式的配置其实是很麻烦的，里面有很多选择!
哨兵配置文件：sentinel.conf
- 设置一个哨兵，监控myredis节点：
sentinel monitor myredis 127.0.0.1 6379 1（host：127.0.0.1 port：6379，1表示主机挂了需要投票，票数最多的是成为新主机） - 启动哨兵：
redis-sentinel
Redis缓存穿透和雪崩
Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。
缓存穿透
缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透
解决方案
- 布隆过滤器：
布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力; - 缓存空对象
当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源;
缓存击穿
这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
当某个key在过期的瞬间，有大量的请求并发访问]，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。
解决方案
- 设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题 - 加互斥锁
分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。
缓存雪崩
缓存雪崩，是指在某一个时间段，缓存集中过期失效，或Redis宕机
产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。
解决方案
- redis高可用
这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活） - 限流降级
这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待 - 数据预热
数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
扫一扫
1670
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
