RDP数据快照储存(丢失数据的概率比较高,很可能完成不了最后一次数据的存储)
AOF命令储存(AOF健壮性更强,有可读的日志文件可以处理操作,但是耗内存(尤其是持久化策略选择always的时候),也有重写AOF文件的设定可以压缩文件容量)
都是先存储到缓存这种再进行持久化储存
使用场景：如果数据相对不是很敏感,推荐使用RDP就可以,不要单独启用AOF（不适合备份，并且可能有bug）,如果只是做缓存要求的话可以两个都不使用;
--
主从结构（主服务器来写入操作，子服务器来读取，分散压力）
从服务器挂掉后重新启动会认为自己是主服务器,
此时重新slaverof会恢复为从服务器,并且恢复主服务器的所有数据
主服务器挂掉后从服务器会等待主服务器重新恢复（哨兵模式可以自动让其中一个子服务器变成主服务器继续运行）
--
哨兵模式:监视主机,如果主机挂了,从机会变成主机,主机恢复之后也只会成为从机
排序根据奴隶浓度等指标
---
集群:多个主从 结构的集合可以相互访问，就减少了服务器设置的压力
---
几个缓存问题
1.缓存穿透(炮弹)(被攻击,缓存命中率低,疯狂查询数据库不存在数据)
1.服务器压力变大2.缓存中数据不足够3.一直访问数据库,导致过载
2.错误的访问导致一直访问数据库出现问题
2.缓存击穿(针尖 )
1.某个key已经过期了,但是大量的访问这个key最终造成数据库压力变大
---
雪崩问题大量key同时过期,对数据库的过载访问
--
2.分布式锁
在一个操作没有完成的时候 加上了锁 其他操作需要等待
分布式锁所解决的问题:
在分布式集群中对单一分布上锁的时候其他机器并不知道已经上锁,因此利用分布式锁(共享锁)进行实现;利用setnx进行上锁,可以用del来释放锁,也可以利用expire time来设置过期时间(但是这非原子),因此可以利用set key value nx ex time方式来进行加锁与释放的操作.（在java中利用lua来进行原子操作）
:1.设置锁,
2.对其他数据进行访问操作
3.操作结束释放锁
4.(如果得到锁失败那么就沉睡下次再次尝试(递归))
但是这如果出现以下问题,在操作时错误的锁释放会导致问题;
利用uuid来作为锁的value值,
在释放锁的时候,先判断当前uuid与要释放锁的uuid是否相同,作为上述的2.5步骤
但是此时仍并不是原子性操作
利用lua进行原子性操作
