这两天突然想起redis，索性就再尝试一下搭建最新版本的redis，过程有点艰辛呀，记录一下，供自己和大家今后搭建做参考。

一、为什么用Redis？

　　我自己总结了一下：

　　1、基于内存实现的key-value类型的存储，速度快，性能好。

　　2、支持多种存储类型，有Strings，Hashes，Sets，Lists，Sorted Sets类型。

　　3、支持数据持久化，有Snapshotting，Append-Only File模式的持久化。

　　4、支持集群和哨兵。

　　5、支持主从复制。

　　6、支持简单的事务控制。

　　7、支持消息的发布和订阅。

　　8、安全性的支持。

　　9、支持数据过期。等等

二、Redis的应用场景

　　总结了以下几点，应用场景特别多，大家根据其特性可类推其作用：

　　1、主要是用于热点数据的存储，比如Top100，最新10个数据。

　　2、时间过期（如短信验证码的过期时间等）。

　　3、计数器，由于Redis是单线程且命令的原子性，可用来构建计数器。

　　4、可用来构建队列，Sorted Sets。

　　5、缓存，为减轻数据库访问压力。

　　6、分布式锁，分布式session管理。

三、Redis主要功能介绍。

　　先介绍Redis的几个主要功能。

　　1、不同数据类型的存储。这个我在这里就不讲了。哈哈，大家去百度下都有了。

　　2、高级特性。在这里，我通过redis的redis.conf配置文件来给大家讲解，只讲经常会用到的，其余配置，大家感兴趣可自己学习下。

　　(1)、NETWORK，网络配置。

• bind：绑定服务器的网卡IP，由于一个服务器可能有多个网卡，配置这个bind属性，可限制访问该网卡IP才能访问到Redis。注意：不是绑定外部访问该服务器的IP，网上很多地方都是错误讲解的。我这边搭建环境一般都是将其注释掉，允许该服务器所有IP都能访问到Redis服务。默认是bind 127.0.0.1。
• protected-mode：Redis服务的保护模式，保护模式下，只能允许127.0.0.1 and ::1这种本地访问，配置默认为开启状态protected-mode yes。这里要注意保护模式的生效条件。根据配置文件中注释：

　　　　# When protected mode is on and if:1) The server is not binding explicitly to a set of addresses using the "bind" directive.2) No password is configured.

　　　该模式在bind被注释掉和没有配置访问密码的时候才生效。一般可让其为开启状态，同时配置访问密码，来实现Redis的服务安全性。

• port：配置Redis服务的端口。很重要哦。默认是6379。

　　(2)、GENERAL，常规配置。

• daemonize：服务是否后台运行，默认是no，我们自己没有改的话，启动redis时候，会占用当前连接。所以，大家记得改成yes，让其在后台运行。
• pidfile：配置Redis服务的PID号存在哪个文件。由于可能在同一服务器上启动多个Redis服务，所以，大家最好指定具体的PID文件，且不同的Redis服务的PID文件不同。

　　　如配置为：pidfile /var/run/redis_（端口）.pid

• logfile：指定Redis服务的日志路径，大家记得也修改一下。

　　(3)、SNAPSHOTTING，快照类型的持久化配置，这里说明下快照的原理：快照是Redis的默认持久化方式，这种方式就是以快照的方式将内存中的数据写到二进制文件中，文件名为dump.rdb。介绍下快照保存的步骤：1、redis调用fork，产生一个子进程。2、父进程继续接受client的请求处理数据，利用copy on write，将执行快照动作时候的内存拷贝做成副本。3、子进程通过副本将数据写入临时文件，并替换之前的dump.rdb文件，然后退出。所以，快照持久化的数据是执行快照动作时的内存数据。Client可以通过调用save或者bgsave命令执行快照，不同点事save命令由redis主进程完成，会阻塞所以client请求，而bgsave是开启子进程执行，不会阻塞其他client请求。需要注意的是，当Redis服务是作为大数据量的内存存储时，调用快照，由于数据量较大，且是快照所有内存数据，这会造成大量磁盘IO动作，可能会严重影响性能。

• save 900 1
  save 300 10
  save 60 10000

　　　save <seconds> <changes>，配置快照触发的条件。解读第一个sava：900秒内有一个key值变化，则会触发快照。可配置多个条件，条件是独立的。

• stop-writes-on-bgsave-error：这个配置默认为yes，是指Redis在后台持久化失败后，为了让客户感知到，会拒绝写服务，直到后台持久化恢复正常。如果需要在后台持久化失败后，希望能继续服务。可将其设置为no。
• dbfilename：指定二进制文件名，默认为dump.rdb。
• dir：指定rdb文件路径。配置为文件夹那一层。在一台服务器上启动多个Redis服务时，注意修改为不同文件路径。

　　(4)、REPLICATION，主从模式的配置。注意，之前版本的redis，配置为slave of，现在改为REPLICATION。主从模式，可以是树状的，从服务属于多台主服务，且从服务也可以有从服务。主从模式，可实现读写分离；高可用模式下，主服务出现问题，也可以通过哨兵切换从服务为主服务；可实现主服务不用数据持久化，从服务进行持久化工作，减轻主服务负担等等。

• replicaof <masterip> <masterport>：配置主服务的ip和端口。配置之后，就是这台机器的小弟了。主服务也能知道谁是他的小弟。
• masterauth <master-password>：如果主服务需要密码认证，这里需要配置从服务连接主服务的密码。
• replica-read-only：默认为yes，配置从服务默认为只读模式。

　　(5)、SECURITY，安全配置。

• requirepass：配置连接该Redis服务需要的认证密码。注意一下，由于redis的请求速度特别快，每秒150K，所以密码强度一定要高一些，不然很快就会被破解。

　　(6)、CLIENTS，客户端配置

• maxclients：配置最大客户端连接数，最大支持10000个。超过了连接时，客户端会收到超过最大连接数的提示。

　　(7)、MEMORY MANAGEMENT，内存管理配置。配置Redis服务占用的最大内存，超过内存后，会将设置超时的key按超时时间来剔除，如果没有可剔除的key后，那就报内存已满。配置没细细研究，下来研究一下补充。

　　(8)、APPEND ONLY MODE，aof模式的另一种持久化方式。这种模式，是为了弥补快照模式的不足。快照模式下，对于大内存数据时，快照严重影响性能，而且，快照是有触发条件的时间间隔，这个间隔时间内，如果Redis服务Down掉，那这个时间段的数据就消失了。如果应用的数据一致性要求比较高，那就可以使用AOF模式。AOF模式是在收到写命令后，通过write将命令追加到appendonly.aof文件中。Redis重启后，通过读取该文件中的命令来重新恢复内存数据（注意，如果同时存在aof和rdb文件，Redis服务启动时，优先读取aof文件）。注意：持久化文件会越来越大，而且会有很多重复的命令，这也会导致不必要的内存影响，所以，Redis提供了bgrewriteaof命令来重建aof文件，过程如下：1、主进程调用fork，产生子进程。2、Redis子进程通过当前数据的快照，往aof临时文件中写入数据命令。3、redis主进程继续接收命令，并存在缓存中。4、子进程写完快照命令后，通知主进程，主进程将缓存中的命令也写入临时aof文件中。5、写完后，主进程用临时的aof文件替换之前的aof文件。

• appendonly：默认为no，关闭aof模式，需要开启则设置为yes。
• appendfilename ："appendonly.aof"，指定aof文件名。
• appendfsync ：always，每次写操作时触发aof。
  appendfsync ：everysec，每秒写一次aof，默认设置，3个配置选一个就行。
  appendfsync ：no，依赖os系统，当系统想刷新aof时，就执行aof。（任性，性能高，不稳定，和快照感觉差不多）。

　　(9)、REDIS CLUSTER，redis集群配置。

• cluster-enabled：默认是注释掉，不启用集群模式的。取消注释即可开启集群模式。
• cluster-config-file：指定cluster的配置文件，每个cluster的节点都需要这个配置文件，会在简历集群的时候自动填充内容，所以，需要指定为不同的文件。
• cluster-node-timeout：超过这个时间，某个节点不能被连通，则视该节点为failover状态。

　　(10)、其余配置项大家自己研究一下。

四、Redis集群及哨兵简单介绍

　　集群：集群是一个提供在多Redis节点间共享数据的程序集。Redis集群会把数据分配到不同的片区，引入了16384个哈希槽，哈希槽会分布在集群中的主节点，key通过CRC16校验后，对16384取模，来决定数据落在哪个槽内，有利于添加或删除节点，只需进行哈希槽的重新分配。集群通过主从模式，具有高可用性，某个主节点fail后，集群会选取主节点下一个从节点作为新的主节点，并给它分配之前主节点的槽位，如果切换完成后，旧的主节点上线，它此时也只能作为新的主节点的从节点。注意，Redis5.0之前，部署集群需要安装ruby等，但在Redis5.0中，不需要安装Ruby，直接使用redis-cli就可以创建集群！

　　哨兵：主从模式下，为了使主从具备高可用性，就需要通过哨兵进行监控，在主节点下线后，会通过投票出新的主节点，在主节点上线后，也只能作为新主节点的从节点。哨兵在生产环境下，也需要具备高可用，所以哨兵一般也要配置为集群。

五、搭建主从模式的Redis服务，并启动多个哨兵进行监控

　　1、下载redis。下载地址：http://www.redis.cn/download.html。

　　2、解压，编译Redis。

　　(1)、新建一个文件夹放Redis服务相关的东西。

　　(2)、在该文件夹下解压、编译Redis。

　　　　tar -zxvf redis-5.0.0.tar.gz

　　　　make && make install

　　(3)、在解压后的Redis文件夹中，找到redis.conf文件，该文件是启动redis服务所需文件，拿出来，我们这里建三个redis服务，一主两从，将文件拷贝三份，分别命名为redis-7000.conf，redis-7001.conf，redis-7002.conf，分别编辑以下内容，注意如果配置的文件夹不存在，则需要新建好。其余配置保持默认。我举一个例子说明：

• #bind 127.0.0.1，将bind注释掉。
• port 7000：改变其服务端口，三份文件端口分别为7000,7001,7002，注意检查端口是否被其他程序占用。
• daemonize yes：修改服务为后台运行。
• pidfile /var/run/redis_7000.pid：指定不同的pid文件，注意三份配置文件不同。
• logfile "/var/redis/7000.log"：指定log日志路径，自己配，要求不同。
• dir /opt/redis-cluster/redis-7000：这个指定rdb文件的路径配置，要求改成不同。
• # replicaof <masterip> <masterport>：主服务这句话注释，从服务配置的两台需要开启。配置主服务的ip的port。
• masterauth ibethfy：都配上吧，从服务到主服务的认证密码。
• requirepass ibethfy：三份文件都配置，客户端访问需要密码验证。

　　(4)、配置好三份文件后，使用redis-server redis-7000.conf，redis-server redis-7001.conf，redis-server redis-7002.conf启动服务，注意我是在配置文件路径执行的命令。

　　　　使用ps -ef|grep redis查看是否三个服务都正常启动，使用redis-cli -h ip地址 -p 端口 -a 密码，通过客户端登陆，执行info replication，可以查看到主从信息。

　　(5)、搭建哨兵。新起一台linux吧。同样执行1,2步骤，安装redis。拷贝sentinel.conf三份，分别为sentinel-26380.conf，sentinel-26381.conf，sentinel-26382.conf。

　　(6)、修改sentinel

• protected-mode no：关闭保护模式，使外网能访问。
• port 26380：修改端口。三份文件分别不同。
• daemonize yes：修改为后台运行。
• pidfile /opt/redis-cluster/redis-sentinel-26380/sentinel.pid：指定不同pid文件，注意文件夹不存在自己要新建。
• logfile "/opt/redis-cluster/redis-sentinel-26380/26380.log"：配置哨兵日志文件。
• dir /opt/redis-cluster/redis-sentinel-26380：配置哨兵工作路径。
• sentinel monitor master7000 192.167.3.145 7000 2：配置哨兵需要监控的主节点ip和端口，最后的2代表，如果有2个哨兵主观认为主节点down了，那么就客观认为主节点down掉了，开始发起投票选举新主节点的操作。多个主节点配置多个。
• sentinel auth-pass master7000 ibethfy：配置哨兵连接主节点的认证密码。（主节点配置的requirepass）。
• sentinel down-after-milliseconds master7000 5000：配置多少毫秒后没收到主节点的反馈，则主观认为主节点down了。
• sentinel failover-timeout master7000 30000：failover过期时间。当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。

注意，配置前把之前的默认的mymaster开启的配置全部注销掉！或者直接在其上修改！不然会出现问题！

　　(7)、在配置文件目录下执行redis-sentinel sentinel-26380.conf，redis-sentinel sentinel-26381.conf，redis-sentinel sentinel-26382.conf，分别启动三个哨兵。

　　(8)、测试，kill掉7000端口的redis服务，一段时间后，登陆到其他端口的客户端，查看info replication，此时是否从节点的某一个已切换成主节点，另一个从节点属于新主节点的从节点。并测试主节点再次上线后，是否是新主节点的从节点。

　　(9)、哨兵的细节问题，可参考：http://www.redis.cn/topics/sentinel.html。

六、集群搭建

　　(1)、同样解压安装、编译Redis，拷贝redis.conf文件，分别为7000-7008，共九个文件。准备搭建1主2从的3套Redis。

　　(2)、配置文件修改，同主从搭建的第三步，只是不需要配置服务的状态了，将replicaof <masterip> <masterport>这个注释掉。

• cluster-enabled yes：开启集群模式。
• cluster-config-file nodes-7000.conf：指定不同的集群节点配置文件，集群会自己修改内容。
• cluster-node-timeout 15000：配置多少毫秒后，主节点失联将会触发节点切换。

　　(3)、使用redis-server redis-7000.conf等将所有节点启动。

　　(4)、使用redis-cli配置集群。命令和启动成功的提示如下。过程中会让你看下节点分配是否可以，输入yes确定。通过日志可以看到，主节点为7000,7001,7002，每个主节点各两个从节点，replicates后面跟的是主节点的nodeid。Slots 0-5460表明各主节点分配到的槽位。

[root@rhel64 redis-cluster]# redis-cli --cluster create 192.167.3.145:7000 192.167.3.145:7001 192.167.3.145:7002 192.167.3.145:7003 192.167.3.145:7004 192.167.3.145:7005 192.167.3.145:7006 192.167.3.145:7007 192.167.3.145:7008 --cluster-replicas 2 -a ibethfy

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.

>>> Performing hash slots allocation on 9 nodes...

Master[0] -> Slots 0 - 5460

Master[1] -> Slots 5461 - 10922

Master[2] -> Slots 10923 - 16383

Adding replica 192.167.3.145:7003 to 192.167.3.145:7000

Adding replica 192.167.3.145:7004 to 192.167.3.145:7000

Adding replica 192.167.3.145:7005 to 192.167.3.145:7001

Adding replica 192.167.3.145:7006 to 192.167.3.145:7001

Adding replica 192.167.3.145:7007 to 192.167.3.145:7002

Adding replica 192.167.3.145:7008 to 192.167.3.145:7002

>>> Trying to optimize slaves allocation for anti-affinity

[WARNING] Some slaves are in the same host as their master

M: 35d56aab1045bded29a8b273dca0d8a9258b4182 192.167.3.145:7000

   slots:[0-5460] (5461 slots) master

M: 238c6ca906531cd0feeebaaa6ff2afb84b9cc072 192.167.3.145:7001

   slots:[5461-10922] (5462 slots) master

M: 144577204f66c0857920dd3ce91ad3248a16e426 192.167.3.145:7002

   slots:[10923-16383] (5461 slots) master

S: a98785183466cc59ae39599779196d986402c94a 192.167.3.145:7003

   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182

S: d80ffdfeef5a536e5e9aaa69aa175b42ca5b1f32 192.167.3.145:7004

   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072

S: 43bf3f2f15cd963f2cb7cbc8427e3c5d70d8b9dc 192.167.3.145:7005

   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182

S: 0723dfeeb31015178791eba46f895076ca66bc05 192.167.3.145:7006

   replicates 144577204f66c0857920dd3ce91ad3248a16e426

S: 603d61677a6044e57e415afb325d7a81501a78c8 192.167.3.145:7007

   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072

S: 110918384563a4173bb17d36b6dd6958a3e97b3c 192.167.3.145:7008

   replicates 144577204f66c0857920dd3ce91ad3248a16e426

Can I set the above configuration? (type 'yes' to accept): yes

>>> Nodes configuration updated

>>> Assign a different config epoch to each node

>>> Sending CLUSTER MEET messages to join the cluster

Waiting for the cluster to join

..........

>>> Performing Cluster Check (using node 192.167.3.145:7000)

M: 35d56aab1045bded29a8b273dca0d8a9258b4182 192.167.3.145:7000

   slots:[0-5460] (5461 slots) master

   2 additional replica(s)

S: 603d61677a6044e57e415afb325d7a81501a78c8 192.167.3.145:7007

   slots: (0 slots) slave

   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072

S: 0723dfeeb31015178791eba46f895076ca66bc05 192.167.3.145:7006

   slots: (0 slots) slave

   replicates 144577204f66c0857920dd3ce91ad3248a16e426

M: 238c6ca906531cd0feeebaaa6ff2afb84b9cc072 192.167.3.145:7001

   slots:[5461-10922] (5462 slots) master

   2 additional replica(s)

M: 144577204f66c0857920dd3ce91ad3248a16e426 192.167.3.145:7002

   slots:[10923-16383] (5461 slots) master

   2 additional replica(s)

S: d80ffdfeef5a536e5e9aaa69aa175b42ca5b1f32 192.167.3.145:7004

   slots: (0 slots) slave

   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072

S: 110918384563a4173bb17d36b6dd6958a3e97b3c 192.167.3.145:7008

   slots: (0 slots) slave

   replicates 144577204f66c0857920dd3ce91ad3248a16e426

S: 43bf3f2f15cd963f2cb7cbc8427e3c5d70d8b9dc 192.167.3.145:7005

   slots: (0 slots) slave

   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182

S: a98785183466cc59ae39599779196d986402c94a 192.167.3.145:7003

   slots: (0 slots) slave

   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

　　(5)、测试节点下线，这里就不说明了。结论是主节点故障后，下挂从节点会有一个升级成主节点，并接替主节点的槽位。另一个从节点切换成作为新主节点的从节点。旧主节点上线后，也只能作为其从节点。

　　(6)、高级特性我这里不说明了，太多了，给大家一个网址：http://www.redis.cn/topics/cluster-tutorial.html。

七、最后，希望各位有问题能留言提出，大家可以一起学习成长！