Redis 所学内容

  • 一、windows 下redis的登录
  • 命令行窗口登录
  • 二、基本数据类型
  • 1.字符串数据类型
  • 2.字符串数据类型
  • 3.set集合类型
  • 4.hash类型
  • 5.Zset有序集合：
  • 三.redis事务
  • 1.悲观锁与乐观锁
  • 2.redis的事务特新
  • 四.持久化：
  • 五.主从复制
  • 六.集群
  • 七. Redis应用问题


一、windows 下redis的登录

命令行窗口登录

1. E:  、 cd /Redis   跳转到E盘，再到Redis的目录下。
			2.用客户端访问：redis-cli

二、基本数据类型

1.字符串数据类型

存放数据：set key value 
			 获取键值队中的数据： get key

2.字符串数据类型

存放数据：lrupt 列表名称 数据 （向左插入数据）
			  		  rrupt 列表名称 数据 （向右插入数据）
			 取出全部数据：lrange 列表名 0 -1
			 根据下标来获取数据：lindex 列表名 下标值

3.set集合类型

存放数据：sadd 集合名称 value1 value2
			取出集合中的所有数据：smembers 集合名称

4.hash类型

存放数据：hset hash名 键名 值
		    批量存放多个数据：hmset hash名 键名 值 键名 值..
		    查看数据：hget hash名 键名

5.Zset有序集合：

三.redis事务

1.悲观锁与乐观锁

悲观锁：将资源绑定起来，进程与进程之间只能互斥地对资源进行占有与调用
							缺点：并发性低
			 乐观锁:   进程与进程之间可以占有资源，也可以使用资源。但是，若进程改变了资源的状态之前，必须确保资源已经是最新的状态，才可以改变资源状态。

2.redis的事务特新

①单独的隔离操作 
							事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。 
					②没有隔离级别的概念 
							队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行
					③不保证原子性 
							事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚 

	引出的问题：
						超卖：
							场景描述：当多个进程同时占有资源时，同一刻，多个线程对这个资源进行修改，这个资源
								就会变得不符合常理
								===》解决方法：
										乐观锁进行解决
						连接超时问题：
							  修改配置：

四.持久化：

RDB：将一段时间内的数据集存入到写入进到磁盘中

优点：
					    适合大规模的数据恢复
						对数据完整性和一致性要求不高更适合使用
						节省磁盘空间
						恢复速度快
		缺点：
						Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
						虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
						在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改

AOF：以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

五.主从复制

概念： 将主机中的数据复制到从机中

为什么要引入主从复制？解决了什么问题
				   读写分离，性能扩展
				   容灾快速恢复

1）一主多仆： 将这一台主句中的数据，分别写入到多台从机中，当主机挂起之后，还可以从机获取数据

2）薪火相传： 从机也可以找自己的从机，这台从机不属于主机

3）反客为主

当主机挂起后，从从机找一台当主机，原先的主机变成从机。
					引出问题：
						需要自己配置
					解决问题==》

4）哨兵模式

反客为主的自动版
		选主机规则：
			1.优先级可以自己设置，优先级高的称王 （低位高）
			2.优先级相同，拥有主机中的数据多的称王（兵多）
			3.数据一样多，每个redis实例启动后都会随机生成一个40位的runid，runid小的称王（天注定）

六.集群

概念：Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

解决了什么问题：
			容量不够，redis如何进行扩容？
			并发写操作， redis如何分摊？

七. Redis应用问题

1）缓存穿透

问题描述：
				当用户查询key对应的数据源时，每次从redis缓存中获取不到数据，便会直接到数据库中。此时，所有的请求都会来到数据库这边，然后数据库查询不到数据，无法进行缓存。（比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。）

								 
		 解决方案：
				（1）对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟
				（2）设置可访问的名单（白名单）：
				使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
				（3）采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。
				布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)
				将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。
				（4）进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

2）缓存击穿

问题描述：
			当用户大量查询一个key对应的数据时，这个key在数据库是存在的，但是这个key对应的缓存已经失效，所以此时
		    所有的请求都会转向数据库，这个时候大并发的请求可能会瞬间把后端DB压垮。

		解决方案：
			  1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长
			  2）实时调整：现场监控哪些数据热门，实时调整key的过期时长
			  3）使用锁：
				（1）就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。
				（2）先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key
				（3）当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；
				（4）当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

3）缓存雪崩

问题描述：