• NoSQL入门第四天——事务与主从复制


    一、Redis的事务

      1.是什么

        可以一次执行多个命令,本质是一组命令的集合。一个事务中的
        所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入,不许加塞

        (更多请参见官网事务介绍)

      2.能干什么

        一个队列中,一次性、顺序性、排他性的执行一系列命令

      3.怎么干

        摘取官网:

      常用如下:

        开启一个事务:(MULTI)

        添加若干命令加入队列,执行事务(EXEC)

        添加操作后不想执行,放弃事务(DISCARD)

        一个出错,全体受罚,连坐(一个出错,其它事务内操作均不成功)

        谁的命令加入队列时正常执行时报错,则冤头债主,只找它(这里k1的v1不是Integer不能增加)

      //和上一个的区别就是这个是加入队列时成功,执行时出错,而上一个加入队列时就出错了

      所以说,Redis对事务的支持,是部分支持

      watch监控

        悲观锁/乐观锁/CAS(Check And Set)

          悲观锁(会有点像行锁和表锁)

     悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁

          乐观锁(一般用乐观锁,还是乐观点好)

     乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号(在记录后加一个版本号,通过版本号来判断是否进行了修改)等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,

          CAS

      redis中使用 check-and-set 操作实现乐观锁

        模拟场景:模拟信用卡消费,可用额度:balance,当前欠款:debt

     

        无加塞篡改,先监控再开启multi,保证两笔金额变动在同一个事务内(如果监控的变量在其它事务地方发生了变化,将会报错)

        有加塞篡改,监控了key,如果key被修改了,后面一个事务的执行失效(以前一个事务执行结果为准)

        UNWATCH(WATCH之后的设值是模拟其它终端进行了修改,实际操作中可用通过boolean等变量来控制,当有人修改时,放弃监控,再获取最新的进行监控修改,直到没有人修改,再开始监控,开启事务)——此命令是取消监控所有key

        一旦执行了exec之前加的监控锁都会被取消掉了,不管成功失败,本次操作就清了(操作结束)

       小结:

       Watch指令,类似乐观锁,事务提交时,如果Key的值已被别的客户端改变,比如某个list已被别的客户端push/pop过了,整个事务队列都不会被执行。

       通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败

         4.事务三阶段

          开启:以MULTI开始一个事务

          入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面

          执行:由EXEC命令触发事务

        5.事务三特性

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

          没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在”事务内的查询要看到事务里的更新,在事务外查询不能看到”这个让人万分头痛的问题。

          不保证原子性:redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚

     二、Redis的发布和订阅

      1.是什么

        (兼职做一下发布,实际还是做分布式缓存的)

      进程间的一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。

      2.实例:

        先订阅后发布后才能收到消息,
          1 可以一次性订阅多个,SUBSCRIBE c1 c2 c3

          2 消息发布,PUBLISH c2 hello-redis
          ===========================================================================================================
          3 订阅多个,通配符*, PSUBSCRIBE new*
          4 收取消息, PUBLISH new1 redis2015

      左边发布,右边获取:

     三、主从复制

      1.是什么   

        行话:也就是我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主

      2.能干什么

        读写分离  容灾恢复

      3.怎么干

        配从(库)不配主(库)

        从库配置:slaveof 主库IP 主库端口

          每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件

          info replication

        开始实验

          拷贝多个redis.conf文件(用于模拟多台机器)

          开启daemonize yes

          pid文件名字

          指定端口

          log文件名字

          dump.rdb名字

        

        常用3招:其实已经是过时,后面将会由哨兵模式更先进的模式取代

          一主二仆

        开启3台机器模拟如下:

        启动情况如下:

        使用  INFO replication: 查看主/从复制信息(此时还是三台主机身份)

      使用  slaveof 192.168.1.1 6379进行主从复制:(后两台使用命令后变为从机)

     注意,此时从机是可以取得k1 k2 k3的(即使从机是从k4才开始开启备份),也就是说,从机一旦接管,便从头录到尾

     

       此时查看主机79信息:身份是主机,后跟着两个小弟(从机),再在从机中查看主从复制信息可以看到是slave(从机状态)

        假设三台机器都执行相同的命令,思考结果:

      //结果:只有主机可以正确执行,从机将会出错。也就是从机无法覆盖主机。

        假设主机挂了,思考此时从机是代替主机上位,还是原地待命(假设由你设计,哪种方案)

      //主机关机后,从机之前备份的数据是存在的(不然,备份意义何在呢)

      可以发现还是从机身份,不过连接状态为down

       此时再把主机开启,并且进行操作

       //可以发现是可以获取到最新的值的。(主机一旦正常,一切照旧)

        假设其中一台从机挂了,另外的从机是正常运作的,而主机当然不受影响:

        再把从机启动,发现身份信息翻身为主机了

        但是其它机器在80SHUTDOWN期间的操作,80的无从获取的;原因是前面说过的,只要从机断开连接(自己挂了),就要重新和主机连接

      不然就认为是一台独立的机器而不是从机(除非写进它的配置文件)

        当然了,只要它重新和主机连接,重新作为从机,是可以正常运作的(再增量备份一份,最新的k8也有了):

          薪火相传

            1.上一个Slave可以是下一个slave的Master,Slave同样可以接收其他slaves的连接和同步请求,

            那么该slave作为了链条中下一个的master,可以有效减轻master的写压力。

            2.中途变更转向:会清除之前的数据,重新建立拷贝最新的

            3.slaveof 新主库IP 新主库端口

          原先是80 81挂在79上,变更为81挂80,80依旧挂79

         此时查看79主从复制信息:其下只有一个直接从机

        在第一台主机上设值,可以看到直接和间接从机都能成功获取(薪火相传是OK的)

          查看80的主从复制信息:总体而言是一个slave,但它同时连接了一个slave(包工头还是打工的,但手下还管了人)

          反客为主

         SLAVEOF no one

        使当前数据库停止与其他数据库的同步,转成主数据库

      先将上一个实验中间接从机81改回来,使环境正常:

        假设主机挂了,我们不再像第一个实验一样,傻傻的等待主机苏醒,而是从从机中选出新主机上位:SLAVEOF no one(不再为奴)

        现在主机变更为80,现在81就不傻傻的等了,跟着新主机81混了。格局变更

        现在老主机再回来,不过目前80 81已经组成新的格局,老主机再次苏醒,可惜无法入局了:

        4.复制原理

      仔细区分思考、,是增量还是全量

      1.slave启动成功连接到master后会发送一个sync命令

      2.Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步

      3.全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。

      4.增量复制:Master继续将收集到的修改指令,依次发送给slave,完成同步

      5.但是只要是重新连接master,一次完全同步(全量复制)将被自动执行

       5.哨兵模式(sentinel)

      是什么

        反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

      怎么干

        调整结构,6379带着80、81

      开始实验之前,依旧恢复原始环境(80 81都跟着79走,可以在79查看是否环境正常)

        自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错

      

          配置哨兵,填写内容

            vim sentinel进行配置

             sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

           上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机

        

          启动哨兵

          redis-sentinel /myredis/sentinel.conf 

          上述目录依照各自的实际情况配置,可能目录不同

        

        

        此时主机出现故障,哨兵开始工作:

          选出主机,更换格局:

        倘若此时老的主机回来,哨兵模式下会有何变化:

        开始启动是master,经哨兵监控调剂,成为从机!

        上述实验为监控一个master,实际:一组sentinel能同时监控多个Master

        6.复制的缺点

        复制延时

    由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。

  • 相关阅读:
    linux安装mysql
    yum命令
    java启动jar包中的指定类
    linux系统配置参数修改
    iconfont阿里巴巴矢量图标库批量保存
    Python 使用Pandas读取Excel的学习笔记
    在Ubuntu18.04的Docker中安装Oracle镜像及简单使用
    Eclipse 安装PyDev开发Python及初步使用
    Python打包工具
    MacOS下打包Python应用
  • 原文地址:https://www.cnblogs.com/jiangbei/p/7359846.html
Copyright © 2020-2023  润新知