1）redis可以认为是一个数据库，数据应该和服务进行物理上面的隔离，主要是为了确保当服务的机器发生宕机，重启，物理断电等意外事故之后，整个服务的配置还存在，同时可以进行恢复。这从一般的mysql，oracle等数据库的部署就可以知道。

2）redis的高可用可以用redis集群来进行保障，这就像数据库可以进行主从备份来保证数据库的高可用。

3）redis集群作为一个高速的缓存数据库，但是由于他自身的架构，所以它有自己可以运行的边界。

1） redis集群采用的是一个主节点存储，操作一部分key值的数据，这也就意味着，如果一开始规划了redis集群的主节点数目，当产生意外的时候，如果redis集群中存活的主节点数目达不到一开始规划的数目，整个redis集群是不可用的。

为了解决这个问题，redis集群引用了从节点的概念，即可以给一个主节点分配多个从节点，比如说一主三从，这样当一个主节点挂掉之后，其它三个从节点会自己竞选出一个主节点来替代已经挂掉的主节点来处理之前他应该处理的key值数据。基于redis集群可用的这个要求，就意味着redis主从节点不应该都部署在一个机器上面来避免机器的意外关机导致整个redis集群不可用。目前业界比较流行的部署方式是采用三主三从的方式来确保redis的高可用。

2） 一个主节点挂掉之后，会从主节点的从节点中竞选出一个主节点。在竞选的短暂过程中可以认为之前应该有该redis主节点处理的key值是不能进行操作的，直到从从节点中产生可以替代的主节点，并通知其它所有的节点，该主节点已经产生。整个集群可用。也正是因为这个原因，所以目前做的关停机测试再停机之后会出现性能测试拐点的问题，这个问题就是因为主节点的选举以及整个redis集群再次回复使用才能对外提供服务造成的。如下图：

3） 当再次启动已经被停止的redis主节点的时候，因为这时候启动的之前停止的redis主节点认为自己是一个主节点，但是实际上已经存在了它的替代的主节点，所以这时候整个redis集群就可以认为被分成了两个逻辑上的redis集群，因为可以认为，redis集群之所以成为集群，就是因为他有主从的概念。当然，当这个再次重启的redis主节点和别的节点的交流过程中，因为他发现已经存在了替代他的主节点。所以它会自己把自己降级为从节点。但是，正是有这个过程，所以目前开停机测试之后启动了机器上面的redis，同时在启停fr或者bi服务的时候，页面上会报websocket端口异常这个现象，这个现象产生的原因是websocket端口检测的时候需要用到先进行redis集群的连接以便后面进行保存数据，但是进行redis集群连接的时候检测到了redis集群存在两个集群，所以判断集群不可用然后才报出websocket端口异常的提醒。

4） redis集群可用还有一个边界就是不能同时挂掉超过一半的主节点或者节点数。正是因为这个边界的存在，所以，每次关机之后的关机再启动redis节点都需要关注一下redis集群的多数主节点是否都在一台机器上面。如果都在一台机器上面就需要人为的进行运维，使redis集群的主节点不在同一台机器上面。

1） 因为目前业界里面经过检验的，比较合理，常用的redis集群架构是3主3从，所以如果考虑这个redis架构，最好有三台独立的物理机进行redis集群部署。

理论上来说，原则只有一个，那就是需要有不同的物理机来部署redis集群的主从节点，确保一台机器挂掉不会影响redis集群的整体可用。

2） 当然，如果已经存在现有的redis集群，可以考虑和帆软的产品共用一套redis集群，因为，fr，bi产品目前使用redis进行存储的key值是有固定的可以修改的前缀，所以在存储数据方面可以保证和现有使用redis集群的系统的存储的数据区分开来。