redis5.0.0功能介绍以及主从集群、哨兵搭建

这两天忽然想起redis，索性就再尝试一下搭建最新版本的redis，过程有点艰辛呀，记录一下，供本身和你们从此搭建作参考。

1、为何用Redis？

　　我本身总结了一下：

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

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

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

　　四、支持集群和哨兵。

　　五、支持主从复制。

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

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

　　八、安全性的支持。

　　九、支持数据过时。等等

2、Redis的应用场景

　　总结了如下几点，应用场景特别多，你们根据其特性可类推其做用：

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

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

　　三、计数器，因为Redis是单线程且命令的原子性，可用来构建计数器。

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

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

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

3、Redis主要功能介绍。

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

　　一、不一样数据类型的存储。这个我在这里就不讲了。哈哈，你们去百度下都有了。

　　二、高级特性。在这里，我经过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。介绍下快照保存的步骤：一、redis调用fork，产生一个子进程。二、父进程继续接受client的请求处理数据，利用copy on write，将执行快照动做时候的内存拷贝作成副本。三、子进程经过副本将数据写入临时文件，并替换以前的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文件，过程以下：一、主进程调用fork，产生子进程。二、Redis子进程经过当前数据的快照，往aof临时文件中写入数据命令。三、redis主进程继续接收命令，并存在缓存中。四、子进程写完快照命令后，通知主进程，主进程将缓存中的命令也写入临时aof文件中。五、写完后，主进程用临时的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)、其他配置项你们本身研究一下。

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

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

　　哨兵：主从模式下，为了使主从具有高可用性，就须要经过哨兵进行监控，在主节点下线后，会经过投票出新的主节点，在主节点上线后，也只能做为新主节点的从节点。哨兵在生产环境下，也须要具有高可用，因此哨兵通常也要配置为集群。

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

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

　　二、解压，编译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。

6、集群搭建

　　(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。

 7、最后，但愿各位有问题能留言提出，你们能够一块儿学习成长！