redis-cli -h 指定ip -p 指定端口 -a 指定密码
1、哨兵配置
https://blog.csdn.net/yaooch/article/details/80167571
2、redis持久化之AOF(Append Only File)及其总结
https://blog.csdn.net/kfengqingyangk/article/details/53454309
3、
redis提供了两种持久化机制，rdb和aof。
关于aof的原理，类似于预写日志，不再解释。其中几个选项如下：
appendfsync always：总是写入aof文件，并完成磁盘同步 appendfsync everysec：每一秒写入aof文件，并完成磁盘同步
appendfsync no：写入aof文件，不等待磁盘同步。
可见，从持久化角度讲，always是最安全的。从效率上讲，no是最快的。而redis默认设置进行了折中，选择了everysec。合情合理。
bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。
现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。
因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。
https://www.cnblogs.com/ExMan/p/10233529.html
4\参数详解
https://www.cnblogs.com/zhoujinyi/p/5565647.html
https://lixiaohui.iteye.com/blog/2315516
5、Sentinel连接
https://www.cnblogs.com/Xrinehart/p/3502198.html
