毕业设计时 我使用redis与token结合的方式来实现商城用户信息的验证 redis的部署采用了 主从复制 以及哨兵模式 保证了高可用性 最后实现的效果也很不错 现将其总结如下:
为什么要采取主从复制+哨兵模式集群部署主要基于以下原因:

  1. 1.由于用户的验证信息存储于redis 只要redis宕机 那么所有用户将不可登录网页
    2.2.主从模式只能实现信息的备份 也就是说主机redis宕机后虽然从机会存储有主机的信息 但客户端与redis的连接无法自动从主机切换到从机 这是因为在springboot 的yml文件配置 客户端与redis以ip:端口的形式进行 绑定除非手动配置文件
  2. 3.想要实现redis自动主从切换 就要使用到哨兵 每个哨兵监视整个redis集群 只要有一个哨兵就能实现主从切换 但是因为哨兵存在宕机的可能所以哨兵也要集群化部署

redis集群部署架构示意图

redis集群 linux环境下的配置

如上图所示在conf/ 中创建以下配置文件: 3台用做redis服务器redis-6379.conf，redis-6380.conf，redis-6381.conf，3台用做哨兵，它们的配置文件分别为sentienl-26379.conf，sentinel-26380.conf，sentienl-26381.conf。

redis-6379.conf 的配置如下:

sentienl-26379.conf 的配置如下:

然后分别以redis-server和redis-sentinel命令以加载配置文件的方式的方式对redis服务器和redis哨兵进行启动。效果如下图所示:

可以看到通过ps命令（一种显示进程的命令）集合-ef（一种过滤信息的命令）grep命令（一种搜索相关信息的命令）可以得到redis进程的启动情况。Redis服务器分别启动6379、6380、6381端口，而redis哨兵则分别启动在26379、26380、26381端口。即linux下redis的环境已经顺利的搭建完毕了。

redis主从复制模式实现商城数据备份

总的来说主从复制就是多台服务器连接方案，注意主从复制这里还没有用哨兵服务器仅仅是多台redis服务器的连接，在本商城模拟搭建的环境中以一台服务器用作写即作为数据的提供方master，两台服务用于读即数据的接收方slave。本项目的模拟环境中当作master的redis服务器为6379端口所运行的，当作slave的为运行在6380、6381端口的。
开启redis服务器后 通过redis-cli可以连接运行在不同端口的服务器，用info指令可以获取它们的属性状态信息。

如上图所示为redis-6379的部分状态信息，下面对于几个参数进行说明。Role:master 表示该主机的角色为master即负责写，这与我们的设定是一致的。Connect_slaves:2表示当前主机有两个从机，即两个用作读作为数据备份。Slave0:127.0.0.1,port=6381,state=online，表示slave0的ip为127.0.0.1端口为6381当前为在线状态。
本商城项目连接的redis为主机6379，那么当用户正常登录时其token便会先存入主机redis-6379，然后会在两个从机6380和6381中均进行备份
如下图所示为用户登录后使用google浏览获取的网页端存储的token值。这个值会与存储与redis中token值进行验证从而判定用户的登陆状态。

然后查看一下 此时各个redis服务器的存储信息:



根据上面几张图可以看到用户的token值已正确存储于redis中且完成了复制备份，那么这样即使redis6379机器出现故障出现丢失，由于redis6380和redis6381中已存储数据，所以数据可正常恢复，且可通过哨兵模式选举新的主机，由于数据是一样的新选举出的主机仍可使得服务器正常运行，从而实现了高可用性。

redis哨兵模式实现容灾

Redis哨兵模式是一个分布式系统。本商城项目主要使用哨兵模式对于主从结构中的每台服务器进行监视，防止redis宕机从而导致tokne值丢失，服务端无法对用户信息进行验证从而影响用户正常正常登录系统情况的发生。而当redis出现宕机时，哨兵会通过投票机制选择出新的master并将所有slave连接到新的master，从而保证系统的正常运行，即完成商城的容灾处理。哨兵在运行期间会通过心跳机制不断检查redis服务器的运行状况，当被监控的服务器出现问题时，会向其他哨兵发送通知。当master发生故障时会自动实施故障转移断开master与slave连接选一个slave作为新的master，将其他slave连接到新的master上，并通知客户端新的服务地址。
本商城项目的使用的redis集群模式为3个哨兵加上3个redis服务器，其中redis服务器的配置1主2从，即一个redis服务器作为master，另外两个redis服务器作为slave。需要注意的是三个哨兵在配置时都只监控主机的就可以了，因为主机本身拥有两个从服务器的相关信息，所以只要监控了主服务器自然就可以获取从服务器的情况。下面展示哨兵的相关配置信息:

如上图所示，为其中一台哨兵sentienl-26379的相关配置信息，port 26379表面sentienl将会启动在26379端口，sentienl announce-ip “192.168.118.145”为哨兵配置时的声明ip，这是因为redis部署在linux上，而linux的ip会发生变化所以客户端要从外部访问需声明ip地址，不然访问时会带来一定的问题。Sentienl moitor mymatser 192.168.118.145 6380 2，表明指明主节点信息为ip地址为192.168.118.145，端口为6380的节点，其quorum值为2，表明当其中一个redis下线时此时判定为主观下线，若整个系统中有其他两个哨兵发现已经下线，则将其判定为客观下线，当客观下线后redis集群将会选举出新的主节点。下面从几个情况依次查看节点发生故障后对于商场项目运行产生的相关的影响。另外由于本商城项目的配置为多台redis的集群配置，所以客户端连接时也会有所不同。

如上图所示为redis集群模式下启动的信息，不同于单机启动，redis以哨兵模式集群启动时所需要连入的节点为哨兵而非服务器本身，这是因为哨兵本身就会监控服务器即哨兵本身就掌握了服务相关的运行信息，所以只要监控了哨兵那么对于服务器的运行情况也就了解，也就可以正确的服务器中配置信息。
另外对于客户端从redis中获取的信息的方式做以下配置，该配置是以配置类的形式的生成。

如图所示，在customize函数个性化配置了关于redis读写的相关选项，Read.REPLICA_PREFERRED该配置意味，客户端优先从slave服务器读取相关信息，当slave服务器均下线后再考虑从master中读取相关信息。这是因为在主从模式中master负责写功能，而slave则负责从master中读，这启到读写分离的作用。本商城项目借助xshell连接linux虚拟机，以3哨兵3redis服务器的形式启动，其中由于哨兵会产生相关的日志信息且该信息与本文所研究的故障恢复机制有密切关系，哨兵的启动不采取守护进程的方式。

如上图为使用linux，ps命令所获得的当前虚拟机内redis的结果，可以看到三个redis服务器，三个哨兵均以正常启动。可以看到redis当服务器的进程信息显示均有sentinel标志这便是显示为哨兵的标志。
下面将redis哨兵的服务器的日志内容用以解释说明此时本商城项目的redis集群中服务器运行结构以及状况。

上图为sentienl-26379哨兵的运行情况，由于本项目在启动哨兵时的顺序为sentienl-26379、sentienl-26380、sentienl-26381，所以sentienl-26379哨兵是拥有完整的监控信息以及整个redis集群的构建情况，故以sentienl-26379的运行日志对于本商城项目所使用的哨兵集群构建状况进行说明。
可以看到sentinel-26379启动时，会首先生成自身的sentinel id，这是用于之后哨兵集群之间相互通信所使用的。然后会显示当前所监控的主节点信息，+monitor master mymaster 192.168.118.145 6380 quorum 2，这便对应了在配置文件对于监控主节点信息的相关配置。接下来依次将sentienl-26380和sentienl-26381启动可以看到日志中打印+sdown sentienl信息这表明以及新启动的sentinel加入对应的节点，且新加入的这sentienl所监视的节点也为192.168.118.145 6380。

开启项目，进入登录界面后，可以顺利加载出验证码，且控制台没有产生报错信息，由于验证码的相关信息是存储在redis中，可以证明此时以哨兵集群的模式启动redis没有任何问题，项目正常运行。
那么接下来检验集群模式下主从模式的运行状态。


可以看到正常登录后redis服务器在哨兵集群模式运行情况可以进行正常的主从复制模式，读写完全正常。
接下来进行哨兵模式下故障恢复的试验。杀死master服务器的进程后观察哨兵服务器的日志输出情况，以及项目的运行情况。

如上图所示可以看到我们已经成功杀死了redis master服务器的进程，接下来先查看项目信息。

可以看到当master发生故障后，客户端检测到了异常开始了重连，首先选择重连的是原master即192.168.118.145:6380但由于该服务器已经被我们强制下线了所以该重连请求被拒绝。接下来重连到192.168.118.145:6381以及192.168.118.145:6379，而这里主要就取决于redis哨兵服务器所进行的投票选举结果选出的是谁，那么哪个主机就可以连接成功。那么现在我们查看一下sentienl日志信息。

可以看到当master下线后第一时刻sentienl日志信息首先输出的是sdown master，而sdown为主观下线，然后通过各个slave之间的互相通信，输出odown master，观其后的注释可以看到此时quorum已经为2/2，即已经达到客观下线的标准，所以进行odown mymaster。然后接下来进行投票选举+vote-for-leader，以及一系列投票，然后最终选出新的master为192.168.118.145 6381。并将相关信息重写入配置文件。而我们通过redis-cli连接6381的redis服务器，并查看其信息可以发现，此时其角色已经转化为master，而只连接了一个slave，因为6379已经被强制下线，所以整个redis服务器集群只有两台服务器，一个master一个从服务器。
下图使用info命令查看的 redis-6381的信息

再回到项目网页主界面可以看到仍可正常运行，并无任何异常。
且仍有存有与之前完全相同的token信息值。