Redis的事务

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

  • 能干什么？
    – 一个队列中，一次性，顺序性，排他性的执行一系列命令

  • 怎么玩？
    – 常用命令：
    1.DISCARD：取消事务，放弃执行事务块内的所有命令
    2.EXEC：执行所有事务块内的命令
    3.MULTI：标记一个事务块的开始
    4.UNWATCH取消WATCH命令对所有key的监控
    5.WATCH key [key…]：监视一个（或多个）key，如果在事务执行之前这个（或这些）key被其他命令所改动，那么事务将被打断
    – 正常执行

    – 放弃事务

    –全体连坐（有点想mysql中的原子性，要么一次成功，要么失败）

    –冤头债主（谁有错找谁，其他的放行）

–watch监控（类似于乐观锁）

1.悲观锁/乐观锁/CAS(Check And Set)
– 乐观锁：
乐观锁（Optimistic Lock），顾名思义，就是跟乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。
乐观锁策略：提交版本必须大于记录当前版本才能执行更新。
– 悲观锁：
悲观锁（Pessimistic Lock），顾名思义，就是悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在做操作之前先上锁。
– CAS:

  • 事务的3阶段
    – 开启：以MULTI开始一个事务
    – 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
    – 执行 ：有EXEC命令触发事务

消息订阅发布简介

  • 是什么？
    – 进程间的一种信息通信模式：发送者(pub)发送信息，订阅者(sub)接收信息。

  • 命令
    – PSUBSCRIBE pattern [pattern…] 订阅一个或多个符合给定模式的频道
    –PUBSUB subcommand [argument [argument…]]查看订阅与发布系统状态
    –PUBLISH chnnel message 将消息发送到指定的频道
    –PUNSUBSCRIBE [pattern [pattern…]] 退订所有给定模式的频道
    – SUBSCRIBE channel [channel…] 订阅给定的一个或多个频道的信息
    –UNSUBCRIBE [channel [channel…]] 指退订给定的频道

  • 案例
    –
    –

复制机制(Master/Slave)

  • 是什么？
    – 也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

– 作用：
1.读写分离
2.容灾恢复

– 使用：
1.配从（库）不配主（库）
2.从库配置：slaveof主库IP主库端口
– 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
–Info replication（查看当前状态）
3.修改配置文件细节操作
– 拷贝多个redis.conf文件
–开启daemonize yes
–Pid文件名字
–指定端口
–Log文件名字
–Dump.rdb名字
4.常用3招
->一主三仆
–Init
–一个Master两个Slave
–日志查看
->薪火相传
–上一个Slave可以是下一个slave的Maset，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为l链条中下一个master可以有效减轻master的写压力
–中途变更转向：会清除之前的数据，重新建立拷贝最新的
–Slaveof新主库IP新主库端口
->反客为主
– SLAVEOF no one 是当前数据库停止与其他数据库的同步，转成主数据库

  • 复制原理
    –Slave启动成功连接到master后会发送一个sync命令
    –Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步。
    – 全量复制：而salve服务在接收到数据库文件数据后，将其存盘并加载到内存中
    – 增量复制：Master继续将新的所有收集到的修改命令依次传递给slave，完成同步。
    – 但是只要是重新连接master，一次完全同步（全量复制）被将自动执行

  • 哨兵模式（sentinel）
    – 是什么？
    反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主控
    – 使用

    1. 自定义的/myredis目录下新建sentinel.conf文件，名字绝对不能错（哨兵配置文件）
    2. 配置哨兵，填写内容
      – setimel monitor 被监控数据库名字 127.0.0.1 6379 1
      –上面最后一个数字1，表示主机挂掉后salve投票看让谁接替称为主机，得票数多少后成为主机

– 一组sentinel能同时监控多个Master

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