Redis 预研分册.docx

1. 概述1.1 简介Redis（远程字典服务）是一个开源的key-value存储系统，采用C语言编写，支持网络交互。为了取得突出的性能，Redis数据集在内存中工作。如果想持久化保存数据可以时常转储数据集到磁盘上，或者添加每一条命令到日志。Redis支持主从同步，数据可以从主服务器向任意数量的从服务器上同步。第一次同步的时候是非阻塞的并且非常快，网络断开的时候自动重连接。其他的功能包括简单的check-and-set机制，pub/sub和配置设置让Redis看起来像一cache。从2010年起，Redis的开发工作由VMware主持。1.2 数据类型1.2.1 Redis的keyRedis是Remote Dictionary Server（远程字典服务器）的缩写，它以字典结构存储数据，并允许其他应用通过TCP/IP协议读写字典中的内容。同大多数脚本语言中的字典一样，Redis字典中的键值除了可以是字符串，还可以是其他数据类型。Redis的key是字符串类型，由于key不是binary safe的字符串，所以像”my key”和”mykeyn”这样包含空格和换行的key是不允许的。Redis的key是唯一的。key不要太长，尽量不要超过1024字节，不仅消耗内存，而且降低查询效率。key不要太短，太短的话，key可读性差。统一key命名方式，例如user:10000:passwd。1.2.2 Redis的valueRedis支持的键值value数据类型有五种，如下：l 字符串类型string。l 字符串列表list。l 字符串集合set。l 有序字符串集合sorted set。l 哈希。1.3 适用场景优点：1、 开源，免费。2、 性能高。3、 为一些个性化问题提供了相关的解决方案，例如索引引擎、统计排名、消息队列服务等。4、 和其他NoSQL产品相比，Redis易用性高。缺点：1、 事务支持差。（1） 不支持回滚。（2） 一致性差，如一个事务修改字段，在没执行EXEC前，其他进程可以读取旧的数据并修改，现在的关系型数据库是，在一个事务中修改了某个字段，其他进程就不能读（除非脏读）或修改该字段，要等这个事务提交了才行。（3） 错误处理，一个事务中，其中一个或多个命令运行时失败，其他命令仍然会执行。2、 Redis是单线程服务器，不能从多CPU中获益。3、 集群功能在以后版本中提供。4、 Publication/Subscription功能中，如果master宕机，slave无法自动提升为master。与关系型数据库比较：1、 相比于关系型数据库，由于Redis存储结构简单，因此并不能对复杂的逻辑关系提供很好的支持，然而在适用于Redis的场景中，由此可获得效率上显著提升。2、 Redis在同一连接中可以选择打开不同的数据库，数据库通过数字命名，缺省打开数据库0，如果程序运行中打算切换数据库，可以使用Redis的select命令，例如select 1，如果此后再想切换回缺省数据库，只要执行select 0即可。3、 Redis遵循NoSQL数据库的主流思想，key作为数据检索的唯一标识，等同于关系型数据库的索引键，查询条件只能基于key。value作为数据存储的主要对象，value被视为二进制字节流，用于存储任何格式的数据，例如Json、XML、序列化对象的字节流等。适用场景：Redis常被用来作为数据库缓存，或者构建消息系统和队列系统。使用Redis的公司主要有Blizzard、digg、stackoverflow、github、flickr等。因为Redis的数据集不会超过系统可用的内存，所以如果为大数据量，而且主要是读取模式，Redis并不适合。1.4 软件安装1.4.1 RedisRedis安装：$ wget /antirez/redis/archive/3.0.0-rc3.tar.gz$ tar zxvf 3.0.0-rc3.tar.gz$ cp -r redis-3.0.0-rc3 /usr/local/redis$ cd /usr/local/redis$ make#编译$ make install#编译好的文件将被复制到/usr/local/bin下$ cp redis.conf /etc/redis.conf#先修改redis.conf让server以daemonize yes运行Redis组件说明：#redis-server：Redis服务器。#redis-cli：Redis客户端，命令行操作工具。#redis-benchmark：Redis性能测试工具，测试Redis在你的系统及配置下的读写性能。$redis-benchmark -n 100000 -c 50 #模拟同时由50个客户端发送10万个SETs/GETs查询#redis-check-aof：用于修复出问题的AOF文件。#redis-check-dump：用于修复出问题的dump.rdb文件。#redis-sentinel：用于集群管理。启停Redis服务器：$ redis-server /etc/redis.conf #启动redis服务器，指定要加载的配置文件，redis默认以非daemon方式运行，默认服务端口6379，redis服务器可以启动多个$ ps -ef | grep redis#检测redis服务器是否正常启动$ redis-cli shutdown#通过客户端关闭redis服务器$ redis-cli -p 6379 shutdown#通过客户端关闭指定端口的redis-server$ redis-cli -help#查看客户端工具帮助信息启动Redis客户端：$ redis-cli -h -p 8379 -a tianDIyiHAO7788 -n#连接到指定的redis服务器，端口为redis.conf中的port，密码tianDIyiHAO7788在redis.conf中设置1.4.2 HiredisHiredis安装：$ wget /redis/hiredis/zip/master或者$ /redis/hiredis$ unzip master$ make$ make install修改.bash_profile，export LD_LIBRARY_PATH=/usr/local/lib/:$LD_LIBRARY_PATH$ g+ -lhiredis redis.cpp$ ./a.out1.5 参考资料1、 官方网站http:/www.redis.io/documentation2、Redis入门指南。3、超强、超详细Redis入门数据库教程/article/56448.htm4、Redis学习手册/stephen-liu74/category/354125.html5、Redis应用场景示例/yuxingfirst/archive/2012/11/16/2773658.html/article/51624.htm/article/54774.htm6、hiredis简单函数使用介绍/mniwc/article/details/128518377、hiredis源码学习/2014/03/hiredis//xuxu8511/archive/2013/08/06/3240941.html2. 基本操作2.1 系统管理Redis在设计之初就被定义为长时间不间断运行的服务进程，因此大多数系统配置参数都可以在不重启服务器的情况下立即生效，即便是将持久化模式从AOF切换到RDB。2.2 key-value操作2.2.1 key操作key相关指令参见Redis命令。2.2.2 string类型string是最基本的类型，而且string类型是二进制安全的，意思是string可以包含任何数据，例如jpg图片或者序列化的对象。从内部实现来看，其实string可以看作byte数组，最大上限是1GB。string类型的数据操作指令，参见Redis命令。2.2.3 list类型list的key就是链表的名字，value是由string类型组成的双向链表，是按照插入顺序排序的字符串链表。list的底层实现是一个链表结构，并不是数组，由于为链表结构，所以在链表头部或尾部插入/删除新元素时间复杂度为常数级别，即在10个元素的链表头部插入/删除新元素，和在上千万的链表头部插入/删除新元素的速度应该相同。但是链表型元素定位比较慢，数组型lists定位快。如果在链表中间插入/删除元素，将会非常低效。主要功能是lpush（链表左侧插入一个元素）、rpush（链表右侧插入一个元素）、lrange（链表中指定一个范围提取元素）等。如果链表中所有的元素均被移除，那么该键也将从数据库中删除。List可以包含的最大元素为4294967295。适用场景：1、 用作消息队列，以完成程序之间的消息交换。可以确保先后顺序，不必像MySQL需要order by排序。2、 利用lrange很方便的实现分页功能。3、 在博客系统中，每篇博文评论存入一个list中。使用示例：2.2.4 set类型set的key就是集合的名字，value是由string类型组成的集合。set中的元素没有先后顺序，是一种无序集合。与list不同的是，set集合中不允许出现重复的元素，如果多次添加相同元素，将忽略相同元素的添加，与C+标准库的set容器相同。set主要满足唯一性和无序性的场景。和list相比，set还提供取交集、取并集、取差集的功能，操作在服务端完成，因此效率极高，而且节省了大量的网络I/O开销。添加、删除、判断元素是否存在等操作，时间复杂度为O(1)。set最大容量为4294967295。适用场景：1、 QQ用户标签，把每个用户的标签都存储在一个集合中。2、 可以用set类型跟踪一些唯一性的数据，例如访问某一博客的唯一IP地址。3、 充分利用set类型的服务端聚合操作方便、高效的特性，可以用于维护数据对象之间的关联关系。例如所有购买某一电子设备的客户ID被存储在一个指定的Set中，而购买另外一种电子产品的客户ID被存储在另外一个Set中，如果此时我们想获取有哪些客户同时购买了这两种商品时，Set的intersections命令就可以充分发挥它的方便和效率的优势了。使用示例：2.2.5 sorted set类型与set类似，都是字符串的集合，都不允许重复成员。差别是sorted set中的每一个成员都会有一个分数（score）与之关联，这便是从小到大排序的依据。成员是唯一的，但是分数可以重复。在Sorted-Set中添加、删除或更新一个成员都是非常快速的操作，其时间复杂度为集合中成员数量的对数。由于Sorted-Sets中的成员在集合中的位置是有序的，因此，即便是访问位于集合中部的成员也仍然是非常高效的。事实上，Redis所具有的这一特征在很多其它类型的数据库中是很难实现的，换句话说，在该点上要想达到和Redis同样的高效，在其它数据库中进行建模是非常困难的。适用场景：1、 可以用于一个大型在线游戏的积分排行榜。每当玩家的分数发生变化时，可以执行ZADD命令更新玩家的分数，此后再通过ZRANGE命令获取积分TOP TEN的用户信息。当然我们也可以利用ZRANK命令通过username来获取玩家的排行信息。最后我们将组合使用ZRANGE和ZRANK命令快速的获取和某个玩家积分相近的其他用户的信息。2、 sorted set还可用于构建索引数据。使用示例：2.2.6 hash类型hash存的是字符串和字符串值之间的映射，类似string key和string value的map容器，非常适合存储值对象的信息，例如一个用户要存储其全名、姓氏、年龄等等，就使用hash，可以将hash看作关系型数据库中的一行，hash的每个子键对应行的一个字段，因此，当把关系型数据库中的数据缓存至Redis时，使用hash较方便。hash结构内部的子键之间是没有顺序的，没有联系，但是它们共同组成了一个完整的hash结构。每个hash可以存储4294967295个键值对。添加，删除操作都是O(1) （平均） 。hash 特别适合用于存储对象。相对于将对象的每个字段存成单个 string 类型。将一个对象存储在 hash 类型中会占用更少的内存，并且可以更方便的存取整个对象。省内存的原因是新建一个 hash 对象时开始是用 zipmap（又称为 small hash）来存储的。这个 zipmap 其实并不是 hash table，但是 zipmap 相比正常的 hash 实现可以节省不少 hash 本身需要的一些元数据存储开销。尽管 zipmap 的添加，删除，查找都是 O(n)，但是由于一般对象的 field数量都不太多。 所以使用 zipmap 也是很快的,也就是说添加删除平均还是 O(1)。如果 field或者 value的大小超出一定限制后，redis会在内部自动将zipmap替换成正常的hash实现。这个限制可以在配置文件中指定。hash-max-zipmap-entries 64 #配置字段最多 64 个hash-max-zipmap-value 512 #配置 value 最大为 512 字节使用示例：2.3 主从同步Redis支持一主多从以及多级从结构。主从结构一是为了冗余备份，另外读取任务可以分摊到从服务器上，提升读取性能。主从同步异步进行，不会影响主逻辑，也不会降低Redis性能。主从架构中可以关闭主服务器的持久化功能，只在从服务器做持久化，可以提高主服务器的性能。主从架构中，从服务器通常被设置为只读模式，避免从服务器数据误修改。主从同步原理：1、 从服务器向主服务器发送SYNC指令，当主服务器接受到该命令后，调用bgsave指令创建一个子进程专门进行数据持久化，就是将主服务器的数据写入RDB文件中。在持久化期间，主服务器将执行的写指令缓存在内存中。2、 在bgsave指令执行完成后，主服务器将持久化后的RDB文件发送给从服务器，从服务器保存RDB文件，然后读到内存中。该动作完成后，主服务器将这段时间缓存的写指令再以Redis协议的格式发送给从服务器。3、 即使有多个从服务器同时发送SYNC指令，主服务器只会执行一次bgsave指令，然后将持久化后的RDB文件发送给多个下游。Redis 2.8版本之后，Redis支持增量同步：主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置（replication offset）”发送出去。主服务器接收到这样的同步请求后，首先会验证主服务器ID是否和自己的ID匹配，其次会检查“请求的偏移位置”是否存在于自己的缓冲区中，如果两者都满足的话，主服务器就会向从服务器发送增量内容。2.4 分区分区的好处：1、利用多台机器的内存，支持更大的数据库。2、可以充分利用多核和多台机器的计算能力，以及多台机器的网络代码。分区的实现方法：1、客户端分区，客户端直接把数据按照一定规则存放在不同的分区上。2、代理辅助分区，也就是客户端把请求发到代理，由代理按配置好的规则分发到不同的分区上。开源中间件Twemproxy实现了代理辅助分区。3、查询路由，客户端把请求发给众多服务器中的任意一个，由服务器把请求路由到合适的服务器中。分区的缺点：1、不支持多个key的操作，如要计算两个集合的交集。2、不支持涉及到多个key的事务。3、分区的粒度是key, 因此如果单个key值的数据非常大，也不能分到不同的区中使用了分区，数据管理会变得复杂，如为了备份数据，你要从多个实例多台机器上收集RDB/AOF文件。4、增加和减少分区变得复杂, 客户端分区和代理辅助分区，要增加或者减少分区就会比较困难，目前有一个办法可以实现，就是预先把分区分得足够多。2.5 事务Redis事务相关的四个指令：1、 mulit，用来组装一个事务，类似于关系型数据库的BEGIN TRANSACTION。每个命令都会进入到内存队列中缓存起来，QUEUED表示命令成功插入了缓存队列。在执行exec时，这些被QUEUED的命令都被会组装成一个事务执行，按照先插入先执行的顺序执行。2、 exec，用来提交执行一个事务。如果Redis开启了AOF，一旦事务执行成功，事务中的命令会通过write命令一次性写到磁盘上，如果在向磁盘写的过程中恰好出现断电、硬件故障等问题，就会出现只有部分命令进行了AOF持久化，AOF文件不完整，可以使用redis-check-aof修复，该工具会将AOF文件中不完整的信息移除，确保AOF文件完整可用。（1） 事务执行期间，Redis不会再为其他客户端的请求提供任何服务，从而保证了事务中所有命令都被原子的执行。（2） 与关系型数据库事务相比，Redis事务中如果有一条命令执行失败，其他命令仍然会继续执行。（3） 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行。（4） 当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。3、 discard，用来取消一个事务，与multi对应。若果已经exec，discard无效。4、 watch，用来监视key是否被改动过，而且支持同时监视多个key，一旦这些key在事务执行之前被改变，则取消事务的执行，事务之前的改变生效，此时watch失效，若需要监视，需要继续调用watch key。实现乐观锁的效应，即CAS（check and set）。multi使用示例：两类事务错误：1、 调用exec之前的错误。可能是语法错误、内存不足，只要某个命令无法成功写入缓冲队列，在调用exec时，Redis会拒绝执行。2、 调用exec之后的错误。Redis会忽略错误，继续执行事务中的其他命令，其他命令正常生效。watch使用示例：2.6 集群2.7 内存存储与持久化Redis数据库中的所有数据都存储在内存中。由于内存的读写速度远快于硬盘，因此Redis在性能上比其他基于硬盘存储的数据库有非常明显的优势。但是将数据存储在内存中也有问题，例如，程序退出后内存中的数据会丢失。不过Redis提供了对持久化的支持，即将可以内存中的数据异步写入到硬盘中，同时不影响继续提供服务。Redis通过以下两种方式实现对数据的持久化，快照方式和日志追加方式，快照方式为默认持久方式，官方建议两种方式同时使用，不会有任何冲突。如果没有数据持久化需求，可以关闭RDB和AOF，这样Redis将变成一个纯内存数据库，类似于MemCache。2.7.1 快照方式RDB方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。持久化的过程中，Redis会先将数据写到一个临时文件，在持久化结束后再用该临时文件替换上次持久化的文件。对于RDB方式，Redis会单独创建一个子进程进行持久化，而主进程进行任何I/O操作，这样确保了Redis的性能。客户端也可以使用save或bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有客户端请求，所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步增量数据。如果数据量大的话，写操作会比较多，必然会引起大量的磁盘IO操作，可能会严重影响性能。注意：由于快照方式是在一定间隔时间做一次的，所以如果redis意外宕机的话，就会丢失最后一次快照后的所有数据修改。redis-check-dump可以用来修复dump文件。Redis可以参照当前数据库中数据被修改的数量，达到一定阀值后，可以每隔若干时间将快照存储到磁盘上。修改不会立即持久化，避免了频繁I/O，效率上得到提升，但是失去了可靠性，因此提供了另外一种持久化机制-Append方式。2.7.2 日志追加方式AOF方式 redis 会将每一个收到的写命令都通过write函数追加到文件末尾(默认appendonly.aof)，不允许改写文件。当redis重启时，会通过重新执行文件中保存的写命令实现数据恢复。当然由于操作系统会在内核中缓存 write 做的修改， 所以可能不是立即写到磁盘上。这样的持久化还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis 我们想要通过 fsync 函数强制操作系统写入到磁盘的时机。AOF重写：日志追加方式同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incrtest 命令 100 次，文件中必须保存全部 100 条命令，其实有 99 条都是多余的。因为要恢复数据库状态其实文件中保存一条 set test 100 就够了。为了压缩这种持久化方式的日志文件，redis 提供AOF文件重写机制，当AOF文件大小超过所设定的阀值时，Redis会启动AOF文件压缩，只保留可以恢复数据的最小指令集。AOF文件重写时，先写临时文件，完成后再替换原文件。或者直接执行bgrewriteaof命令，Redis生成一个全新的AOF文件，其中包括了可以恢复现有数据的最小指令集。如果追加日志时，遇到磁盘空间满、inode或断电等情况导致日志写入不完整，redis-check-aof可以用来修复日志。AOF重写原理：在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。AOF与RDB比较：1、 同样的数据规模，AOF文件要比RDB文件体积大。2、 AOF恢复速度慢于RDB方式。3、 AOF优点：不小心执行flushall，导致Redis内存中的数据全部被清空，只要配置了AOF模式，且AOF文件没有被重写，可以暂定Redis，编辑AOF文件将最后一条flushall命令删除，然后重启Redis就可以恢复Redis所有的数据到flushall之前的状态。如果AOF已经被重写就无法恢复了。AOF异常修复：如果AOF出现了被写坏的情况，Redis不会加载该文件，而是报错退出，修复步骤：1、 备份被写坏的AQF文件。2、 运行redis-check-aof -fix进行修复。3、 用diff -u查看两个文件差异，确认问题点。4、 重启Redis，加载修复后的AOF文件。3. 配置说明3.1.1 简介redis配置文件说明，大小写不敏感，只支持byte，不支持bit。在主配置文件redis.conf中引入其他配置文件指令：include /path/to/other/conf。3.1.2 通用配置1、 daemonize，默认为no，修改为yes以后台守护进程方式运行redis-server。2、 pidfile，当redis-server以守护进程方式运行时，Redis写一个pid文件，记录了redis-server本次启动的进程ID。3、 默认情况下，redis会响应本机所有可用网卡的连接请求。当然Redis允许通过bind配置项指定要绑定的IP。4、 port，redis-server监听端口，默认端口为6379。如果端口设置为0，redis就不会监听端口了。如果redis不监听端口，redis还支持unix socket方式接收请求，通过unixsocket配置项指定unix socket文件路径，并通过unixsocketperm指定文件权限。5、 timeout，如果客户端（例如redis-cli）空闲N秒，则服务器主动关闭客户端连接，修改为0表示永远不关闭。6、 通过tcp-keepalive配置项设置tcp连接保活策略，单位为秒。假如设置为60秒，则server端会每60秒向连接空闲的客户端发起一次ACK请求，以检查客户端是否已经挂掉，对于无响应的客户端则会关闭其连接。所以关闭一个连接最长需要120秒的时间。如果设置为0，则不会进行保活检测。7、 loglevel，log信息级别，总共支持四个级别：debug、verbose、notice、warning，默认为verbose。8、 logfile，默认为空字符串”表示标准输出。如果配置为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志会写到/dev/null。如果希望日志打印到syslog中，通过syslog-enabled yes控制，另外” syslog-ident redis”可以指定syslog中的日志标志。而且还支持指定syslog设备，值可以是USER或LOCAL0-LOCAL7。具体可以参考syslog服务本身的用法。9、 databases，开启数据库的数量，数据库编号从0开始。使用“select 库ID”方式切换操作各个数据库。3.1.3 快照配置1、 sava * *，快照保存频率，注释掉即关闭快照的自动持久化。第一个*表示多长时间，第二个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时，自动保存快照。可设置多个条件。如果开启了RDB功能，如果持久化数据到磁盘出现失败，默认情况下，Redis会停止接收所有的写请求。2、 如果不在乎不一致，在快照写入失败时，也确保Redis继续接受新的写请求，可以修改stop-writes-on-bgsave-error no。3、 rdbcompression，保存快照是否使用压缩，默认为yes，Redis采用LZF算法压缩。如果不想消耗CPU进行压缩，可以关闭该功能，但是快照较大。4、 在存储快照后，rdbchecksum可以让Redis使用CRC64算法进行数据检验，但是会增加10%的性能消耗，如果希望获得较大的性能提升，可以关闭该功能。5、 dbfilename，数据快照文件名（只是文件名，不包括目录），默认值为dump.rdb。6、 dir，数据快照的保存目录。3.1.4 复制配置redis提供了主从同步功能。通过slaveof配置项可以控制某一个redis作为另一个redis的从服务器，通过指定IP和端口来定位到主redis的位置。一般情况下，我们会建议用户为从redis设置一个不同频率的快照持久化的周期，或者为从redis配置一个不同的服务端口等等。代码如下:slaveof 如果主redis设置了验证密码的话（使用requirepass来设置），则在从redis的配置中要使用masterauth来设置校验密码，否则的话，主redis会拒绝从redis的访问请求。代码如下:masterauth 当从redis失去了与主redis的连接，或者主从同步正在进行中时，redis该如何处理外部发来的访问请求呢？这里，从redis可以有两种选择：第一种选择：如果slave-serve-stale-data设置为yes（默认），则从redis仍会继续响应客户端的读写请求。第二种选择：如果slave-serve-stale-data设置为no，则从redis会对客户端的请求返回“SYNC with master in progress”，当然也有例外，当客户端发来INFO请求和SLAVEOF请求，从redis还是会进行处理。你可以控制一个从redis是否可以接受写请求。将数据直接写入从redis，一般只适用于那些生命周期非常短的数据，因为在主从同步时，这些临时数据就会被清理掉。自从redis2.6版本之后，默认从redis为只读。代码如下:slave-read-only yes只读的从redis并不适合直接暴露给不可信的客户端。为了尽量降低风险，可以使用rename-command指令来将一些可能有破坏力的命令重命名，避免外部直接调用。代码如下:rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52从redis会周期性的向主redis发出PING包。你可以通过repl_ping_slave_period指令来控制其周期。默认是10秒。代码如下:repl-ping-slave-period 10在主从同步时，可能在这些情况下会有超时发生：1.以从redis的角度来看，当有大规模IO传输时。2.以从redis的角度来看，当数据传输或PING时，主redis超时3.以主redis的角度来看，在回复从redis的PING时，从redis超时用户可以设置上述超时的时限，不过要确保这个时限比repl-ping-slave-period的值要大，否则每次主redis都会认为从redis超时。代码如下:repl-timeout 60我们可以控制在主从同步时是否禁用TCP_NODELAY。如果开启TCP_NODELAY，那么主redis会使用更少的TCP包和更少的带宽来向从 redis传输数据。但是这可能会增加一些同步的延迟，大概会达到40毫秒左右。如果你关闭了TCP_NODELAY，那么数据同步的延迟时间会降低，但 是会消耗更多的带宽。（如果你不了解TCP_NODELAY，可以到这里来科普一下）。代码如下:repl-disable-tcp-nodelay no我们还可以设置同步队列长度。队列长度（backlog)是主redis中的一个缓冲区，在与从redis断开连接期间，主redis会用这个缓冲区来缓 存应该发给从redis的数据。这样的话，当从redis重新连接上之后，就不必重新全量同步数据，只需要同步这部分增量数据即可。代码如下:repl-backlog-size 1mb如果主redis等了一段时间之后，还是无法连接到从redis，那么缓冲队列中的数据将被清理掉。我们可以设置主redis要等待的时间长度。如果设置为0，则表示永远不清理。默认是1个小时。代码如下:repl-backlog-ttl 3600我们可以给众多的从redis设置优先级，在主redis持续工作不正常的情况，优先级高的从redis将会升级为主redis。而编号越小，优先级越 高。比如一个主redis有三个从redis，优先级编号分别为10、100、25，那么编号为10的从redis将会被首先选中升级为主redis。当 优先级被设置为0时，这个从redis将永远也不会被选中。默认的优先级为100。代码如下:slave-priority 100假如主redis发现有超过M个从redis的连接延时大于N秒，那么主redis就停止接受外来的写请求。这是因为从redis一般会每秒钟都向主 redis发出PING，而主redis会记录每一个从redis最近一次发来PING的时间点，所以主redis能够了解每一个从redis的运行情况。代码如下:min-slaves-to-write 3min-slaves-max-lag 10上面这个例子表示，假如有大于等于3个从redis的连接延迟大于10秒，那么主redis就不再接受外部的写请求。上述两个配置中有一个被置为0，则这 个特性将被关闭。默认情况下min-slaves-to-write为0，而min-slaves-max-lag为10。3.1.5 安全配置1、 requirepass，设置Redis连接密码，如果配置了连接密码，客户端在连接redis-server时需要通过AUTH命令提供密码，默认关闭。当redis-server处于不可信的网络环境中时，需要使用该功能。由于Redis性能非常高，每秒钟可以完成15万次的密码尝试，所以需要设置足够复杂的密码，避免被破解。requirepass tianDIyiHAO77882、 Redis允许对指令更名，将一些比较危险的名字改名，避免被误执行。例如可以将CONFIG改成一个复杂的名字，避免外部调用，同时满足内部需求。rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c89甚至可以禁用CONFIG命令，将CONFIG名字改为空字符串：rename-command CONFIG “”但是需要注意，如果采用AOF方式进行数据持久化，或者需要与从Redis进行通信，那么更改指令的名字可能引起一些问题。3.1.6 限制配置1、 maxclients，最大客户端连接数，默认为1000个。如果达到了此限制，Redis会拒绝新的连接请求，并且向请求方发出“max number of clients reached“。2、 maxmemory，设置Redis可以使用的最大内存。一旦到达内存使用上限，Redis会试图移除内部数据，移除规则通过maxmemory-policy指定。如果redis无法根据移除规则来移除内存中的数据，或者我们设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果是主Redis，设置内存使用上限时，需要预留内存空间给同步队列缓存。3、 移除策略maxmemory-policy，LRU算法和最小TTL算法非精确算法，是估算值。（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：不进行移除。针对写操作，只是返回错误信息。3.1.7 追加模式配置1、 启用日志追加方式，appendonly yes。2、 设置日志文件名称，appendfilename appendonly.aof。3、 三种追加方式，如下：（1）appendfsync always，每次写请求后就立即调用fsync强制写入磁盘，最慢，数据最安全，不推荐使用。（2）appendfsync everysec，该方式为默认方式，每秒钟调用一次fsync强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐。（3）appendfsync no，不调用fsync，让操作系统自行决定sync的时间，性能最好,持久化没保证。当fsync方式设置为always或everysec时，如果后台持久化进程需要执行一个很大的磁盘IO操作，那么redis可能会在fsync()调用时卡住。目前尚未修复这个问题，这是因为即使我们在另一个新的线程中去执行fsync()，也会阻塞住同步写调用。为了缓解这个问题，我们可以使用下面的配置项，这样的话，当BGSAVE或BGWRITEAOF运行时，fsync()在主进程中的调用会被阻止。这意味着当另一路进程正在对AOF文件进行重构时，redis的持久化功能就失效了，就好像我们设置了“appendsync none”一样。如果你的redis有时延问题，那么请将下面的选项设置为yes。否则请保持no，因为这是保证数据完整性的最安全的选择。代码如下:no-appendfsync-on-rewrite no我们允许redis自动重写aof。当aof增长到一定规模时，redis会隐式调用BGREWRITEAOF来重写log文件，以缩减文件体积。redis是这样工作的：redis会记录上次重写时的aof大小。假如redis自启动至今还没有进行过重写，那么启动时aof文件的大小会被作为基准值。这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例，则会触发重写。另外，你还需要设置一个最小大小，是为了防止在aof很小时就触发重写。代码如下:auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb如果设置auto-aof-rewrite-percentage为0，则会关闭此重写功能。3.1.8 LUA脚本配置lua脚本的最大运行时间需要被严格限制，单位毫秒。如果设置为0或负数，无限制。3.1.9 慢日志配置redis慢日志是指一个系统进行日志查询超过了指定的时长。这个时长不包括IO操作，比如与客户端的交互、发送响应内容等，而仅包括实际执行查询命令的时间。针对慢日志，你可以设置两个参数，一个是执行时长，单位是微秒，另一个是慢日志的长度。当一个新的命令被写入日志时，最老的一条会从命令日志队列中被移除。单位是微秒，即1000000表示一秒。负数则会禁用慢日志功能，而0则表示强制记录每一个命令。slowlog-log-slower-than 10000慢日志最大长度，可以随便填写数值，没有上限，但要注意它会消耗内存。你可以使用SLOWLOG RESET来重设这个值。slowlog-max-len 1283.1.10 事件通知配置Redis可以向客户端通知某些事件的发生。3.1.11 高级配置有关哈希数据结构的一些配置项：hash-max-ziplist-entries 512hash-max-ziplist-value 64有关列表数据结构的一些配置项：list-max-ziplist-entries 512list-max-ziplist-value 64有关集合数据结构的配置项：set-max-intset-entries 512有关有序集合数据结构的配置项：zset-max-ziplist-entries 128zset-max-ziplist-value 64关于是否需要再哈希的配置项：activerehashing yes关于客户端输出缓冲的控制项：client-output-buffer-limit normal 0 0 0client-output-buffer-limit slave 256mb 64mb 60client-output-buffer-limit pubsub 32mb 8mb 60有关频率的配置项：hz 10有关重写aof的配置项aof-rewrite-incremental-fsync yes4. 软件测试4.1 测试指标3个测试指标：1、配置Redis不写数据文件（无备份），测试本机访问Redis的读写性能。2、配置Redis不写数据文件（无备份），测试跨主机访问Redis的读写性能。3、测试10W、100W、1000W数据量，备份、重新加载的内存占用情况与效率。4.2 测试环境测试环境：l 操作系统：Redhat 6.0。l 网络：百兆网。l CPU：AMD 三核450，主频2.2G。l 内存: 8G。4.3 测试结