1、redis的主从配置
1.1为什么要实现主从配置
①通过上篇文章简介的数据库发展史我们可以知道，为了减轻服务器数据库的io压力，出现了数据库集群，配置主从数据库，实现读写分离，减缓数据库的压力
②redis单机服务：可能会出现单点故障，导致缓存失效，压力/性能也不好
1.2如何实现主从配置
1.2.1配置主redis
根据redis初始那一章修改配置文件，开启服务，相当于正常开启。
1.2.2配置从redis
①复制并重命名配置文件cp redis.conf slave.conf ②修改复制的配置文件将绑定的ip设置为虚拟机的ip(主机绑定的ip0.0.0.0代表任意IP链接通过xshell连接或者dos连接服务器时连接的是本机的ip)用我的不行的，修改端口号以及bind
将replicaof 打开行主机ip以及主机端口写上
所有命令展示，复制的配置文件要自己进去修改
1.2.3连接主从redis
主：直接像往常一样连接这是通过本机ip连接的127.0.0.1是一个回返ip返回的是你电脑的ip常用做测试
从：指定端口号6378以及虚拟机中redis部署的主机ip，就是刚刚修改的复制的配置文件中的bind
验证是否开启
1.3主从redis的使用
在主中写的数据可以在从中查看，但不可以在从中写入数据，现在主从就同步了
2、redis数据的持久化
2.1为什么要将数据持久化
Redis 的读写都是在内存中，所以它的性能较高，但在内存中的数据会随着服务器的重启而丢失，为了保证数据不丢失，我们需要将内存中的数据存储到磁盘， Redis 重启时能够从磁盘中恢复原有的数据，这个过程就叫做 Redis 的持久化。
持久化的方式
2.2快照方式（RDB, Redis DataBase）
将某一个时刻的内存快照（Snapshot）数据，以二进制的方式写入磁盘的过程。
触发方式
2.2.1手动触发
手动触发持久化的操作有两个： save 和 bgsave ，它们主要区别体现在：是否阻塞 Redis 主线程的执行。
① save 命令 在客户端中执行 save 命令，就会触发 Redis（单线程） 的持久化，但同时也是使 Redis 处于阻塞状态，直到 RDB 持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用。
② bgsave 命令 bgsave（background save）既后台保存的意思， 它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来执行持久化，整个过程中只有在 fork() 子进程时有短暂的阻塞，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求了，相对于整个流程都阻塞的 save 命令来说，显然 bgsave 命令更适合我们使用。
2.2.2自动触发
① save m n save m n 是指在 m 秒内，如果有 n 个键发生改变，则自动触发持久化。 参数 m 和 n 可以在 Redis 的配置文件中找到，例如，save 60 1 则表明在 60 秒内，至少有一个键发生改变，就会触发 RDB 持久化。 自动触发持久化，本质是 Redis 通过判断，如果满足设置的触发条件，自动执行一次 bgsave 命令。 注意：当设置多个 save m n 命令时，满足任意一个条件都会触发持久化。 通过命令行也可以修改配置文件但是他只对当前服务窗口有效，一旦重启服务后则不生效，修改配置文件是永久修改
② flushall flushall 命令用于清空 Redis 数据库文件，在生产环境下一定慎用，当 Redis 执行了 flushall 命令之后，则会触发自动持久化，把 RDB 文件清空，删库跑路的命令
2.2.3RDB的优缺点
优点：
①RDB 的内容为二进制的数据，占用内存更小，更紧凑，更适合做为备份文件
②RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复
③RDB 可以更大程度的提高 Redis 的运行速度，因为每次持久化时 Redis 主进程都会 fork() 一个子进程，进行数据持久化到磁盘，Redis 主进程并不会执行磁盘 I/O 等操作
缺点：
①因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，则会丢失一段时间内的 Redis 数据
②RDB 需要经常 fork() 才能使用子进程将其持久化在磁盘上。如果数据集很大，fork() 可能很耗时，并且如果数据集很大且 CPU 性能不佳，则可能导致 Redis 停止为客户端服务几毫秒甚至一秒钟。
2.3文件追加方式（AOF, Append Only File)
记录所有的操作命令，并以文本的形式追加到文件中；默认是关闭的，在命令行中查看与修改，只对当前操作生效，想要永久生效可以修改配置文件
原先没有aof文件修改了配置文件之后就会生成一个aof文件
触发方式
2.3.1自动触发
①满足 AOF 设置的策略触发
always：每条 Redis 操作命令都会写入磁盘，最多丢失一条数据；
everysec：每秒钟写入一次磁盘，最多丢失一秒的数据；
no：不设置写入磁盘的规则，根据当前操作系统来决定何时写入磁盘，Linux 默认 30s 写入一次数据至磁盘。
这三种配置可以在 Redis 的配置文件（redis.conf）中设置，
②满足 AOF 重写触发
(1)AOF的出现背景
AOF 是通过记录 Redis 的执行命令来持久化（保存）数据的，所以随着时间的流逝 AOF 文件会越来越多，这样不仅增加了服务器的存储压力，也会造成 Redis 重启速度变慢，为了解决这个问题 Redis 提供了 AOF 重写的功能。
(2)什么是AOF重写
AOF 重写指的是它会直接读取 Redis 服务器当前的状态，并压缩保存为 AOF 文件。例如，我们增加了一个计数器，并对它做了 99 次修改，如果不做 AOF 重写的话，那么持久化文件中就会有 100 条记录执行命令的信息，而 AOF 重写之后，之后记录一条此计数器最终的结果信息，这样就去除了所有的无效信息。
(3)AOF重写的实现
触发 AOF 文件重写，要满足两个条件，这两个条件也是配置在 Redis 配置文件中的，它们分别：
• auto-aof-rewrite-min-size：允许 AOF 重写的最小文件容量，默认是 64mb 。
• auto-aof-rewrite-percentage：AOF 文件重写的大小比例，默认值是 100，表示 100%，也就是只有当前 AOF 文件，比最后一次（上次）的 AOF 文件大一倍时，才会启动 AOF 文件重写。
(4)重写流程
AOF 文件重写是生成一个全新的文件，并把当前数据的最少操作命令保存到新文件上，当把所有的数据都保存至新文件之后，Redis 会交换两个文件，并把最新的持久化操作命令追加到新文件上
2.3.2手动触发
在客户端执行 bgrewriteaof 命令就可以手动触发 AOF 持久化，自动触发 AOF 文件重写。
2.3.3优缺点
优点：
①AOF 持久化保存的数据更加完整，AOF 提供了三种保存策略：每次操作保存、每秒钟保存一次、跟随系统的持久化策略保存，其中每秒保存一次，从数据的安全性和性能两方面考虑是一个不错的选择，也是 AOF 默认的策略，即使发生了意外情况，最多只会丢失 1s 钟的数据；
②AOF 采用的是命令追加的写入方式，所以不会出现文件损坏的问题，即使由于某些意外原因，导致了最后操作的持久化数据写入了一半，也可以通过 redis-check-aof 工具轻松的修复redis-check-aof --fix …/src或者其它；
③AOF 持久化文件，非常容易理解和解析，它是把所有 Redis 键值操作命令，以文件的方式存入了磁盘。即使不小心使用 flushall 命令删除了所有键值信息，只要使用 AOF 文件，删除最后的 flushall 命令，重启 Redis 即可恢复之前误删的数据
缺点：
①对于相同的数据集来说，AOF 文件要大于 RDB 文件；
②在 Redis 负载比较高的情况下，RDB 比 AOF 性能更好；
③RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 更健壮。
如果RDN和AOF同时开启会以加载appendonly.aof文件为主
2.4混合持久化方式
Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件，这样既能保证 Redis 重启时的速度，又能减低数据丢失的风险。
3、Redis事务
3.1什么是事务
事务指的是提供一种将多个命令打包，一次性按顺序地执行的机制，并且保证服务器只有在执行完事务中的所有命令后，才会继续处理此客户端的其他命令。事务也是其他关系型数据库所必备的基础功能，一般涉及金钱消费等肯定会用到事务
3.2事务的基本使用
3.2.1事务在其他语言中(关系型数据库mysql)，一般分为三个阶段：
第一阶段：开启事务——Begin Transaction
第二阶段：执行业务代码，提交事务——Commit Transaction
第三阶段：业务处理中出现异常，回滚事务——Rollback Transaction
3.2.2Redis 中的事务从开始到结束也是要经历三个阶段：
第一阶段：开启事务multi命令
第二阶段：命令入列
第三阶段：执行事务/放弃事务exec命令/discard命令
3.3在redis中使用事务
3.3.1开启
当客户端是非事务状态时，使用 multi 命令，客户端会返回结果 OK，从非事务状态转变为事务状态，如果客户端已经是事务状态，再执行 multi 命令会 multi 命令不能嵌套的错误，但不会终止客户端为事务的状态
3.3.2命令入列
客户端进入事务状态之后，执行的所有常规 Redis 操作命令（非触发事务执行或放弃和导致入列异常的命令）会依次入列，命令入列成功后会返回 QUEUED，命令会按照先进先出（FIFO）的顺序出入列，也就是说事务会按照命令的入列顺序，从前往后依次执行。
3.2.3执行事务/放弃事务
执行事务
放弃事务
3.4事务错误&回滚
3.4.1执行时才会出现的错误（简称：执行时错误）
命令敲错(仅限可以成功入队的错误命令)当执行的时候会报错，但是不影响正确的命令的执行
3.4.2入列错误不会导致事务结束
3.4.3入列错误导致事务结束
命令敲错无法入队时提交命令的时候会导致事务结束无法成功执行，但是可以放弃discard
3.4.4为什么不支持事务回滚？
① Redis 事务的执行时，错误通常都是编程错误造成的，这种错误通常只会出现在开发环境中，而很少会在实际的生产环境中出现，所以他认为没有必要为 Redis 开发事务回滚功能；
②不支持事务回滚是因为这种复杂的功能和 Redis 追求的简单高效的设计主旨不符合。
这里不支持事务回滚，指的是不支持运行时错误的事务回滚。
4、Redis管道技术-pipeline
前言： 把命令打包一次性提交给服务端，服务端统一返回，避免多次交互浪费网络资源以及网络延迟，他是客户端提供的一种处理技术
4.1为什么有管道技术
管道技术（Pipeline）是客户端提供的一种批处理技术，用于一次处理多个 Redis 命令，从而提高整个交互的性能。通常情况下 Redis 是单行执行的，客户端先向服务器发送请求，服务端接收并处理请求后再把结果返回给客户端，这种处理模式在非频繁请求时不会有任何问题。但如果出现集中大批量的请求时，因为每个请求都要经历先请求再响应的过程，这就会造成网络资源浪费，此时就需要管道技术来把所有的命令整合一次发给服务端，再一次响应给客户端，这样就能大大的提升了 Redis 的响应速度
4.2管道技术解决了什么问题
管道技术解决了多个命令集中请求时造成网络资源浪费的问题，加快了 Redis 的响应速度，让 Redis 拥有更高的运行速度。但要注意的一点是，管道技术本质上是客户端提供的功能，而非 Redis 服务器端的功能。
4.3管道技术需要注意的事项
①发送的命令数量不会被限制，但输入缓存区也就是命令的最大存储体积为 1GB，当发送的命令超过此限制时，命令不会被执行，并且会被 Redis 服务器端断开此链接；
②如果管道的数据过多可能会导致客户端的等待时间过长，导致网络阻塞；
③部分客户端自己本身也有缓存区大小的设置，如果管道命令没有没执行或者是执行不完整，可以排查此情况或较少管道内的命令重新尝试执行。
4.4管道使用
打开pycharm，在pycharm中开启redis的管道
import redis
import time # 验证开启管道和不开启管道执行的速度
r = redis.StrictRedis(host='127.0.0.1',prot=6379
# 创建管道)
t1 = time.time()
pl = r.pipeline()
for i in range(100):
pl.set('%s-key' % i,'%s-value' % i)
pl.execute()
t2 = time.time()
print(t2-t1) # 打印执行命令的时间5、查询附近的人-GEO
点击此处查看经纬度(查询链接) Redis 在 3.2 版本中增加了 GEO 类型用于存储和查询地理位置(用经纬度表示位置)，关于 GEO 的命令不多，主要包含以下 6 个：
5.1geoadd：添加地理位置
geoadd key longitude latitude member [longitude latitude member] 此命令支持一次添加一个或多个位置信息。longitude 表示经度、latitude 表示纬度、member 是为此经纬度起的名字
5.2geopos：查询位置信息
geopos key member [member]
5.3geodist：距离统计
geodist key member1 member2 [unit]
unit 参数表示统计单位，它可以设置以下值：
m：以米为单位，默认单位；
km：以千米为单位；
mi：以英里为单位；
ft：以英尺为单位。
5.4georadius：查询某位置内的其他成员信息
georadius key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC]
WITHCOORD说明：返回满足条件位置的经纬度信息。
WITHDIST说明：返回满足条件位置与查询位置的直线距离。
WITHHASH说明：返回满足条件位置的哈希信息。
COUNT count说明：指定返回满足条件位置的个数。
ASC|DESC说明：从近到远|从远到近排序返回。
eg:georadius site 116.405419 39.913164 5 km withdist
查询并返回离116.405419 39.913164距离5km的地方的直线距离
127.0.0.1:6379> georadius site 116.405419 39.913164 5 km withdist
5.5geohash：查询位置的哈希值
geohash key member [member]
5.6zrem：删除地理位置
zrem key member [member]
