redis初学者你有福了—带你进入Redis不一样的世界( 十 )


rename-command CONFIG ""
但需要注意的是 , 如果你使用AOF方式进行数据持久化 , 或者需要与从redis进行通信 , 那么更改指令的名字可能会引起一些问题 。
 
【教你看懂redis配置 -限制】
我们可以设置redis同时可以与多少个客户端进行连接 。默认情况下为10000个客户端 。当你无法设置进程文件句柄限制时 , redis会设置为当前的文件句柄限制值减去32 , 因为redis会为自身内部处理逻辑留一些句柄出来 。
如果达到了此限制 , redis则会拒绝新的连接请求 , 并且向这些连接请求方发出“max number of clients reached”以作回应 。
maxclients 10000
我们甚至可以设置redis可以使用的内存量 。一旦到达内存使用上限 , redis将会试图移除内部数据 , 移除规则可以通过maxmemory-policy来指定 。
 
如果redis无法根据移除规则来移除内存中的数据 , 或者我们设置了“不允许移除” , 那么redis则会针对那些需要申请内存的指令返回错误信息 , 比如SET、LPUSH等 。但是对于无内存申请的指令 , 仍然会正常响应 , 比如GET等 。
maxmemory <bytes>
需要注意的一点是 , 如果你的redis是主redis(说明你的redis有从redis) , 那么在设置内存使用上限时 , 需要在系统中留出一些内存空间给同步队列缓存 , 只有在你设置的是“不移除”的情况下 , 才不用考虑这个因素 。
 
对于内存移除规则来说 , redis提供了多达6种的移除规则 。他们是:
1.volatile-lru:使用LRU算法移除过期集合中的key
2.allkeys-lru:使用LRU算法移除key
3.volatile-random:在过期集合中移除随机的key
4.allkeys-random:移除随机的key
5.volatile-ttl:移除那些TTL值最小的key , 即那些最近才过期的key 。
6.noeviction:不进行移除 。针对写操作 , 只是返回错误信息 。
无论使用上述哪一种移除规则 , 如果没有合适的key可以移除的话 , redis都会针对写请求返回错误信息 。
maxmemory-policy volatile-lru
LRU算法和最小TTL算法都并非是精确的算法 , 而是估算值 。所以你可以设置样本的大小 。假如redis默认会检查三个key并选择其中LRU的那个 , 那么你可以改变这个key样本的数量 。
maxmemory-samples 3
最后 , 我们补充一个信息 , 那就是到目前版本(2.8.4)为止 , redis支持的写指令包括了如下这些:
set setnx setex append
 
incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
 
sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
 
zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
 
getset mset msetnx exec sort
【教你看懂redis配置 – 追加模式】
默认情况下 , redis会异步的将数据持久化到磁盘 。这种模式在大部分应用程序中已被验证是很有效的 , 但是在一些问题发生时 , 比如断电 , 则这种机制可能会导致数分钟的写请求丢失 。
如博文上半部分中介绍的 , 追加文件(Append Only File)是一种更好的保持数据一致性的方式 。即使当服务器断电时 , 也仅会有1秒钟的写请求丢失 , 当redis进程出现问题且操作系统运行正常时 , 甚至只会丢失一条写请求 。
我们建议大家 , AOF机制和RDB机制可以同时使用 , 不会有任何冲突 。对于如何保持数据一致性的讨论 , 请参见本文 。
appendonly no
我们还可以设置aof文件的名称:
appendfilename "appendonly.aof"
fsync()调用 , 用来告诉操作系统立即将缓存的指令写入磁盘 。一些操作系统会“立即”进行 , 而另外一些操作系统则会“尽快”进行 。
redis支持三种不同的模式:
1.no:不调用fsync() 。而是让操作系统自行决定sync的时间 。这种模式下 , redis的性能会最快 。
2.always:在每次写请求后都调用fsync() 。这种模式下 , redis会相对较慢 , 但数据最安全 。


推荐阅读