香港服务器redis慢(香港服务器速度慢)
- 香港服务器
- 2022-12-20 00:27:26
- 7
本篇文章给大家谈谈香港服务器redis慢,以及香港服务器速度慢对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
本文目录一览:
redis读写瓶颈
从你这个描述来看,写性能确实不太正常。
我有一种方法可以用来看一下你这50000条数据是不是超过了默认的maxmemory值:
统计一下10000条数据大约占的内存值,估计5W条记录的大约内存值,然后再看一下你的VM是否开启。这样做是因为超过了指定的内存同时没开启vm时,有可能会导致进程挂掉。
你既然使用了默认配置,你还可以看一下日志里是不是会有崩溃记录。也可以根据记录找一下其他的原因。
你用的是hash结构的话,可以调整一下hash-zipmap-max-entries这个参数。一般这个参数在1000的时候性能是比较高的。超过1000以后CPU就上来了。默认是512.
Redis为什么会那么快?
最近学习了一下Redis写一篇文章来总结一下学习成果,学习的方式主要是看书,看的是Redis 5设计与源码分析;想系统学习的同学,可以好好看看很推荐这本书,那么,为什么标题选择Redis为什么会那么快?因为,我在学习的过程中,感受到Redis的精髓就是快,为了快这个属性,它有了很多自己特殊设计及实现;
Redis快,我主要是基于三大部分的理解
下面分别对这2,3部分进行展开:
首先,先要知道Redis工作线程是单线程的,但是,整个Redis来说,是多线程的;
Redis事件处理 :
Redis 服务器是典型的事件驱动程序,而事件又分为文件事件(socket 的可读可写事件)与时间事件(定时任务)两大类。已经注册的文件事件存储在event[]数组中, 时间事件形成链表;Redis 底层可以使用4中I/O多路复用模型(kqueue、epoll、select等)根据操作系统的不同选择不同, 关于,多路复用模型相关内容可以查看我的另一篇文章 操作系统IO进化史 所以,epoll本身就效率很高了;但是,随着我们网卡的不断升级,在Redis 6.0之后的版本中,对IO的处理变成了多线程;
为什么对IO的处理变成了多线程能提高速度?
下面是Redis6.0之前的情况:
如果到了Redis6.0之后:
所以,这也是Redis快的一个主要原因;
由于,Redis中设计的话,主要分为底层设计结构以及一些相应的功能,所以,特定将其分为2部分来进行讲解;
Redis底层数据结构有简单动态字符串,跳跃表,压缩列表,字典,整数集合;针对,简单动态字符串,压缩列表,主要是考虑到节约内存;像跳跃表,字典,主要是考虑到查询速度,整数集合即考虑到了空间又考虑到了时间;其实像字典中的渐进式rehash,以及间断key查找,都是考虑到了节约时间;具体的内容可以查看我的另一篇文章, Redis底层数据结构
具体细节可查看官网
优点:最多有25%的过期key存在内存中,这种方法会比轮询更加省时间;就是稍微牺牲内存,来保证 redis的性能,就是快; 还是以空间换时间的思想;
注意 :个人觉得这里和 缓存雪崩 还能建立其联系,如果,一个大型的redis实例中所有的key在同一时间过期了,那么,redis会持续扫描keys 因为,一直大于25%;虽然,这是有扫描时间的上限的25ms;这个时候,刚好客户端请求过来了,如果,客户端将超时时间设置的比较短,比如说10ms,那么就会出现大量链接因为超时而关闭,业务端也会出现很多异常。(客户端超时时间,如果说设置得太小,那么容易导致访问redis失败,如果,设置太大,那么,在redis异常的时候,不容易及时作出切换;一般是通过网络延迟和redis慢日志来进行查看的)
redis的特点是快,它虽然有事务,但是,它是没有回滚的,事务的功能是不够完善的; 回滚:代表失败时,回滚到事务开始的时刻;
redis 是单线程的 如果,有多个客户端,一个客户端的事务 并不会阻塞到其他客户端; 客户端1 发送 开启事务的标记 客户端2 也开启事务 。随着时间发展;2又连续发了一些命令 1 也发了一些命令; 这时候,会先看谁的执行指令先到; 假设 2 先到达,这个时候,先执行2 的相关数据,在执行1相关的命令; 如果 1 先到达,这个时候,先执行1 的相关命令,再执行2;
事务失败处理
这个时候,会发现报错那条语句不执行,剩下的语句都会进行执行;也没有发生了回滚;
证明 :redis是不支持事务回滚的。在运行期错误,即使事务中有某条/某些命令执行失败了,事务队列中的其他命令仍然会继续执行 -- Redis 不会停止执行事务中的命令;
为什么Redis 不支持事务回滚?
总结 :Redis为了快,而不支持事务回滚;
在redis中,有两个东西 第一个为RDB , 第二个为AOF RDB为快照/副本相关内容, AOF为日志相关的内容;
RDB的特点 :1.需要时点性 (比如说:我有1G的内存,需要持久化到硬盘,比如说:一个小时持久化一次。那么,假设在8点,就需要进行持久化)
如何实现RDB持久化呢?
方法一:阻塞Redis ,Redis不再对外提供服务了,但是,这种方式是需要阻塞的,很显然,如果,这个持久化需要花费1s,那么,这个时候,Redis 不能被客户端进行使用;
方法二:非阻塞 Redis继续对外提供服务;
但是,这个时候会出现一个问题;比如说:8点开始RDB持久化,8点零1秒才持久化完,问题就来了:持久化的数据是8点的还是8点零1秒的呢?很显然,是8点的;那么,在8点到8点零1秒这个过程中,数据是会发生改变的,那么, 怎么解决这个数据不一致的问题呢? 比如说:8点的时候,b = 10 到 8点零1秒的时候,b =20;
为了解决这个读写并存 使用CopyOnWrite 的思想来进行实现;
就是,在操作系统中,先使用fork() 创建子线程来复制一份副本(注意:这里拷贝的是指针,所以,速度会很快)然后,这个副本,就保持在8点不变了。然后,复制的时候,就复制这份副本就行了,对数据增删改查就在父进程中更改。
但是,因为父子进程都指向的是同一个内存,所以,不能在这个内存中改,比如说:不能在原来key 8 中进行更改,比如说要改key = 10 那么,就得在内存中,再创建一块区域,然后,让父进程中指针指向新的key ,这样两个进程就不会相互影响了。
这里也验证了Redis是多线程的;
具体实现:
RDB的缺点
RDB的优点 :恢复数据的速度相对较快;
Redis内存大小选择 进程一般使用10G以内,因为从内存到磁盘持久化这个过程,如果说,10G需要写的时间比较久,那么,如何解决呢?1. 减少内存 2. 硬盘选择固态硬盘;
针对RDB容易丢失数据的问题,提出了AOF持久化机制
AOF : append on File 向文件中,进行追加;redis发生写操作时,会记录到文件中;
优点 :1.丢失的数据比较少
背景 :RDB和AOF可以同时开启,如果,开启了AOF只会用AOF来进行恢复,即便RDB也开启了,也不会使用它;因为,AOF的修复比较准确;但是,AOF是比较慢的,所以,在4.0以后,AOF就包含了RDB全量,和增加的新的写操作。这样来提高速度;
缺点 :由于,AOF是增加的方式,所以,如果一直增加的话,就会有 1.体量无限变大 2.恢复慢 的缺点;为了解决这个问题,需要设计出一个方案让日志AOF足够小;这个,就有了 重写 的方案;4.0之前,重写方案是将AOF进行瘦身,比如说:把创建key和删除key的命令进行抵消删除;4.0之后,就采用 混合持久化 比如说:我这个AOF已经到了100M文件了,这个时候,我先将老的数据变成RDB文件(二进制文件)然后,再存储到AOF中,再将增量以指令的方式Append 到AOF。所以,是一个混合体;这里的AOF日志不再是全量的日志,而是持久化开始到持久化结束这段时间的增量AOF日志通常很小;那么,它这么改变的 优点 是:在Redis重启时,可以先加载RDB的内容,在加载增量AOF日志,完全替代AOF全量日志重放,重启的效率将大幅度提升; 每次一重写完,就会变成RDB ;
脏数据刷入时机 :AOF日志是以文件形式存在的,当程序对AOF日志进行写操作时, 实际上是先将数据写到一个内存缓存中,然后,让内存再把脏数据写回到磁盘中 那么,什么时候写呢?如果,还没来的及写就宕机了,那么可能会出现日志丢失;这时候有三个级别可以调;
no : 不调用fsync 等到它满了再进行调用(fsync 可以将指定文件的内容,强制从内核缓存刷到磁盘) 一般生产环境不用
always :每写了一个数据,就调用一次fsync 一般生产环境不用
everysec: redis每一秒调用一次flush
一般Redis 的主节点不会进行持久化操作,持久化操作主要是在从节点中进行。因为,没有来自客户端请求的压力;
上面是Redis持久化的两种方式 由于,持久化过程需要花费的时间是比较多的,所以,一般由从节点来进行持久化操作; 主服务器发现需要执行完整重同步时,会fork子进程执行RDB持久化,并将持久化数据发送给从服务器。这时候,有两种选择 1. 直接通过Socket发送给从服务器(从服务器支持eof),2. 持久化数据到本地文件,待持久化完毕后再将该文件发送给从服务器。 默认第二种,具体情况是根据同步信息确定;但是,第一种效率会更高,速度会更快;
总结 :为了Redis快的特性,Redis在持久化的时候,使用fork()函数,新开线程来执行;同时,如果主从服务器的话,还提供了psync2来进行部分重同步;eof功能;
redis的特点就是快,在系统设计的方方面面都体现了这个快的特性;这是我自己在学习Redis相关知识时,了解到的内容,做个记录。如果,有偏差欢迎读者进行指正!
如何解决redis高并发客户端频繁time out
可以把你应用的部署环境描述下,使用什么样的客户端,长连接还是短连接,redis是单机环境还是集群环境,redis是否配置了持久化,什么样的持久化方式,还有就是redis服务器的硬件设施,把这些描述清楚然后再分析原因。
java连接redis超时问题怎么解决
应该是redis本身的服务有问题了
本文所针对的连接超时问题所涉及的相关元素如下:
Redis客户端: Jedis (java)
Redis版本 :2.8.12
Redis部署操作系统类型:Linux
正文开始:
No 1.Redis执行大命令(时间复杂度为O(N)的命令)
问题剖析:
a.Redis服务器端通过单线程处理命令,一旦有大命令被执行,Redis将无法及时响应来自客户端的任何命令
关于Redis大命令的监控,可以查看slowlog来观察
b.在使用jedis作为redis客户端时,当redis连接池的配置参数testOnBorrow=true时,默认会在获取redis连接
时,先执行redis的ping方法,而基于原因a,此时redis将无法及时响应,自然会报出time out异常
如何解决:
a.尽量避免使用时间复杂度为O(N)的命令
b.如果无法避免使用时间复杂度为O(N)的命令,则应降低其使用频率,避免在业务高峰期时使用
No 2.Redis单次操作数据包过大
问题分析
a.单次操作数据包过大,且操作频繁,极有可能会导致网络拥堵
b.在使用jedis作为redis客户端时,当redis连接池的配置参数testOnBorrow=true时,默认会在获取redis连接
时,先执行redis的ping方法,而基于原因a,此时redis将无法及时响应,自然会报出time out异常
如何解决:
a.排查代码,确定是否存在大数据(数据条目过多/单条数据过大)操作,将其进行改造,改造方案有两个:
a1.数据拆分,变更数据类型(常见的情况是将java中的collection类型序列化后存入redis的String数据
类型中),如将String数据类型调整为hash/list/set等,这常用于解决单条数据量过大的情况
a2.调整业务逻辑,减少单次数据查询范围(常见的情况如将redis中的整个hash数据取回,在应用程序内存中获取需要的entry),如使用hget等单条查询命令替换hgetall命令
Redis-代理(解决redis压力)
如果没有反向代理,一台Redis客户端需要跟很多个客户端连接:
看着是不是很懵逼?没关系,主要连接需要消耗线程资源,没有代理的话,Redis要将很大一部分的资源用在与客户端建立连接上,Redis的高可用和可扩展性,无论是自带的Sentinel还是Cluster都要求客户端进行额外的支持,而目前基本上没有合适的客户端能够做这些事情,客户端来做这些事情也并不合适,它会让维护变的跟糟糕。
因此客户端和Redis服务端之间加一层代理成了一种理想的方案,代理屏蔽后端
Redis实现细节想客户端提供Redis服务,可以完美的解决Redis的高可用和扩展性的问题。
很简单,将请求链接到代理服务器上,有Proxy负责将请求转发到后面的Redis服务器实例:
那么问题来了,如果Proxy挂了呢?
所以Proxy需要做集群,前面再加一层负载均衡(LVS),而其单机也存在故障的风险,所以整一个主备,备机通过KeeAlived来检测主LVS的健康状况,出现故障自动切换过去:
Redis Cluster 的实现方案十分的聪明,它的分区方式采用了虚拟槽分区。
Redis Cluster 首先会预设虚拟槽,每个槽就相当于一个数字,有一定范围,每个槽映射一个数据子集。
Redis Cluster中预设虚拟槽的范围为 0 到 16383
————————————————————
坐标帝都,白天上班族,晚上是知识的分享者
如果读完觉得有收获的话,欢迎点赞加关注
关于香港服务器redis慢和香港服务器速度慢的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
本文由admin于2022-12-20发表在靑年PHP官网,如有疑问,请联系我们。
本文链接:https://qnphp.com/post/151962.html