Redis深度历险记(二)管理
文章目录
- RESP
- 持久化
- rdb
- aof
- 重写
- fsync
- 备份
- 内存优化
- 32bit vs 64bit
- ziplist intset
- 内存回收
- info
- 安全
- 指令黑名单
- 密码
- Lua
- SSL
RESP
Redis Serialization Protocol
Redis协议将传输的结构分为5种最小单元类型,单元结束时同一加上回车换行符号\r\n
- 单行字符串以"+"符号开头
- 多行字符串以"$"符号开头,后跟字符串长度
- 整数值以":"符号开头,后跟整数的字符串形式
- 错误消息以"-"符号开头
- 数组以"*"号开头,后跟数组的长度
+hello world\r\n
$11\r\nhello world\r\n
:1024\r\n
-WRONGTYPE Oper.....\r\n
*3\r\n:1\r\n:2\r\n:3\r\n
注意多行和数组的\r\n
下面是NULL
$-1\r\n
下面是空字符串,视为多行字符
$0\r\n\r\n
一般来说,多行字符串在client显示的时候会被用引号括起来
持久化
rdb
Redis在持久化时会调用glibc的函数fork产生一个子进程,快照持久化完全交给子进程处理,父进程继续处理客户端请求.
这个时候会使用操作系统的CopyOnWrite机制来进行数据段页面的分离…当父进程对其中一个页面的数据进行修改时,会被共享的页面复制一份分离出来,然后对这个复制的页面进行修改.这时子进程相应的页面是没有变化的,还是进程产生时那一瞬间的数据.
可以看出,在执行了快照后,后续指令是不会影响快照的.
aof
Redis和hbase等对日志的处理不同的一点是,Redis是先处理逻辑,再写日志.
重写
bg rewrite aof
Redis提供了bgrewriteaof指令对于aof日志进行瘦身,其原理就是开辟一个子进程对内存进行遍历,转换成一些列Redis的操作指令,序列化到一个新的AOF日志文件中…
可以看出来重写其实是舍弃了原先的日志
fsync
默认情况下Redis每秒调用fsync来将内存数据写入磁盘,另外还提供了两种策略,让OS决定和每条指令执行.
备份
一般让从节点做备份工作,压力小(缺点是网络分区时存在丢失数据的可能)
内存优化
32bit vs 64bit
如同其他32bit程序一样,32bit的redis的指针占用更少空间,但是最大内存不能超过4G
ziplist intset
这是两种存储少量数据时候的数据类型,可以使用object encoding key来查看当前的key是使用了什么数据结构,如果不满足优化条件,那么就会升级为标准结构hashtable
内存回收
由于OS是按页回收内存,所以一个页上只要有key存在,就不会回收,相当于java垃圾回收中的引用计数(虽然计数都是1),如果使用flushdb则可以回收,相当于移动压缩
redis使用第三方的jemalloc和tcmalloc来处理内存分配,client可以使用info memory指令来查看
info
info指令大致可以获取以下内容
- server
- client
- memory
- persistence
- stats
- replication
- cpu
- cluster
- keyspace
安全
指令黑名单
Redis在配置文件中提供了rename-command指令用于将某些危险的指令修改成特别的名字…比如在配置文件的security块中增加以下内容
rename-command keys asdf
修改后原指令会失效,如果想禁用该指定可以使用下面设置为空字符串的语法
rename-command flushall ""
密码
如果master设置了密码,从节点也需要设置从而能连上主节点
- 主节点
requirepass mima
- 从节点
masterauth mima
Lua
为了防止lua脚本,不要用root启动redis
SSL
使用spiped