Redis
1.环境配置
## 检验是否具有GCC环境(c的运行环境)
已安装 gcc :no input files 未安装 yum install gcc-c++
## 安装redis后，使用小黑窗口进入redis，输入命令make prefix = /usr/local/myredis install 进行编译/usr/local/myredis--指定编译的路径。将redis.conf拷贝至此编译的目录下， 编译redis.conf 将daemonize no改为daemonize yes保存。启动：命令 ./redis-server redis.conf 连接命令 ./redis-cli -p 6379.
2.redis介绍
##.redis是单线程模式！ 是通过对epoll函数包装来做到的，实际处理速度完全依赖于主进程的执行效率.
##.默认有16个库 select dbsize flushall flushdb keys* set get incr2. redis-benchmark: 写每秒8W 读11W。
## 进入redis.conf可看见其中配置。
1）、units are case insensitive so 1GB 1Gb 1gbB are all the same---不区分大小写。 Include /path/to/local.conf ---可加载外部文件daemonize yes---改为后台程序
pidfile /var/run/redis.pid--改为后台程序pid的输出地址。port 6379--端口号
Timeout 0 --超时时间（单位是秒）。Tcp-keepalive 0 --保持活跃时间，单位是秒，如果设置成0就不会进行keep检查，建议设置成60
2）、tcp-backlog 511 其实是一个链接队列，backlog 队列综合= 未完成3次握手队列 +已经完成三次握手队列，在高并发环境下你需要一个搞backlog值来避免客户端链接问题
3）、SNAPSHOTTING快照中RDB持久策略（存储在dump.rdb中，可通过dbfilename:dump.rdb--修改名称）。
RDB ：在指定的时间间隔内将内存中的数据集快照写入磁盘， (在指定的时间内将内存中的数据写入磁盘，)也就是行话讲的Snapshot快照，它恢复时是将快照文件dump.rdb直接读到内存里 。
原理： Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
RDB的持久化策略分为主动和被动：
主动是Save：save时只管保存，其它不管，全部阻塞
BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间。
被动策略有3种：After 900 sec (15 min) if at least 1 key changed --如果900s内有一次有效操作（增删改），则触发保存
After 300 sec (5 min) if at least 10 key changed
After 60 sec if at least 10000 key changed
优势：适合大规模的数据恢复
劣势：在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改的数据（但运维可恢复）
4）、SECURITY安全校验
stop-writes-on-bgsave-error ：如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制。
rdbcompression 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum： 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
5）、LIMITS过期策略
maxclients :最大的客户端连接数 :默认是10000个
maxmemory :使用的最大内存,如果达到最大值会按照 maxmemory-policy 进行移除操作,默认不配置的话,进行操作会返回错误。
maxmemory-policy:redis rdb策略:
Volatile-lru:移除最近最少使用的key,默认设置了过期的
Allkeys-lru:.移除最近最少使用的key,
Volatile-random: 随机移除,默认设置了过期的
Allkeys-random:随机移除
Volatile-ttl:移除在规定时间内,更早的过期的key
Noeviction:当内存不足以容纳新写入数据时，新写入操作会报错
maxmemeory-samples：设置样本数量，LRU 算法和最小的TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小。默认是5个样本，可选3或10.
6）、AOF（ 保存在appendonly.aof）
## aof：以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
缺点：redis在高并发时写的指令很多，每条都会记录下来，aof文件会很大。
Redis并不智能（列入increase1=1--100-100，会记录100次增加操作）
## 在有rdb和aof时会加载aof文件。修复aof命令： redis - check-aof --fix appendonly.aof
## appendfsync 同步策略
always：同步持久化每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好
everysec：出厂默认推荐，异步操作，每秒记录. 如果一秒内宕机，有数据丢失以日志的形式来记录每个写操作（命令）
always： 记录写操作，通过io写入到磁盘
everysec :记录写操作，并不会立刻写入到磁盘(先存入到内存中--> 内存中中的这些命令写入到磁盘上)
重写原理 :AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
触发条件
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的两倍并and文件大于64M时触发
no-appendfsync-on-rewrite：重写时是否可以进行Appendfsync（持久化），用默认no即可，保证数据安全性。
7）、主从备份：也就是我们所说的主从复制，主机数据更新后根据配置和策略，
自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
## 一主二从的情况（配从机不配主机）
salveof 主机ip 主机端口号
1.查看当前主机状态 info replication master 主 slave 从
2.当配置成主从模式时，从机只能够读取，而不能够设置值 （读写分离）
3.从机断开，回来之后是全局更新（将所有的内容进行添加）。
注：增量更新-每次更新的内容是添加的内容。
4.当主机死亡之后，从机会原地待命 不会翻身做主，主机回来还是主机
##： 一个传一个 A-->B-->C
1.好处： 去中心化
2.弊端：可能出现数据的失真，中间断开，此时就不能交互数据
##： slaveof no one 反客为主(手动)
1.当主机断开之后，想让从机上位
slaveof no one -->从机会变成主机 ，但不会影响其他机器
## 哨兵模式(Sentinel):是Redis 的高可用性解决方案：由一个或多个Sentinel 实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，让从服务器进行投票选取出新主机。
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
启动命令 ./redis-sentinel sentinel.conf
8）、redis的事物：可以一次执行多个命令，本质是一组命令的集合。一个事务中的
所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞。
redis的事物是弱原子性、弱事物的， 关系型数据库强原子性。
启动事物：multi 回复OK ！ 有下列情况
case1：正常执行（exec）
case2 放弃事物 （ discard ）
case3 全体回滚（语法有错）--事务中的所有都不执行
case4 单步回滚（逻辑有错）--有错的那一步不执行
case5 ：watch监控（再打开事务将监控此事务，若不是最新的版本将提交失败）
unwatch 取消watch命令对所有key的监视，redis对事物的部分支持。
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
