Redis知识拓展

更多命令可参考 Redis 官网：http://www.redis.cn/commands.html

本文仅作知识分享，技术支持不负责解答本文相关知识及拓展。

更改 Redis 配置

使用 config 命令可以对Redis 的配置参数进行热修改，这样就不需要重启，如下所示：

config get *   # 获得所有的配置项的key 
127.0.0.1:7379> config get maxmemory 
maxmemory 4294967296    # 改变redis的内存，推荐内存大小为 4G， 单位为byte
127.0.0.1:7379> maxmemory 4294967296
config get *   # 查看 
127.0.0.1:7379> config get *

查看 Redis 使用情况

info  #查看redis的使用情况
127.0.0.1:7379> info
# Server
redis_version:2.8.13  # Redis 服务器版本
redis_mode:standalone  # 运行模式是单机状态，redis集群时是cluster nodes
os:Linux3.5.0-48-generic x86_64  # 服务器的宿主操作系统
arch_bits:64  # 架构（32 或 64 位）
multiplexing_api:epoll  # Redis 所使用的事件处理机制
tcp_port:7379  #  TCP/IP 监听端口
uptime_in_seconds:11554  # redis启动至今经过的秒数
uptime_in_days:0   # redis启动至今经过的天数

Redis 单机运维

启动 Redis 并查看 key 值，检查状态、远程连接操作如下所示：

./redis-cli -p 端口 -a 密码  # 本地启动Redis客户端，可以进行查看key值，删除key值，检查redis状态等操作，如果端口是6379的话可以省略
./redis-cli -h ip -p 端口 -a 密码  # 远程连接Redis服务，ip和端口为要连接的Redis服务，如果端口是6379的话可以省略

Redis 集群运维

远程连接节点、查看运行情况操作如下所示：

./redis-cli -h ip -c -p 端口 -a 密码   # 客户端远程连接某个节点，要输入对应的ip、端口、密码
127.0.0.1:7379> cluster nodes    # 查看redis集群目前的主从分布和运行情况

通用运维命令

127.0.0.1:7379> time  # 显示服务器时间 , 时间戳(秒), 微秒数
127.0.0.1:7379> dbsize  # 当前数据库的key的数量
127.0.0.1:7379> set fine-1-ha "a"  # 设置 fine-1-ha 的值为 a
127.0.0.1:7379> keys *  # 查询所有 key
127.0.0.1:7379> keys fine*  # 模糊查询以 fine 为前缀的 key 值
127.0.0.1:7379> keys *ha  # 模糊查询以 ha 为后缀的 key 值
127.0.0.1:7379> DEL key1  # 清空指定的key，多个之间用空格隔开
127.0.0.1:7379> flushall   # 清空整个 Redis 服务器的数据，谨慎使用
127.0.0.1:7379> Flushdb  # 清空当前库所有键
127.0.0.1:7379> exit   # 退出 Redis 客户端

本文仅作知识分享，技术支持不负责解答本文相关知识及拓展。

特别提示

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

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

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

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，同时在启停 FineReport 或者 FineBI 服务的时候，页面上会报 WebSocket 端口异常这个现象，这个现象产生的原因是 WebSocket 端口检测的时候需要用到先进行 Redis 集群的连接以便后面进行保存数据，但是进行 Redis 集群连接的时候检测到了 Redis 集群存在两个集群，所以判断集群不可用然后才报出 WebSocket 端口异常的提醒。

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

集群资源支持

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

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

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