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

这两天突然想起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。

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

 

      

 

  

 

posted @ 2018-11-16 15:17  ibethfy  阅读(6355)  评论(0编辑  收藏