Redis系列- 服务配置
  TEZNKK3IfmPf 2023年11月14日 27 0

为了方便讲解,笔者在实操过程中全部使用的是默认配置。

通过.conf文件配置(建议)

如果想自定义配置文件,可查看笔者的上一章中启动一节的描述。下面例子中是默认配置文件,修改后需重新启动redis服务。​

运行交互命令配置

可以运行状态中动态修改一部分配置,下面只给出配置的方式,至于哪些配置可在运行中动态修改需要读者自行查询官方文档或用以下命令来查看,重新打开个终端窗口(命令行工具,笔者用的是mac系统自带的终端工具,但笔者比较推荐iTerm2工具);

Redis系列(2)- 服务配置

Redis系列(2)- 服务配置

节点配置

因配置文件内容比较多,读者可自行查看/usr/local/etc/redis.conf文件,下面章节只描述一些重要配置参数的作用。读者可自行试验。

服务相关

以下参数只能由配置文件配置,不能在运行中修改

databases说明:一个逻辑分组,数据库间也不是物理隔离的,它更像一个命名空间。redis默认支持16个数据库,可以修改这个数字,redis不支持自定义数据库名,在开发时必须记住。在单机版开发时客户端可指定通过select命令连接指定的库,但需要注意有些命令是合局的,比如flushall。

在单机环境时当建立连接后,默认选择编号为0的数据库,可以通过select命令来选择,但集群环境只有一个库。所以这个配置只适用于单机环境


快照相关

redis快照功能,是可以被关闭的,关闭后节省了磁盘空间,但在主宕机时也增大了丢数据的风险,所以一般不是非必要情况不要关闭快照功能,redis在以下三种情况下会创建快照:

  1. 通过bgsave, save,shutdown命令,其中save,shutdown这两个命令是阻塞的,其间不会接收用户请求,bgsave命令会新开一个线程,异步创建快照,其间不会阻塞用户请请求;
  2. 当有新节点加入时,主节点也会创建快照,主节点会先执行bgsave然后再sync同步;
  3. flushall命令,这个命令会清除数据库中的所有数据,但如果配置了快照功能则会先生成快照,再执行fluashall命令;

注:bgsave命令备份会新开一个线程,同时也占用了部分CPU资源,在极端情况下有造成机器停顿的风险,比如宿主机同时在运行大量的运算,另外bgsave的时间要比save长5倍左右,一般数据量1G大概会占用20ms左右时间来生成快照,有时为了平衡上述关系,对于不太重要的数据会关闭快照功能,转而采用定时任务或手动触发。

虽然bgsave有各种风险,但如果按CAP原则来设置的话,还是会选择服务的稳定性。一台服务器不行就扩两台,这也是大多数互联网公司在设计系统时如果资源与稳定性等方面发生冲突,都会花钱选择扩容的原因,毕竟资源还是很好解决的。下面是与快照相关的配置参数:

save配置,触发的是bgsave命令,可以配置多个触发条件,这些条件是或的关系,用逗号分隔,redis会依次检查,只要满足前面的条件就不会再检查下一条规则是否满足了,默认配置解读如下:

  1. save 900 1: 如果超过每1秒有900个key发生变化(新增、修改和删除),则重写rdb文件;
  2. save 300 10: 如果每10秒有300个key发生变化(新增、修改和删除),则重写rdb文件;
  3. save 60 3600: 表示如果每60秒有10000个key发生变化(新增、修改和删除),则重写rdb文件。

增量文件

aof与rdb的区别和作用就不在细述了,可自行在网上查询,这里只提一点容易被忽略的内容,这个文件它缓存的是命令,命令会追加到AOF文件结尾。

appendfsync配置:表示执行数据操作指令后,数据缓存到硬盘上的时间。不建议修改,可选值还有always和no,其中 no不代表不同步,只是同步的时间由系统决定(这个选项不太好评估,所以不建议使用),always表示实时同步,也不不建议用,因为会造成I/O放大,影响磁盘的寿命。

auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置:这两个配置一起使用的,默认配置表示当AOF文件大于64M时,并且AOF文件的体积比上一次重写之后的体积大了至少一倍(100%)时,才会执行gbrewriteaof命令,也可以人为用这个命令来控制AOF文件的备份。

主从相关

上面描述的的是单机配置,如果在高负载还需要多机,redis间采用的是主从复制(master-slave模式),不支持主主复制。但slave节点可以有自己的slave节点。

节点:分布式环境,会弱化服务器的概念,都会采用节点这个术语来描述,在多数分布式系统中不会存在混合部署的情况,所以可以认为节点==服务器或节点==容器。笔者在以后的文章里也都会采用节点这个术语。

在主从或从从复制时,master节点会先执行bgsave命令,然后将整个快照(rdb文件)发给slave节点,发送期间master会用缓存(aof文件)记录未在快照中的命令,当master发送完快照后,再发送缓存中的写命令给slave,同时slave节点处理快照时会丢弃自身原有的所有数据。

如果在同步期间又有新的slave节点接入,master节点不会重新生成快照,它会把当前的快照发送给所有的slave节点,如果之前同步完成了,则会再生成一个新快照重复之前同步过程。redis这种master-slave模式同步的最大问题在于多个slave节点连接时会造成大量的带宽被占用,因为master节点会持续创建快照然后传输。所以最好的方式是采用树状网络拓扑,即master-slave-slave这样的结构,同步的过程交给中间的slave节点来进行,定向更新。

性能相关

这个比较简单,多数是和数据存储方式相关,看一下下面的注释就可以理解了,后面章节会详细描述。

哨兵配置

集群环境中,加入了slave节点通过数据冗余的方式解决了和读写分离的问题,间接提升了redis的吞量(读),同时节点的健康度就需要特别注意了,如果需要人工介入的方式来监控基本不太可能,因此哨兵就是实现了这个自动化监控的功能。它的作用是监控master-slave节点是否正常运行以及master节点出现问题后自动将slave节点升级为master节点。

在集群环境中,可以用哨兵监控哨兵、也可以用一个哨兵监控多个master节点(需要配置多个下面第一条的配置)、还可以用多个哨兵监控一个主数据库。配置过程如下:

  1. 建立sentinel.conf文件,内容为sentinel monitor mymaster 127.0.0.1 6379 30000。mymaster表示主数据库名字,启动后会自动识别从数据库,所以不需要配置从数据库。后两个参数表示IP和PORT。30000表示执行故障恢复操作需要几个哨兵同意。
  2. 将上述.conf路径传递给sentinel进程。redid-sentinel /path/to/sentinel.conf

    原理如下:部署成功后,哨兵会按sentinel down-after-milliseconds mymaster 30000中配置的时间周期地向master节点的__sentinel__:hello订阅请求的内容,同时发送info命令获取信息,每秒会向所有节点发送ping命令。当ping未回复则主观认为下线了,如果是master节点,还会向其它哨兵发送sentinel is-master-down-by-addr询问,如果达到指定的询问数量(上例中的30000),则认为客观下线了,这时就会执行故障恢复功能。一般时候不要部署单一和过多的哨兵,如果节点不是很多时尽量为每套master-slave节点配置一个哨兵。

    建议的配置模式:slave也可以做为master来使用,这样就可以组建一个树状的redis群组。其使用场景如下:主数据库只写,从数据库只读操作。另一个耗时的操作是持久化,可以在slave中启用持久化,在master中禁用持久化。当master崩掉时可以在slave中启用slaveof no one提供为主数据,在master中使用slaveof变为从数据库,防止数据丢失。也可以同步数据回来。但这个功能不要做成自动重启,需要改动参数后再重启。

哨兵可以视为集群的子集,在不需要水平扩容的时候哨兵就够了,否则就要使用集群。前者的缺点是每个节点存储同样大的数据,势必造成资源的浪费,如果使用分片技术又存在很多问题。所以集群就是不二选择了。哨兵模式基于主从复制模式。哨兵模式下,master挂掉可以自动进行切换,系统可用性更高。缺点是同样也继承了主从模式难以在线扩容的缺点,Redis的容量受限于单机配置,需要额外的资源来启动sentinel进程,实现相对复杂一些。

集群配置

在这里大家一定要清楚一个概念,master-slave是用于数据备份保证数据不丢的情况下也可用于提高系统的吞吐量(读),集群是分布式中的一个概念,核心技术是分区,不具备保证数据不丢的功能,但可扩充系统的吞吐量(写)。

redis的集群原理如下,客户端与redis节点直连,客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可,在Redis的每个节点上,都有一个插槽(slot),取值范围为0-16383 ,一共16384个槽。当我们存取key的时候,redis会根据CRC16的算法得出一个结果,然后把结果对16384求余数,这样每个key都会对应一个编号在0-16383之间的哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用,cluster模式也引入主从复制模式,一个主节点对应一个或者多个从节点,当主节点宕机的时候,就会启用从节点。当其它主节点ping一个主节点A时,如果半数以上的主节点与A通信超时,那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了,那么该集群就无法再提供服务了。为了增加集群的可访问性,官方推荐的方案是将node配置成主从结构,即一个master主节点,挂n个slave从节点。这时,如果主节点失效,Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点,整个集群继续对外提供服务,Redis Cluster本身提供了故障转移容错的能力,所以有时从节点作为备用节点,不提供请求,只作为故障转移使用。配置集群需要设置cluster-enabled选项为yes,集群中至少需要3台主数据库才能正常运行。配置如下:

  1. 配置cluster-enabled yes;集群会将当前节点记录的集群状态持久化到指定文件中,默认为当前工作目录下的nodes.conf。每个节点对应的文件必须不同,必须通过cluster-config-file来修改此文件的名字;
  2. 通过info cluster来查看节点信息,此时节点还是孤立的;
  3. redis提供了redis-trib.rb的RUBY程序配置集群,它依赖gem的redis包,通过gem install redis来安装;
  4. 执行命令:/path/to/redis-trib.rb create —replicas 1 127.0.0.1:6380 127.0.0.1:6381……(至少6个),—replicas 1表示每个主数据库拥有的从数据库的数量;
  5. 执行cluster nodes可以获得集群中所有节点的信息;
  6. 通过cluster meet ip port向集群中添加新节点;
  7. 分配插槽(插槽就是key和实例的对应关系,其实现规则可参考CRC16算法实现。redis集群会分为16384个插槽)。可以用cluster slots查看插槽的分配情况,在已连接的节点上用cluster addslots 100 101 102,重新分配插槽命令如下:/path/to/redis-trib.rb reshard ip:port。(通过cluster nodes)可以获取redis实例运行的ID;
  8. 如果一个至少负责一个插槽的主数据库下线且没有相应的从数据库可以进行故障恢复,则整个集群就认为下线了。可以通过修改cluster-require-full-coverage no为解决这个问题;
【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 2023年11月14日 0

暂无评论

推荐阅读
  TEZNKK3IfmPf   2024年05月31日   27   0   0 redis用户
  TEZNKK3IfmPf   2024年05月31日   28   0   0 dataredis
  TEZNKK3IfmPf   2024年05月31日   27   0   0 awkredis
  TEZNKK3IfmPf   2024年04月19日   37   0   0 javarediskey
TEZNKK3IfmPf