Redis开发运维实践上线部署规划之具体设置参数

5.6 具体设置参数

详见我行自制安装包conf目录中的各个配置文件和上线前检查表格。

redis参数设置技巧列表:

  1. Daemonize 这个参数在使用supervisord这种进程管理工具时一定要设置为no,否则无法使用这些工具将redis启动。
  2. Dir RDB的位置,一定要事先创建好,并且启动redis 的用户对此目录要有读写权限。
  3. Include 如果是多实例的话可以将公共的设置放在一个conf文件中,然后引用即可: include /redis/conf/redis-common.conf

Redis开发运维实践指南

本文为《Redis开发运维实践指南》内容,该书作者为黄鹏程,已授权转载。

时间: 2024-07-31 03:54:03

Redis开发运维实践上线部署规划之具体设置参数的相关文章

Redis开发运维实践上线部署规划之持久化设置

5.4 持久化设置 RDB和AOF两者毫无关系,完全独立运行,如果使用了AOF,重启时只会从AOF文件载入数据,不会再管RDB文件.在配置上有三种选择:不持久化,RDB,RDB+AOF.官方不推荐只开启AOF(因为恢复太慢另外如果aof引擎有bug),除非明显的读多写少的应用. 开启AOF时应当关闭AOF自动rewrite,并在crontab中启动在业务低峰时段进行的bgrewrite. 如果在一台机器上部署多个redis实例,则关闭RDB和AOF的自动保存(save "", auto

Redis开发运维实践上线部署规划之内存规划

5.1 内存.CPU规划 一定要设置最大内存maxmemory参数,否则物理内存用爆了就会大量使用Swap,写RDB文件时的速度很慢.注意这个参数指的是info中的used_memory,在一些不利于jmalloc的时候,内存碎片会很大. 多留55%内存是最安全的.重写AOF文件和RDB文件的进程(即使不做持久化,复制到Slave的时候也要写RDB)会fork出一条新进程来,采用了操作系统的Copy-On-Write策略(子进程与父进程共享Page.如果父进程的Page-每页4K有修改,父进程自

Redis开发运维实践上线部署规划之服务器部署位置

5.3 服务器部署位置 尽可能把client和server部署在同一台机器上,比如都部署在app server,或者一个网段中,减少网络延迟对于redis的影响. 如果是同一台机器,又想榨干redis性能可以考虑采用UNIX domain sockets配置方式,配置方式如下 这样的配置方式在没有大量pipeline下会有一定性能提升,具体请参见http://redis.io/topics/benchmarks: 另外,对于混合部署即redis和应用部署在同一台服务器上,那么可能会出现如下的情况

Redis开发运维实践上线部署规划之网卡rps设置

5.2 网卡RPS设置 RPS就是让网卡使用多核CPU的.传统方法就是网卡多队列(RSS,需要硬件和驱动支持),RPS则是在系统层实现了分发和均衡.如果对redis网络处理能力要求高或者在生产上发现cpu0的,可以在OS层面打开这个内核功能. 设置脚本: #!/bin/bash # Enable RPS (Receive Packet Steering) rfc=32768 cc=$(grep -c processor /proc/cpuinfo) rsfe=$(echo $cc*$rfc |

Redis开发运维实践上线部署规划之多实例配置

5.5 多实例配置 如果一台机器上防止多个redis实例,为了防止上下文切换导致的开销,可以采用taskset.taskset是LINUX提供的一个命令(ubuntu系统可能需要自行安装,schedutils package).他可以让某个程序运行在某个(或)某些CPU上. 1)显示进程运行的CPU (6137为redis-server的进程号) [redis@hadoop1 ~]$ taskset -p 6137 pid 6137's current affinity mask: f 显示结果

Redis开发运维实践上线部署规划之其他好用的配置技巧

5.7 其他好用的配置技巧 5.7.1 使用supervisord进行进程管理 Supervisord是一个优秀的进程管理工具,一般在部署redis时采用它来进行redis.sentinel等进程的管理,一个已经在生产环境采用的supervisord配置文件如下: ; Sample supervisor config file. ; ; For more information on the config file, please see: ; http://supervisord.org/co

Redis开发运维实践高可用和集群架构与实践(二)

11.1.2 环境搭建 11.1.2.1 部署架构 部署架构上采用三台机器,一个Master接受写请求,两个Slave进行数据同步,三台机器上都部署sentinel(一般为奇数个,因为需要绝大部分进行投票才能failover).(官方示例)具体架构如下图: 注意:如果有条件可以将sentinel多部署几个在客户端所在的应用服务器上,而不是与从节点部署在一起,这样避免整机宕机后sentinel和slave都减少而导致的切换选举sentinel无法超过半数. 11.1.2.2 网络规划 redis高

Redis开发运维实践高可用和集群架构与实践(四)

11.1.4 高可用和异常测试 11.1.4.1 测试环境介绍 sentinel的消息可以通过sentinel日志(/redis/log/sentinel.log)以及sentinel:hello订阅此频道进行查看. 11.1.4.2 手动切换测试 集群情况,2.128为主 发起主动切换: 查看sentinel日志: 在2.129上看,集群已经切换过来: 11.1.4.3 主实例宕测试 接上,此时master为2.129,找出redis实例的pid,然后kill: 此时查看sentinel日志:

Redis开发运维实践开发者设计规范之延迟考虑

4.5 延迟考虑 1. 尽可能使用批量操作: mget.hmget而不是get和hget,对于set也是如此. lpush向一个list一次性导入多个元素,而不用lset一个个添加 LRANGE 一次取出一个范围的元素,也不用LINDEX一个个取出 2. 尽可能的把redis和APP SERVER部署在一个网段甚至一台机器. 3. 对于数据量较大的集合,不要轻易进行删除操作,这样会阻塞服务器,一般采用重命名+批量删除的策略: 排序集合: # Rename the key newkey = "gc