redis

1.info replication命令可以查看当前redis节点的情况
2.通过slaveof ip port可以实现让一个redis节点成为某一个redis节点的从节点
3.一主两从默认行为:
---从节点挂掉之后重启，节点将会变为主节点，必须使用slaveof命令重新使它变成原来redis主节点的从节点。变成从节点之后，主节点上的所有数据将会同步到恢复正常的从节点上，不会发生数据丢失。
---主节点挂掉之后，从节点不会篡位，依然承认他们原来的主节点，只不过显示主节点已经下线。主节点恢复之后重启，仍然是主节点，两个小弟依然在，数据会依照rdb文件里面的数据进行恢复
4.主从复制原理：总共来说分为两个阶段，全量复制和增量复制两个阶段。
---全量复制：从节点主动发起同步sync命令，主节点会启动后台存盘进程将数据保存rdb文件里面，同时收集到正在处理的写操作命令，将备份的rdb文件发送给从节点，从节点按照发送过来的rdb文件进行同步
---增量复制：由主节点发起，将增量同步到从节点之中
5.薪火相传：从节点可以作为另一个从节点的主节点，这样可以降低根主节点的同步数据压力，缺点就是一个从节点挂掉之后，它后面的从节点数据就无法同步
6.反客为主：在薪火相传的模式下，根主节点挂掉之后，可以使用命令slaveof no one将一个从节点上升为主节点，但是这种手动改变节点的方式不方便，可能故障发生在半夜两点，运维人员还在睡觉，可以使用哨兵模式来实现自动修改节点。
7.哨兵模式：编写sentinel.conf配置文件：

sentinel monitor mymaster 192.168.137.40 6379 1 ，最后一个数字一表示有一个哨兵认为主节点挂了之后就进行选举。
8.分布式锁--redist解决方案：
首先，简述一下为什么会出现分布式锁。锁的出现是为了对应多线程并发访问同一资源可能会出现问题而进行控制的一种方案。单机环境下是一台服务器，运行一个Java虚拟机，所以使用jdk内置的解决方案就可以实现，但是分布式环境下的跨jvm层面的，所以可以引入第三方的方案来解决。使用setnx ex 原子命令来实现（key固定，value不固定）。这是加锁步骤，紧接着就可以执行业务代码，紧接着手动删除key，代表释放锁资源。但是这样直接删除key释放锁资源存在问题。假设线程一获取锁之后执行业务代码，执行到一半，服务器卡顿，在卡顿的这段时间之内，你的锁已经过期（获取锁的时候设置了过期时间），然后线程二获得锁成功，然后她就执行业务代码，但是此时线程一又争抢到cpu资源，执行业务代码，删除锁资源（但是它的锁资源是自动过期释放的），这是线程一删除的就是线程二的锁资源，这就存在问题。所以应该保证各个线程只能删除自己加的锁资源，所以把value设置成自己线程内部生成的uuid即可，删除时需要判断redis里面存放的uuid和当前线程里面生成的uuid是否是同一个，如果是的话，就删除，如果不是的话，依据业务进行处理。但是是存在问题，判断uuid和删除锁不具有原子性，仍然可能导致删除别的线程的锁，所以可以使用lua脚本来实现。