redis认证，主从复制，aof，快照

2019独角兽企业重金招聘Python工程师标准>>>

redis> KEYS *
1. "visits:1:totals"
2. "users:jdoe"
3. "visits:2:totals"
4. "sets"
5. "visits:635:totals;"
6. "fuge"
7. "circle:jdoe:soccer"
8. "dat"
9. "circle:jdoe:family"
redis> keys v*
1. "visits:1:totals"
2. "visits:2:totals"
3. "visits:635:totals;"
edis> keys v?sits:635:totals
edis> keys v[is]*
场景四oAuth
客户访问客户端的网站，想操作自己放在服务提供方的资源
客户端向提供方请求一个令牌
服务提供方验证客户端身份后授予一个临时令牌
客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求
用户授权，在这个过程中将零时令牌和客户端的回调连接
发送给服务提供方
用户在服务提供方的页面输入用户名和密码，然后授权该客户端访问的请求资源
授权成功后，服务提供方引导用户返回客户端的网页
客户端根据零时令牌和用户授权情况授予客户端访问令牌
客户端使用获取的访问令牌访问存放在服务提供方上的受保护资源
数据模型设计
consumer keys
consumer secrets
request tokens
request tokens
access tokesns
nonces
用redis做全文索引，反向检索
nosql05a,05b
关于购物篮的分析

REDIS持久化
快照
AOF（apend only file）
[root@localhost redis-2.0.4]# ./redis-cli shutdown
[root@localhost redis-2.0.4]# cat dump.rdb
REDIS0001? sets fuga 2 hoga 1
redis> save
OK
redis> config get *
1. "dbfilename"
2. "dump.rdb"
3. "requirepass"
4. (nil)

5. "masterauth"
6. (nil)

7. "maxmemory"
8. "0"
9. "timeout"
10. "300"
11. "appendonly"
12. "no"
13. "appendfsync"
14. "everysec"
15. "save"
16. "900 1 300 10 60 10000"
快照原理
当save的时候 将当前进程fork另一个子进程，在子文件中循环所有的数据，将数据写成rdb
redis的rdb文件不会坏掉，因为其写操作是在新进程中进行的，当生成一个新的rdb文件时，redis会将生成的
子进程写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为rdb,这样，在任何时候出现故障
redis文件都可用
同时，redis的rdb文件也是redis主从同步内部实现的主要一环
我们可以看到，rdb有他明显的不足，就是一旦数据库出现问题
我们的rdb文件中保存的数据不是全新的，从上次rdb文件生成的到停机键的
数据全部丢掉了，在某些业务下，这时可以忍受的，我们也推荐这些业务使用rdb的方式
进行持久化，因为rdb的代价并不高
[root@localhost redis-2.0.4]# vi /etc/redis.conf
appendonly yes
[root@localhost ~]# redis-server /etc/redis.conf
calhost redis-2.0.4]# ./redis-cli shutdown
[root@localhost redis-2.0.4]# redis-server /etc/redis.conf
calhost redis-2.0.4]# ./redis-cli  
[root@localhost redis-2.0.4]# ls a*
adlist.c  ae.c        ae_kqueue.c  anet.c  appendonly.aof

redis> keys *
(empty list or set)
aof优先 rdb
rdb性能优于aof，因为里面没有重复
redis一次性数据加到内存中，一次性预热
AOF rewrite
重新生成一份AOF文件，新的aof 文件中一条记录的操作只会有一次
而不像一份老的文件那样，可能记录了对同一个值得多次操作，其生成过程和
rdb相似，也是fork一个进程，直接便利数据，写入到临时的文件中在下如
新文件的过程中，所有的写炒作还是会写到原来的aof文件中，同时会记录在内存缓冲区中
当炒作完成后，会将缓冲区一次性的写入到临时文件中，然后通过rename命令用新的aof文件取代老的aofwenjian
redis> config get *aof*
vm在为代开vm的情况下，redis数据全部装入内存,受限内存大小，打开vm后，redis将
全部key放入内存，热value也放入内存，冷value放在磁盘
vm-enabled no
设置访问口令
requirepass 密码
当sed 的时候会出现opreation not permitted
这时你就要auth 密码
主从复制
masterauth里面要配置master配置的密码
常见性能问题：写快照阻塞
写内存快照，save命令调度rdbsave函数，会阻塞主线程的工作，当快照比较大时对性能的影响
非常大的，会间断性暂停服务
采用主从复制，master不写快照，slave去写
使用bgsave
常见性能问题：aof引发的问题
aof 持续写入，产生的阻塞可能性比较小
aof重写对性能影响很大，会引发服务暂停，但不重写，aof太大，影响启动装载速度
将no-appendfsync-on-rewrite的配置为yes可以缓解这个问题，设置为yes表示rewrite期间对新写的操作不
fsync，暂时存在内存中，等rewrite完成后再写入，不开启master的aof备份功能
常见问题：主从复制阻塞
redis主从复制性能问题，第一次slave向master同步的实现是：slave向master发出同步请求
master先dump出rdb文件，然后将rdb文件全量传输给slave，然后master把缓存的命令转发给slave，初次
同步完成，第二次以及以后的同步实现是mastewr将变量的快照直接实时的依次发送给slave，不管什么原因
导致slave和master断开都会重复以上的过程，redis的主从复制建立在内存快照的持久化基础上
只要有slave一定会有内存快照产生，虽然redis无主从复制阻塞，但由于io限制，如果master比较大，那么dump会耗费非常大的时间，
如果这个过程中master无法响应请求，服务就会中断

转载于:https://my.oschina.net/goudingcheng/blog/608058