首页
BOB网页客户端
BOB体育官网登陆
BOB注册首页

BOB体育官网登陆

你的位置:BOB(中国)官方入口-BOB投注网页版 > BOB体育官网登陆 > BOB体育官网登陆 一文晓畅大数据下Redis的行使

BOB体育官网登陆 一文晓畅大数据下Redis的行使

发布日期:2021-10-19 23:11    点击次数:92

 

大数据下Redis的行使 1、Redis客户端区别 1.1redis常用客户端

现在市面上比较通走的客户端有jedis、lettuce、redissonBOB体育官网登陆

jedis

jedis客户端连接手段是基于TCP壅塞手段

lettuce

lettuce内部是基于netty的众路复用异步非壅塞手段

redisson

相对于上面两栽行使得较少

在并发数目不大的情况下,两者性能能够差不众,jedis的性能能够还优于lettuce,但当并发量的升迁,jedis的超时舛讹会增补,但lettuce只是平均反答时间增补和最大反答时间会增补,lettuce是已安详性为主的。

1.2epoll模型-单线程的redis为什么快

redis内部行使epoll模型挑高链接处理能力

传统TCP链接与epoll模型的内心区别

TCP链接存在链接数瓶颈,随着连接数的增补,反答速度会清晰变慢

epoll可声援更大数目的连接数而不会对性能有清晰的影响

2、大数据下的redis的存储方案 2.1分片模式

分片模式是把安放众个redis节点,然后由客户端决定数据分片规则,常见的分片规则就所以节点数目进走哈希分片

益处:

服务端不必要进走繁琐的配置,由客户端决定路由规则

弱点:

弱点很清晰,倘若众个节点中的某个节点挂了,将丢失这一片面数据,由于客户端照样为每个节点分配了连接,而且客户端配置分片节点IP的时候要仔细

IP列外的挨次不克肆意指定挨次,IP变更也会影响数据,扩容相等麻烦。

提出:倘若分片节点较少能够行使分片正当的分摊压力

配置示例:

spring :            remote :       ecredis :         type : sharding         uri :                    - 192.168.1.3:6379                    - 192.168.1.4:6379                    - 192.168.1.5:6379                    - 192.168.1.6:6379                    - 192.168.1.7:6379         db : 1         maxIdle : 10         minIdle : 5         maxActive : 10         password : GpG4fZoxsp7cTB5f         keyPrefix : 'ERP:EXPORT-CENTER:' 
2.2哨兵机制

在Redis2.8版本最先引入,就有了哨兵这个概念,哨兵实现了自动化的故障恢复,无需关心IP是否变更。

益处:

哨兵模式是基于主从模式的,一切主从的益处,哨兵模式都具有。

主从能够自动切换,编制更雄壮,可用性更高。

Sentinel会不息的检查主服务器和从服务器是否平常运走。当被监控的某个Redis服务器展现题目,Sentinel经过API脚本向管理员或者其他的行使程序发送告诉。

弱点:

Redis较难声援在线扩容BOB体育官网登陆,对于集群,容量达到上限时在线扩容会变得很复杂。

spring :   redis :     password : 123456     sentinel :       master : master       nodes : 47.98.217.106:26379,47.98.217.109:26380,47.98.217.109:26381     timeout : 20000     database : 0     jedis :       pool :         max-active : 300         max-wait : -1         max-idle : 100         min-idle : 20 
2.3rediscluster集群

经过数据分片的手段进走数据共享题目,同时挑供数据复制和故障迁移功能,包含了哨兵模式的一切功能。

益处:数据按slot松散存储,访问任何一个master节点都能够获取任何分片上面的数据,任何一个master节点都能够做扩容或者新添master节点的时候,数据会自动分片同步迁移,服务器不必要下线。倘若每个master行使了主从模式,那么当master发生故障的时候,下面的slave们会选举一个新的master

弱点:必要行使ruby进走安放,配置相等麻烦,维护不方便

配置示例:

spring :   redis :     password :     cluster :       nodes : 192.168.1.3:6379,192.168.1.4:6379,192.168.1.5:6379       max-redirects : 3     lettuce :       pool :         max-idle : 16         max-active : 32         min-idle : 8 
2.4cachecloud

cachecloud是一套解决方案,实现众栽类型自动安放、解决Redis实例碎片化形象、挑供完善统计、监控、运维功能、缩短运维成本和误操作,挑高机器的行使率,挑供变通的伸缩

益处:

使配置更浅易,集群节点不再由客户端维护,配置一个domain即可自动获取节点列外

配置示例:

spring :            domain : cachecloud.server1.com:8080            remote :       ecredis :                  appid : 2         type : cloud         uri :         db : 1         maxIdle : 10         minIdle : 5         maxActive : 10         password : GpG4fZoxsp7cTB5f         keyPrefix : 'ERP:EXPORT-CENTER:' 

行使案例:

2.5redis存储方案选型

吞吐量数据量较少、数据坦然性不高:单机模式或者分片模式

吞吐量数据量较大、数据坦然性较高:哨兵模式、集群模式

吞吐量数据量大、数据坦然性高、扩展性强:集群模式

3、性能优化 3.1日志优化

Redis日志存储模式分为两栽:RDB和AOF,RDB为实时写入磁盘,AOF为延宕批量写入磁盘

RDB模式:

益处:实时存储日志,在数据恢复方面更有上风

弱点:磁盘IO比较屡次,会影响redis的吞吐能力

AOF模式:

益处:准时批量刷新日志到磁盘,正当高吞吐的场景,对redis性能影响较幼

弱点:倘若某一个时刻redis发生故障,能够会丢失内存中的数据,故障恢复的时候恢复不了这片面数据

模式选择:

倘若吞吐量较幼,行使RDB即可,吞吐量较大,能够选择AOF挑高性能,两栽手段按照详细场景选择

AOF配置:

appendonly yes #aof文件名竖立 appendfilename "appendonly-${port}.aof" #配置选择 appendfsync everysec dir /bigdiskpath #不开启aof重写,由于太消耗性能 no-appendfsync-on-rewrite yes 

AOF重写:分析现在redis中key对答的值优化指令,缩短磁盘空间和压力,但由于必要判定相符并逻辑,会有很大的性能支付,清淡不开启aof重写

# 倘若服务器对键list实走了以下命令; 127.0.0.1:6379> RPUSH list "A" "B"  "G" 127.0.0.1:6379> 

平常AOF会把前线的6条写入命令都存入日志中,AOF重写会先去redis获取list的值,BOB体育官网登陆发现是["C""D""E""F""G"]然后生成一条 RPUSHlist"C""D""E""F""G" 代替前线6条

3.2缓存更新策略

redis默认情况下就是行使LRU策略的由于内存是有限的但是倘若你不息地去redis内里写入数据那肯定是没法存放下一切的数据在内存的

noeviction:倘若内存行使达到了maxmemoryclient还要不息写入数据那么就直接报错给客户端

的key才会清算失踪

allkeys-random:随机选择一些key删除失踪

volatile-random:随机选择一些竖立了TTL的key删除失踪

volatile-ttl:移除失踪片面keys选择那些TTL时间比较短的keys

除了LRU还能够行使scan的手段进走轮询ttl的手段清算

3.3代码中行使redis的一些提出

避免行使keys*这栽暧昧查询会壅塞现在线程行使scan的手段去处理redis客户端提出不要行使redisdesktopmanager

String cursor = ScanParams . SCAN_POINTER_START ; ScanParams scanParams = new ScanParams  {                       break ;            } } 

hgetall也答该避免行使行使hscan代替但倘若经过RedisTemplate回调的手段行使hscan答该仔细资源的开释否则会展现乞求到达肯定次数的时候就不克发首乞求的题目

倘若set的时候同时竖立expire过期时间不要先set再expire这栽手段答该行使原子操作

set key value [EX seconds] [PX milliseconds] [NX|XX] 

对于联相符个需求众次改版redis中写入差别格式的数据会产生兼容性题目能够行使type命令去处理兼容然后监控等老数据不存在之后再把判定逻辑移除

String type = jedis . type  {   // do something } 

倘若redis中的数据必要做去重能够行使set或hashmaphashmap性能更高但对于维护hashmap数据组织之外的数据比较众之前测试过100B的数据存放到hashmap但实际占用量能够有200B~300B甚至更众set对于数据众的情况下性能会矮一点

提出:数据少的情况下用set数据众就用hashmap但要仔细尽量缩短存储内容的长度比如{"source":"order"}能够改成{"s":1}

去重操作不提出行使list由于每次判定都要从list中取数据然后再add进去众线程操作下照样能够会展现重复题目

// 在众线程模式下会有题目 // 倘若线程A和线程B同时实走lrange List << span=""> String > list = jedis . lrange ; } 

倘若一次处理的命令许众行使pipeline性能更益

list能够结相符lpush/rpop、rpush/lpop实现队列功能但不提出把list当成是MQ的功能由于异国记录的状态无法跟踪数据处理情况

关于redis分布式锁现在通走的实现手段还异国完善的方案行使lua脚本的版本也不是完善的倘若需求批准延时或者一准时间内不批准实走众次setnx竖立过期时间是最益的方案

4、故障迁移与数据迁移 4.1数据迁移方案

老节点替换为新节点、新老key兼容处理

将新节点行为老节点的slave节点等数据自动同步完善之后下架老节点不提出行使代码迁移由于差别营业数据组织能够许众

差别类型的节点之间迁移的手段差别倘若单节点迁移至分片集群只能借助迁移工具完善

倘若新营业将行使新的key要保留旧key能够开启两个连接池一个处理新key一个处理旧key云云等旧key都失效的时候移除对旧key的连接就能够十足迁移到新key营业

动态扩容

必须在集群模式下才能够进走动态扩容也能够行使cachecloud数据会自动同步到各个节点

在数据迁移的过程中即使访问的某个key正在迁移数据也是能够平常返回的不必不安迁移过程会对数据访问造成影响

4.2故障迁移对于客户端的影响

redis集群模式固然能够在某个master节点发生故障的时候自动从slave中选举节点当master但相通jedis的客户端并不声援故障迁移也就是当集群某节点发生故障正在切换的时候客户端倘若正在访问故障节点这时集群故障迁移还异国完善客户端会报错倘若必要让客户端也声援故障迁移必要修改jedis客户端源码实现。

行使Kotlin重写AOSP日历行使Sentry监控之Discover大数据查询分析引擎聊聊分布式锁——Redis和Redisson的手段微柔升级Tips行使:让你迅速上手Windows11掌握各栽行使幼技巧将行使程序移动到云端必要清新的事项

Powered by BOB(中国)官方入口-BOB投注网页版 @2013-2021 RSS地图 HTML地图