高并发情况下Redis 的可用性测试与分析及部署架构说明
来源:互联网 发布:网络污词大全 编辑:程序博客网 时间:2024/05/01 09:31
一、Redis AOF模式设置
修改配置文件redis.conf参数:
appendonly yes
# appendfsync always
appendfsync everysec
# appendfsync no
二、测试方法
创建多线程,其中每一个线程执行一个无限循环向Redis 发送set key-value命令,由于处理器执行一次循环操作的速度非常快,因此这样每一个线程都模拟了一个多并发的情况。
<span style="font-size:18px;">class pushThread extends Thread { private JedisPool jedisPool;private Jedis jj;private String threadName;public pushThread(String threadName) { jedisPool = new JedisPool(new JedisPoolConfig(),"localhost"); jj = jedisPool.getResource(); this.threadName = threadName;}public void run() {int n = 1; for(;;) { jj.set("key" + threadName, "" + n); System.out.println(n + " has been set by " + threadName); n++; }}}</span>…
<span style="font-size:18px;">public static void main(String[] args) {for(int i = 0; i < 80; i++) {new pushThread("" + i).start();}}</span>
三、测试说明
1、读取Redis的timeout异常创建线程数在50以下时程序可以正常执行,当线程数设置为100以上时,某些线程执行出现异常:
java.net.SocketTimeoutException: Read timed out
造成这种异常可能有以下两个原因:
原因一:在连接Redis的Jedis的默认构造方法中,超时一般被默认设置为2000毫秒,也就是2秒。当然这个时间,对于Redis这种从内存中读取数据的数据库来说应该是相当大了,但是为什么还会超时?可能的原因是,当Redis的数据量很大时,可能在Redis server可能会出现超时。因为Redis在运行时,是单线程来处理所有的客户端的连接的。当连接数非常多或者数据量很大时,也要遵循FIFO的调度策略,这就造成等待队列过长,因此可能会出现超时的情况。
解决方法:尝试在调用jedis的构造方法时,将超时时间设置的更大些。
Jedis jedis = new Jedis("127.0.0.1", 8371,100000);//将超时时间设置为100000毫秒
原因二:因为Redis是基于TCP连接的,大量数据反复交互相当于远程读写内存的操作,势必会造成带宽的使用紧张,在带宽吃紧的情况下,Redis客户端即Jedis拿不到连接或拿不到后续数据包。
解决方法:最直接的方法是增加带宽,但针对这种问题,对并发交互数据的频率进行调整,对数据量进行精减才是解决这一问题的最佳方案。
2、AOF模式相关问题与快照模式的优点
创建50个线程,执行1分钟之后,每个线程大约循环了13800次,AOF日志(appendonly.aof)的大小是25.5M。Redis重启时会先加载appendonly.aof文件,加载25M配置文件大约耗时5秒。同时做了多次突然关闭Redis 的试验,日志记录准确没有出现丢失数据的情况。
AOF生成的命令日志,只是操作过程的记录文件,它的主要作用是保证高可用性。因为在高并发的情况下,AOF日志文件appendonly.aof会迅速变得很大(当我将线程数调整为50,1分钟appendonly.aof 的文件大小已达到了25M)。
Redis AOF rewrite(重新生成一份AOF文件)设置:
(1)Redis接收到客户端发送的BGREWRITEAOF指令请求,执行AOF rewrite;
(2)在Redis配置文件redis.conf中,如果用户设置了auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数,当AOF日志文件大小大于auto-aof-rewrite-min-size,同时AOF文件大小的增长率大于auto-aof-rewrite-percentage时,会自动触发AOF rewrite;
另外需要注意的是根据网上反馈AOF曾经出现过,因为个别命令导致 AOF 文件在重新载入时,无法恢复原样的问题。
快照模式的优点是:日志的内容更加紧凑,可以在加密后保存到其他数据中心或者亚马逊 S3;快照可以最大化 Redis 的性能:父进程在保存快照文件时唯一要做的就是生成一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作;
快照在恢复大数据集时的速度比 AOF 的恢复速度要快。一个原因是快照文件中每一条数据只有一条记录,不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是快照文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要小于AOF日志的加载。
四、部署架构说明
结合以上分析,建议采用如下的部署方式:Redis Master上不做持久化保证读写性能,Slave上同时开启RDB(快照)和AOF,保证数据的安全性。当 Redis启动时,程序会优先使用 AOF 文件来恢复数据集,因为AOF文件所保存的数据通常是最完整的。
在服务器运行时对 RDB 文件进行备份。RDB文件一旦被创建,就不会进行任何修改,当服务器要创建一个新的RDB文件时,它先将文件的内容保存在一个临时文件里,当临时文件写入完毕才会替换原来的RDB文件,因此备份RDB文件都是相对安全的。
1 0
- 高并发情况下Redis 的可用性测试与分析及部署架构说明
- Redis 高可用性部署
- redis集群部署的高可用性
- 高并发下redis的瓶颈分析
- 部署高可用的Redis集群架构
- 高并发测试下的一些问题及解决
- 高并发测试下的一些问题及解决
- 高并发测试下的一些问题及解决
- Redis HA高可用性测试方案
- 高并发架构设计与原理分析
- Tachyon框架的Worker心跳及Master高可用性分析
- 互联网架构设计 (高并发高可用性)
- 测试Nginx 和 Tomcat 高并发情况下处理静态页面的性能
- 集群与负载均衡系列(8)——redis主从复制+哨兵实现高可用性架构
- 基于nginx和redis架构的高并发框架的设计与研究
- 基于nginx和redis架构的高并发框架的设计与研究
- Tachyon高可用性集群模式的部署
- 大型高并发高负载网站的系统架构分析
- spring quartz 时间配置格式
- epoll和poll剖析
- node的serve-favicon中间件的使用
- 最短路径—Dijkstra算法和Floyd算法
- FragmentTabHost 得到当前显示的Fragment对象
- 高并发情况下Redis 的可用性测试与分析及部署架构说明
- 在eclipse里配置Hadoop开发环境
- Android网络请求开源框架Volley快速使用指南(2)——异步获取图片
- 在Eclipse中集成Genymotion模拟器插件
- sysfs接口函数的建立_DEVICE_ATTR
- C语言中的循环结构
- shell脚本截取日期处理
- 的南方就开始改口费疯狂的复古风飞
- Windows下安装Python模块的方法