Nosql-redis事务/消息订阅/发布/主从复制

版权声明：本文为博主原创文章，转载请说明出处。 https://blog.csdn.net/weixin_43549578/article/details/83961653

Redis事务：

• Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
•  Redis事务的主要作用就是串联多个命令防止别的命令插队

Multi、Exec、discard：

• 从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，至到输入Exec后，Redis会将之前的命令队列中的命令依次执行。
• 组队的过程中可以通过discard来放弃组队。

事务的错误处理：

• 组队中某个命令出现了报告错误，执行时整个的所有队列会都会被取消。

事务冲突的问题：
   如：

     两个请求 一个请求想给金额加20 一个请求想给金额加30

解决方式：

  1.悲观锁

  

2.乐观锁

说明：

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

       乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

WATCH key [key ...]：

• 在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

unwatch：

• 取消 WATCH 命令对所有 key 的监视。
• 如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。

事务特性：

• 单独的隔离操作

1. 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

• 没有隔离级别的概念

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

• 不保证原子性

1. Redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

消息订阅/发布：

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

 

按频道订阅：
      先订阅后发布，才能收到消息， 1 可以一次性订阅多个，SUBSCRIBE c1 c2 c3   2 消息发布，PUBLISH c2 hello-Redis

按规则订阅：

   1 订阅多个，通配符*， PSUBSCRIBE new* 2 收取消息， PUBLISH new1 Redis2015

事件通知：

    能够通过订阅功能，捕捉Redis的事件通知。

配置：修改redis.conf中的  notify-keyspace-events AKE：

#  K     Keyspace events, published with __keyspace@<db>__ prefix.
#  E     Keyevent events, published with __keyevent@<db>__ prefix.
#  g     Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
#  $     String commands
#  l     List commands
#  s     Set commands
#  h     Hash commands
#  z     Sorted set commands
#  x     Expired events (events generated every time a key expires)
#  e     Evicted events (events generated when a key is evicted for maxmemory)
#  A     Alias for g$lshzxe, so that the "AKE" string means all the events.

通过 psubscribe 订阅通知：

订阅端

操作端

Redis的主从复制：

   主从复制，就是主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

用处：

•  读写分离，性能扩展
• 容灾快速恢复

配从(服务器)不配主(服务器):

• 拷贝多个redis.conf文件
• 开启daemonize yes
• Pid文件名字
• 指定端口
• Log文件名字
• Dump.rdb名字
• Appendonly 关掉或者换名字

info replication:打印主从复制的相关信息

slaveof  <ip>  <port>  :成为某个实例的从服务器
模式：

• 一主二仆

• 薪火相传 

1. 上一个slave可以是下一个slave的Master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
2. 用 slaveof  <ip>  <port>
3. 中途变更转向:会清除之前的数据，重新建立拷贝最新的
4. 风险是一旦某个slave宕机，后面的slave都没法备份

• 反客为主  

1. 当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
2. 用 slaveof  no one  将从机变为主机。

• 复制原理

1. 每次从机联通后，都会给主机发送sync指令
2. 主机立刻进行存盘操作，发送RDB文件，给从机
3. 从机收到RDB文件后，进行全盘加载
4. 之后每次主机的写操作，都会立刻发送给从机，从机执行相同的命令

哨兵模式(sentinal)

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

配置哨兵：

1. 调整为一主二仆模式
2. 自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错
3. 在配置文件中填写内容：         sentinel  monitor  mymaster  127.0.0.1  6379  1
4. 其中mymaster为监控对象起的服务器名称， 1 为 至少有多少个哨兵同意迁移的数量。

启动哨兵：执行redis-sentinel  /myredis/sentinel.conf

故障恢复:

1. 从下线的主服务的所有从服务里面挑选一个从服务，将其转成主服务 选择条件依次为： 1、选择优先级靠前的 2、选择偏移量最大的 3、选择runid最小的从服务
2. 挑选出新的主服务之后，sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，复制新master
3. 当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的从

•     优先级在redis.conf中slave-priority 100
•     偏移量是指获得原主数据最多的
•     每个redis实例启动后都会随机生成一个40位的runid