Redis事务+持久化+主从复制+Redis集群

Redis事务

  • Redis事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。

    • Redis事务的主要作用就是串联多个命令防止别的命令插队。

  • Redis事务中的三个命令

    • Multi   、Exec 、 discard

      • Multi 相当于攒SQL  命令队列 不会执行

      • Exec会依次执行 命令队列中的命令

      • discard 放弃攒SQL 命令

    • 错误处理

      • flushdb 清空当前库

    • multi 攒命令

      • 一步错  步步错  执行时被取消

      • 执行阶段错误

          • 只有执行错误的不执行

      • Redis就是利用check-and-set机制实现事务的。

        • 上锁  监视 可以监视一个或多个Key

        • 版本不同,更新过 就会打断事务

      • 事务的特性

        • 隔离级别

        • 读未提交 不可避免脏读

        • 读已提交    不可避免重复读和幻读  orcle默认

        • 可重复读  不可避免幻读     Mysql 默认 

        • 序列化      全部避免  

  • Redis的持久化

    • 再谈Redis和MemeCache的区别

      • Redis支持持久化   MemCache 不支持

      • MemCache 只支持简单的key-value     Redis除了简单的key-value之外还有五大数据类型

      • MemCache 是多线程加锁的形式  Redis是单线程+多路IO复用

    • 两种持久化方式

      • RDB

        • flushdb后 dump.rdb文件会变小

        • 在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照,它恢复时是将快照文件直接读到内存里。

        • 备份是如何执行的

          • 缺点 :最后一次持久化后的数据可能丢失

          • rdb 文件默认存储在启动redis的目录中

        • 手动指定 rdb 文件存储的位置 

        • 默认shutdown时会持久化 一次  bgsave 手动持久化

          • bgsave  :background  手动后台保存

          • 改成  save 60 10

          • 备份

          • 一分钟内存10个key观察 到 rdb自动保存快照

            • 问题: 在输入十个后就会持久化, 但是后续输入的key有可能不被持久化到

        • 其他配置

        • RDB方式的特点

      • AOF

        • AOF和RDB同时开启,Redis听AOF的

          • 即按AOF文件进行恢复

        • redis-check-aof  --fix   appendonly.aof  可以修复aof文件

        • bgrewriteaof :重写可以把多句重复命令合并在一起

  • Redis主从复制

    • 就是主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制

      • 主机主要负责写,从机主要负责读

      • 主要用途:

        • 读写分离,性能扩展

        • 容灾快速回复

    • 配置过程

      • 示例:

        • 关掉appendaof no

        • 创建原始redis配置备份  redis6379.conf

        • 将redis6379.conf复制几份

          • cp redis6379.conf redis6380.conf

        • %s/6379/6380整体替换

    • 命令

      • info replication (主从复制)

        • 打印主从复制的相关信息

      • slaveof <ip> <port>    拜师

        • 成为某个实例的从服务器   

                      • ctrl +l =clear

      •     在其他两台slaveof 127.0.0.1 6379

        • 从机显示

        • 主机显示

      • 主机set的key 从机会保存, 从机无法set

      • 问题:

        • 主机宕机时,从机如何操作

        • 主机从宕机状态恢复时,从机如何操作

    • 主机宕机时,从机如何操作

      • 默认情况下,主机宕机,从机不上位,主机恢复时仍然是主机;若从机宕机,恢复时,从机不再是从机

      • 1.从头开始复制

      • 2.从机不可以写,只可以读get

      • 3.从机原地待命

      • 4.主机恢复后,从机仍可顺利复制

      • 5.从机恢复后,不再是该主的从机,变成初始状态

        • 从机可以继续收从机

    • 主机宕机时顶替主机

      • 在从机的redis.conf文件中,加入    

        • slave-priority 100

    • 哨兵模式

        • 如果之前宕机的主重新上线,会成为当前主机的从机

  • 测试

    • 一主二仆

      • 当配置了哨兵之后,主机宕机会寻找slave-priority 优先级最高的人作为新的主机

      • 当宕机的主机重新连接后,变为新主机的从机

    • Redis 集群

      • 为什么要集群?

        • 容量不够,redis如何进行扩容?

        • 并发读写操作,redis如何分摊?

      • 分布式和集群的区别

        • 分布式是把数据存放在多个机器上,每个机器放不一样的内容

        • 集群是在多个机器上把数据平均分成n份,机器上可能有不一样的内容

    • 搭建集群

      • 安装ruby环境

    • 准备6个实例,6379/6380/6381/6389/6390/6391

      • cluster-enabled yes

      • cluster-config-file node-6379.conf

      • cluster-node-timeout 15000

    • 去中心化 模式的集群 

      •  

      • 将6个合体

        • 192.168.9.35:6389  192.168.9.35:6390 192.168.9.35:6391

        •  

          • redis-cli -c -p 6379   (-c   cluster)

          • 自动带到机器上

        • 一个slot  可以放多个键值对 ,类似于拉链法使用CRC计算

        • JedisCluster 

          Set<redis.clients.jedis.HostAndPort> set=new  HashSet<redis.clients.jedis.HostAndPort>();

          redis.clients.jedis.HostAndPort e=new  redis.clients.jedis.HostAndPort("192.168.9.35", 6379);

          set.add(e);

          JedisCluster jCluster=new JedisCluster(set);

          jCluster.set("k2", "v2");

          System.out.println(jCluster.get("k2"));

          

    

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值