Redis做为单机缓存使用建议

前言

由于原来项目使用的缓存中间件无法在国产麒麟操作系统里面使用，准备在项目中引入redis做为单机缓存。

配置优化建议

配置redis服务以守护进程启动

Redis默认不是以守护进程的方式运行，可以通过将配置项daemonize修改为yes，这样启动redis-server后会自动在后台运行。

安全配置

将bind配置为127.0.0.1可以避免redis受外部攻击。另外使用requirepass配置项，可以设置访问redis服务器数据时先要输入密码。

一个小遗憾是redis只支持在配置文件中使用明文保存访问密码，这里提供一个动态生成配置文件的思路增加安全性：

首先将redis.conf备份成redis.conf.tml，在里面的requirepass配置好密码密文。

在启动redis服务前使用其它程序读取redis.conf.tml的requirepass配置项，把密文解密，替换requirepass值生成redis配置文件redis.conf.，启动redis服务后把redis.conf删除，这样就达到保密效果。

设置最大内存及内存淘汰策略

为避免redis占用内存无限膨胀，导致把系统内存耗尽，建议将maxmemory设置为1024mb。（实际用ps命令查看，会发现redis-server最多会使用比maxmemory多一些的内存）

同时配置内存淘汰策略maxmemory-policy为allkeys-lru，让redis在内存满时在所有的key中使用LRU算法对数据进行淘汰。

日志文件配置

Redis提供了logfile配置项，可以指定日志输出位置。但默认情况下redis会把所有日志输出到同一个文件，天常日久，这个日志文件会越积越大。

建议修改redis的源码，把里面的redisLog函数改为按天输出日志。

持久化配置

由于我们只需要使用redis做数据库缓存，所以不需要持久化。也不需要担心redis重启出现“缓存雪崩”的现象，因为我们业务服务器有很多台，不会同时重启。

单台业务服务器tps有限，缓存清零对数据库也不会产生太大压力。

关闭持久化方法把原来的save配置屏蔽，增加save ""

慢查询配置

设置slowlog-log-slower-than 5000，把所有响应时间大于5ms的请求记录起来，方便出故障时定位问题。

高风险命令配置

有一些redis命令会消耗redis服务器比较多资源，导致查询缓存效率下降。为了防止新手误操作，我们可以把这些命令改名，配置如下：

rename-command MONITOR "DANGEROUS_CMD_MONITOR"

rename-command FLUSHALL "DANGEROUS_CMD_FLUSHALL"

rename-command FLUSHDB "DANGEROUS_CMD_FLUSHDB"

rename-command CONFIG "DANGEROUS_CMD_CONFIG"

rename-command KEYS "DANGEROUS_CMD_KEYS"

优化前后性能测试比较

优化前：

[huangcihui:/home/huangcihui] redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000  -k 1 -e  -q -r 10000  -d 512

PING_INLINE: 56148.23 requests per second

PING_BULK: 55617.35 requests per second

SET: 57570.52 requests per second

GET: 56085.25 requests per second

INCR: 55309.73 requests per second

LPUSH: 54764.51 requests per second

RPUSH: 57570.52 requests per second

LPOP: 54644.81 requests per second

RPOP: 54884.74 requests per second

SADD: 50327.12 requests per second

HSET: 58445.36 requests per second

SPOP: 53191.49 requests per second

LPUSH (needed to benchmark LRANGE): 54945.05 requests per second

LRANGE_100 (first 100 elements): 11693.17 requests per second

LRANGE_300 (first 300 elements): 3824.09 requests per second

LRANGE_500 (first 450 elements): 2342.19 requests per second

LRANGE_600 (first 600 elements): 1671.12 requests per second

MSET (10 keys): 40192.93 requests per second

[huangcihui:/home/huangcihui] redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000  -k 1 -e  -q -r 10000  -d 512

PING_INLINE: 55340.34 requests per second

PING_BULK: 54854.64 requests per second

SET: 53937.43 requests per second

GET: 54347.82 requests per second

INCR: 52910.05 requests per second

LPUSH: 54674.69 requests per second

RPUSH: 51894.13 requests per second

LPOP: 53676.86 requests per second

RPOP: 53022.27 requests per second

SADD: 53676.86 requests per second

HSET: 55401.66 requests per second

SPOP: 56085.25 requests per second

LPUSH (needed to benchmark LRANGE): 54347.82 requests per second

LRANGE_100 (first 100 elements): 11160.71 requests per second

LRANGE_300 (first 300 elements): 3383.98 requests per second

LRANGE_500 (first 450 elements): 2246.33 requests per second

LRANGE_600 (first 600 elements): 1592.66 requests per second

MSET (10 keys): 37622.27 requests per second

[huangcihui:/home/huangcihui] redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000  -k 1 -e  -q -r 10000  -d 512

PING_INLINE: 54734.54 requests per second

PING_BULK: 54024.85 requests per second

SET: 54854.64 requests per second

GET: 52798.31 requests per second

INCR: 55463.12 requests per second

LPUSH: 55432.37 requests per second

RPUSH: 55834.73 requests per second

LPOP: 54495.91 requests per second

RPOP: 53705.69 requests per second

SADD: 52521.01 requests per second

HSET: 54229.93 requests per second

SPOP: 54585.15 requests per second

LPUSH (needed to benchmark LRANGE): 55648.30 requests per second

LRANGE_100 (first 100 elements): 11225.86 requests per second

LRANGE_300 (first 300 elements): 3598.29 requests per second

LRANGE_500 (first 450 elements): 2222.77 requests per second

LRANGE_600 (first 600 elements): 1620.25 requests per second

MSET (10 keys): 38684.72 requests per second

优化后：

[huangcihui:/home/huangcihui] redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000  -k 1 -e  -q -r 10000  -d 512 -a pass123

PING_INLINE: 51361.07 requests per second

PING_BULK: 46838.41 requests per second

SET: 49043.65 requests per second

GET: 50150.45 requests per second

INCR: 51786.64 requests per second

LPUSH: 55493.89 requests per second

RPUSH: 50150.45 requests per second

LPOP: 56915.20 requests per second

RPOP: 55928.41 requests per second

SADD: 56369.79 requests per second

HSET: 58651.02 requests per second

SPOP: 57703.40 requests per second

LPUSH (needed to benchmark LRANGE): 56593.10 requests per second

LRANGE_100 (first 100 elements): 11723.33 requests per second

LRANGE_300 (first 300 elements): 3954.76 requests per second

LRANGE_500 (first 450 elements): 2504.95 requests per second

LRANGE_600 (first 600 elements): 1733.61 requests per second

MSET (10 keys): 44444.45 requests per second

[huangcihui:/home/huangcihui] redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000  -k 1 -e  -q -r 10000  -d 512 -a pass123

PING_INLINE: 57339.45 requests per second

PING_BULK: 56561.09 requests per second

SET: 56116.72 requests per second

GET: 56625.14 requests per second

INCR: 57142.86 requests per second

LPUSH: 59880.24 requests per second

RPUSH: 51387.46 requests per second

LPOP: 51599.59 requests per second

RPOP: 51334.70 requests per second

SADD: 55865.92 requests per second

HSET: 57937.43 requests per second

SPOP: 58719.91 requests per second

LPUSH (needed to benchmark LRANGE): 56625.14 requests per second

LRANGE_100 (first 100 elements): 11845.53 requests per second

LRANGE_300 (first 300 elements): 3999.20 requests per second

LRANGE_500 (first 450 elements): 2414.70 requests per second

LRANGE_600 (first 600 elements): 1702.16 requests per second

MSET (10 keys): 39494.47 requests per second

[huangcihui:/home/huangcihui] redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000  -k 1 -e  -q -r 10000  -d 512 -a pass123

PING_INLINE: 51786.64 requests per second

PING_BULK: 38417.21 requests per second

SET: 55524.71 requests per second

GET: 39047.25 requests per second

INCR: 44822.95 requests per second

LPUSH: 53276.50 requests per second

RPUSH: 58582.31 requests per second

LPOP: 57208.24 requests per second

RPOP: 55066.08 requests per second

SADD: 52910.05 requests per second

HSET: 55187.64 requests per second

SPOP: 57405.28 requests per second

LPUSH (needed to benchmark LRANGE): 57570.52 requests per second

LRANGE_100 (first 100 elements): 10960.11 requests per second

LRANGE_300 (first 300 elements): 3794.20 requests per second

LRANGE_500 (first 450 elements): 2355.44 requests per second

LRANGE_600 (first 600 elements): 1705.41 requests per second

MSET (10 keys): 44130.62 requests per second

经优化后运行效率会有小提升

使用约定

集群

Redis提供三种集群模式，分别是主从，哨兵，分片三种。但因为我们只打算做为单机缓存，所以不需要配置。

合理使用数据库和键名前缀区分业务

Redis提供了多数据库配置，最多支持256个数据库。我们可以规定不同业务模块使用不同的数据库，这样可以避免数据库主键名称冲突。

但即使同一业务模块，也经常容易出现主键名称相同的情况，所以键名需要制定一些规范：统一使用”前缀:” + 具体值。

例如set uname:13560453764 huangcihui

前缀可以使用excel管理起来，这样基本可以解决键名冲突问题。

失效时间

最好对所有键设置失效时间，失效时间最好是某个范围内的随机数，这样可以避免缓存同时失效的情况。

压测

部署redis前最好先执行压测命令，看一下性能是否有异常。如果有异常需要考虑是否调整操作系统参数。

redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000 -k 1 -e -a pass123 -q

注意需要使用-k参数，设置长连接，不然测试结果性能会差很多。（我的机器上测试相差5倍）

原文地址：https://www.cnblogs.com/kingstarer/p/12400574.html

时间： 2024-10-10 16:25:01

Redis做为单机缓存使用建议的相关文章

Spring整合Redis做数据缓存（Windows环境）

当我们一个项目的数据量很大的时候,就需要做一些缓存机制来减轻数据库的压力,提升应用程序的性能,对于java项目来说,最常用的缓存组件有Redis.Ehcache和Memcached. Ehcache是用java开发的缓存组件,和java结合良好,直接在jvm虚拟机中运行,不需要额外安装什么东西,效率也很高:但是由于和java结合的太紧密了,导致缓存共享麻烦,分布式集群应用不方便,所以比较适合单个部署的应用. Redis需要额外单独安装,是通过socket访问到缓存服务,效率比Ehcache低,但

使用Redis做MyBatis的二级缓存

1. 介绍使用mybatis时可以使用二级缓存提高查询速度,进而改善用户体验. 使用redis做mybatis的二级缓存可是内存可控<如将单独的服务器部署出来用于二级缓存>,管理方便. 2. 使用思路 2.1 配置redis.xml 设置redis服务连接各参数 2.1 在配置文件中使用 <setting> 标签,设置开启二级缓存: 2.2 在mapper.xml 中使用<cache type="com.demo.RedisCacheClass" /&g

springboot2.0+redis实现消息队列+redis做缓存+mysql

本博客仅供参考,本人实现没有问题. 1.环境先安装redis.mysql 2.springboot2.0的项目搭建(请自行完成),本人是maven项目,因此只需配置,获取相应的jar包,配置贴出. <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifact

Redis安装（单机及各类集群，阿里云）

Redis安装(单机及各类集群,阿里云) 前言上周,我朋友突然悄悄咪咪地指着手机上的一篇博客说,这是你的博客吧.我看了一眼,是之前发布的<Rabbit安装(单机及集群,阿里云>.我朋友很哈皮地告诉我,我的博客被某个Java平台进行了微信推送.看到许多人阅读,并认同了我的博客,心理还是很开心的. 好了,话题收回来.这次就Redis在实际服务器中的各种安装,进行详细描述. 另外由于内容较多,并不一定能涵盖各个方面,万望见谅.如果存在什么问题,或者有什么需要添加的,请私信或@我. 最后,由于打马赛

Redis for Windows(C#缓存)配置文件详解

Redis for Windows(C#缓存)配置文件详解前言在上一篇文章中主要介绍了Redis在Windows平台下的下载安装和简单使用http://www.cnblogs.com/aehyok/p/3478282.html.当然我也在上一篇中指定过配置文件,并且修改其中的端口port.本文将主要来探讨redis强大的配置文件. 我现在使用的redis版本为2.6.首先奉上配置文件的源文件. # Redis configuration file example # Note on unit

程序员修神之路--redis做分布式锁可能不那么简单

菜哥,复联四上映了,要不要一起去看看? 又想骗我电影票,对不对? 呵呵,想去看了叫我呀看来你工作不饱和呀哪有,这两天我刚基于redis写了一个分布式锁,很简单不管你基于什么做分布式锁,你觉得很简单吗?来来来在计算机世界里,对于锁大家并不陌生,在现代所有的语言中几乎都提供了语言级别锁的实现,为什么我们的程序有时候会这么依赖锁呢?这个问题还是要从计算机的发展说起,随着计算机硬件的不断升级,多核cpu,多线程,多通道等技术把计算机的计算速度大幅度提升,原来同一时间只能执行一条cpu指令的时代已

redis做RDB时请求超时case

最近在排查redis做rdb时会有部分请求超时的case.初步判断是我们redis服务器上开启了THP(Transparent Huge Pages). 1) Linux本身的页大小是固定的4KB,在2.6.38内核新增了THP,透明地支持huge page(2MB)的使用,并且默认开启.开启THP的优势在于: - 减少page fault.一次page fault可以加载更大的内存块. - 更小的页表.相同的内存大小,需要更少的页. - 由于页表更小,虚拟地址到物理地址的翻译也更快. 劣势在于

redis作为mysql的缓存服务器(读写分离) （转）

一.redis简介Redis是一个key-value存储系统.和Memcached类似,为了保证效率,数据都是缓存在内存中.区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步.在部分场合可以对关系数据库起到很好的补充作用.它提供了Java,C/C++(hiredis),C#,PHP,JavaScript,Perl,Object-C,Python,Ruby等客户端,使用很方便. 二.架构图<ignore_js_

(转)Memcache,Redis,MongoDB（数据缓存系统）方案对比与分析

Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求. 二.解决方案: 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 (这里仅从数据缓存方面考虑,当然,后期可以采用Hadoop+HBase+Hive等分布式存储分析平台) 三.主流解Cache和数据库对比: 上述技术基本上代表了当今在数据存储方面所有的实现方案,其中主要涉及到了普通关系型数据库(MySQL/PostgreSQL),NoSQL数据