文件开头 gg
文件末尾G
N 下一行
复制 yy
粘贴 p
https://www.cnblogs.com/baizhanshi/p/6419268.html
1.检验是否具有GCC环境(c的运行环境)
已安装 gcc :no input files
未安装 yum install gcc-c++
2.redis-benchmark
官网介绍 写 每秒8W 读11W
安装命令
make prefix = /usr/local/myredis install
3.redis介绍
1.（了解）redis是单线程模式！ 是通过对epoll函数包装来做到的，实际处理速度完全依赖于主进程的执行效率
2.默认有16个库
select dbsize flushall flushdb keys* set get incr
3.单位
4. general
1）、pidfile /var/run/redis.pid
2）、port 6379
3）、tcp-backlog 511 其实是一个链接队列，backlog 队列综合= 未完成3次握手队列 +已经完成三次握手队列
在高并发环境下你需要一个搞backlog值来避免客户端链接问题
4）、timeout 空闲N秒后关闭，0的话就避免关闭
5）。tcp-keepalive 单位是秒，如果设置成0就不会进行keep检查，建议设置成60
6）、安全（略）
7）、limit
maxclients :最大的客户端连接数 :默认是10000个
maxmemory :使用的最大内存,如果达到最大值会按照 maxmemory-policy 进行移除操作,默认不配置的话,进行操作会返回错误
maxmemory-policy:redis rdb策略:
maxmemory-policy:
volatile --> 设置了过期时间的
1. volatile -lru ：
allkeys-lru :
lru : 最近最少使用
volatile ：设置了过期时间的key
allkeys : 所有的key
2. volatile-random
allkeys-random
random： 随机移除
volatile ：设置了过期时间的key
allkeys : 所有的key
3.volatile-ttl ： 移除规定时间内更早过期的那个key
maxmemeory-samples：
设置样本数量，LRU 算法和最小的TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小
redis会检查这么多个key兵选择其中LRU的那个
8）、redis的持久化策略
AOF + RDB
RDB ：什么是RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘， (在指定的时间内将内存中的数据写入磁盘，)
也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里 （恢复时是将dump.rdb文件读取到内存中)
原理：（必须记住）
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
RDB:
Redis会重新fork出一条子进程，这条子进程和主进程一模一样，
因为cpu里面读和写的操作很慢,所以说fork出一条子进程，让它来进行读和写操作，
当持久化操作完成之后，它就会将fork出来的子进程中的文件去替换原来进程中的那个配置文件，
整个过程中，主进程不进行任何IO操作，这就确保了极高的性能，RDB适合进行大规模数据的恢复，
因为它有一个缺点，就是最后一次持久化后的数据可能会丢失
RDB的持久化策略分为主动和被动，主动是Save和BGsave,save是全阻塞，BGsave是异步操作，
被动策略有3种，默认情况为900s触发1次，300s触发10次,60s触发1万次
fork：
主动
Save：save时只管保存，其它不管，全部阻塞
BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
flush操作
shutdown 操作
被动
save ""
可选
stop-writes-on-bgsave-error ：如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制
rdbcompression 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用
LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum： 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约
10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
dbfilename:dump.rdb
总结：
优势
适合大规模的数据恢复
劣势
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
AOF
appendonly.aof
select 库
1）、aof是什么
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2）、
2.2如果两者都有 走的aof，那么采用哪个策略（修复） ：./redis-check-aof --fix appendonly.aof
3）配置文件
appendfsync 同步策略
always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
everysec：出厂默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失
以日志的形式来记录每个写操作 （命令）
always： 记录写操作，通过io写入到磁盘
everysec :记录写操作，并不会立刻写入到磁盘(先存入到内存中) --> 内存中中的这些命令写入到磁盘上
no
重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，
遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
触发条件
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍并and文件大于64M时触发
no-appendfsync-on-rewrite：重写时是否可以进行Appendfsync（持久化），用默认no即可，保证数据安全性。
aof文件重写的条件
auto-aof-rewrite-min-size： 64M
auto-aof-rewrite-percentage：是原来的2倍时
重写aof文件 ，放置aof文件过大
伪
主从备份
也就是我们所说的主从复制，主机数据更新后根据配置和策略，
自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
一： 一主二从的情况
配从机不配主机
salveof 主机ip 主机端口号
1.查看当前主机状态 info replication master 主 slave 从
2.当配置成主从模式时，从机只能够读取，而不能够设置值 （读写分离）
3.从机断开，回来之后是全局更新 shutdown redis-server ./redis-cli 脱离组织的主机 哨兵
增量更新：每次更新的内容是添加的内容
全局更新：将所有的内容进行添加
4.当主机死亡之后，从机会原地待命 不会翻身做主，主机回来还是主机
二：薪火相传 一个传一个 A–>B–>C
1.好处： 去中心化
2.弊端：可能出现数据的失真
中间断开，此时就不能交互数据
三： slaveof no one 反客为主(手动)
1.当主机断开之后，想让从机上位
slaveof no one -->从机会变成主机 ，但不会影响其他机器
四：哨兵模式
五：redis的事物
六：redis的集群配置(项目二会讲)
1.配从不配主
2.从库备份：slaveof 主库 ip 主库端口
3修改的内容：pid 端口 日志 dump文件
4.先设置值，再连从库-->从是否能拿到 全备份
1 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制
2 从机是否可以写？set可否？
3 主机shutdown后情况如何？从机是上位还是原地待命
4 主机又回来了后，主机新增记录，从机还能否顺利复制？
5 其中一台从机down后情况如何？依照原有它能跟上大部队吗？
9,传递（去中心话） 失真
原子性
要么都成功， 要么都失败
弱原子性
哨兵： （sentinel）
进行投票选取出新主机
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
redis的事物
可以一次执行多个命令，本质是一组命令的集合。一个事务中的
所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞
exec
set k1 v1
set k2 v2
redis的事物是弱原子性 弱事物的
关系型数据库强原子性
打开事物：
multi 回复OK ！
discard 放弃本次操作
case1 正常执行
case2 放弃事物
case3 全体连坐
case4 冤头债主
case5 ：watch监控
常用命令
开启事物
multi
取消事物
discard
执行事物
exec
unwatch
取消watch命令对所有key的监视
watch
监视一个或多个key，如果执行事物之前被其他key修改，那么事物会被打断 不能
如果没有监视这个key，那么在事物中这个key被其他操作修改后，能成功吗？ 能
redis对事物的支持是部分支持
100
初始化信用卡可用余额和欠额
余额banlance 100
无加塞 操作数据
加塞
incrby
decrby
单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，
也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
QkCf9R3XvNCBmvphw9GhlDwcAhUwxRgw
扫一扫
548
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
