redis 事务
    redis的事务是 基于队列实现事务的， 每个命令都加入到队列当中 运行exec 一起执行

    开启事务 multi
    添加命令 …. … 多个添加命令
    执行事务 exec
    取消事务 discard

    对于redis 的事务
    属于弱 事务
    对于语法错误会直接返回错误， 正确的命令也不会执行
    对于运行错误 正确的仍会正常执行，错误的不执行

    springBoot 开启事务方式
    修改RedisConfig配置类，开启事务控制
    redisTemplate.setEnableTransactionSupport(true)
    代码使用：
    redisTemplate.multi();
    try cach 方式
    catch：redisTemplate.discard();
    finally：redisTemplate.exec();

    redis持久化机制
    redis将数据是保存在内存中的 宕机或者关机容易丢失 所以rides提供了 持久化机制
    redis提供了两种持久化机制
    RDB 和 AOF
    根据不同的场景
    可以选择只使用其中一种或一起使用；
    RDB快照

    是redis默认的存储方式

    用快照方式，保存数据内容用二进制的方式到磁盘上， 文件后缀名.rdb

    触发条件
    时间 更改次数
    save 3600 1 一个小时 一个键被更改 就保存
    save 300 100 5分钟 100个键 被更改 进行快照保存
    save 60 10000 1分钟 10000个键 更改 进 行保存
    如果想 停用RDB 快照 可以 save “” 即可 【 冒号里面是个空】

    AOF

    存储的是 对redis操作的所有写的命令
    读的命令不做记录。

    需要手动开启： 修改配置文件 redis.conf

    是否开启 AOF 默认为no 改为yes
    appendonly yes
    #设置AOF文件名称
    appendfilename appendonly.aof

    开启AOF之后重启Redis redis/data 目录会产生一个 appendonly.aof文件
    保存的是操作的写的命令
    AOF实现整个过程分三个部分： 命令追 - -> 文件写入 - -> 文件同步
    收到写的命令保存到缓冲区末尾 - -> 写入aof文件 - -> 根据策略向磁盘同步

    三种同步策略;
    always： 每次写的命令 都保存到缓冲区文件都写入到AOF文件吧并同步到磁盘 特点： 最安全
    默认：everysec： 每次写命令都写到AOF文件 但是AOF不和磁盘同步 每1秒和磁盘同步一次 特点： 安全中等
    no：每次写命令都写到AOF文件 但是AOF不和磁盘同步 每30秒和磁盘同步一次 特点： 速度最快

    AOF和RDB优势和缺点对比：

    1.      1. RDB默认开启，AOF需手动开启。
    2.      1. RDB速度比AOF快。
    3.      1. AOF比RDB安全。
    4.      1. AOF优先级高于RDB。
    5.      1. RDB存储某个时刻的数据快照，AOF存储**写**命令。
    6.      1. RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，AOF默认使用everysec，每秒保存一次，最多丢失两秒以内的数据。

    生产环境下的实践:
    如果当前只追求高性能，不关注数据安全，则关闭RDB，和 AOF
    如果需要较高性能，又关注数据安全，则开启RDB，并定制触发条件规则
    如果更关注数据安全，则开启AOF

    高可用 主从复制
    原理：
    主节点只能写， 从节点只能读 主写从读
    从节点 开启持久化， 主节点关闭持久化
    主节点 master
    从节点 slaves
    在主从复制的结构下，无非要么主节点宕机，要么从节点宕机

    • 当从节点宕机重启后，主节点会自动的将数据同步到从节点上。所以不会出现数据丢失。
    • 当主节点宕机后，可以将从节点提升为主节点(slaveof no one)，继续对外提供服务。 并且当原先的主节点重启后，使用slaveof命令将其设置为新主节点的从节点，即可完成数据同步。

    主从复制的作用：

    • 读写分离：主写从读，提高服务器的读写负载能力
    • 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
    • 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
    • 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
    • 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

    高可用扩展
    哨兵模式：
    哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制**选择新的master并将所有slave连接到新的master
    哨兵也是一台服务器, 只是不提供数据服务。
    当哨兵监测到master宕机，会自动将slave切换成master，通过通知其他的从服务器，修改配置文件切换主机

    Sentinel三大工作任务

    监控 提醒 故障自动转移
    不断检查某Redis是否出现问题 当出现问题时候会通过api向 当主服务器不正常工作
    PING 命令检测 如果响应超时 管理员或者其应用程序发送通知 从从服务器中选择一个 升为主 服务器 并其他从服务器改为
    复制新的主服务器

    哨兵模解决了什么问题？：
    一主二从 三哨兵：

    • 主从集群间可以实现自动切换，可用性更高
    • 数据更大限度的防止丢失
    • 解决哨兵的集群高可用问题，减少误判率

    海量数据比较大的时候 5000w*512b=25GB 需要用到 分片集群 为了解决主节点宕机恢复时间长问题
    高可用扩-Redis Cluster分片集群
    3.0以后 支持分片集群

    Redis Cluster 方案：无中心化

    • 采用哈希槽（Hash Slot）来处理数据和实例之间的映射关系

    • 一个切片集群共有 16384 个哈希槽，只给Master分配

      1. - 具体的映射过程 
      2.    1. 根据键值对的 key，按照CRC16 算法计算一个 16 bit 的值；
      3.    1. 再用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽
      • 哈希槽映射到具体的 Redis 实例上
        • 用 cluster create 命令创建集群，Redis 会自动把这些槽平均分布在集群实例上
        • 也可以使用 cluster meet 命令手动建立实例间的连接，形成集群，再使用 cluster addslots 命令，指定每个实例上的哈希槽个数
          注意：需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作

    分片解决了什么问题；

    • 海量数据存储
    • 高可用
    • 高可扩

    高可用架构总结

    • 主从模式：读写分离，负载均衡，一个Master可以有多个Slaves
    • 哨兵sentinel：监控，自动转移，哨兵发现主服务器挂了后，就会从slave中重新选举一个主服务器
    • 分片集群： 为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，提高并发量。

    过期删除策略
    Redis中对于过期键的过期删除策略3种：

    • 定时删除

      该策略对内存友好 对cpu不友好 因为大多数都有过期时间 会有大量定时器工作 会拉低系统性能 不建议采用

    • 惰性删除

    用到的时候删除 用到的时候 再判断是否过期，如果过期则删除该key 会造成大量内存空间浪费 对内存不友好

    • 定期删除

    默认每秒20次随机扫描带时间的key 同时删除20个中已经过期的key 如果20个key 过期的key比例超过25% 则继续扫描

    内存淘汰策略
    数据驱逐策略

    • lru：Least Recently Used，它是以时间为基准，删除最近最久**未被使用的key。
    • lfu：Least Frequently Used，它是以频次为基准，删除最近最少未被使用的key。