加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 移动互联 > 正文

除了缓存,Redis都解决了哪些问题?

发布时间:2019-05-10 15:39:40 所属栏目:移动互联 来源:Java芋道源码
导读:目次: 1 从零开始 2 基于本机内存的缓存 3 处事端的Redis 3.1 耐久化(Persistence) 3.2 哨兵(Sentinel)和复制(Replication) 3.3 集群(Cluster) 4 客户端的Redis 4.1 数据范例 4.2 事宜 4.3 Lua剧本 4.4 管道 4.5 漫衍式锁 总结 先看一下Redis是一个什么东

上面这一大段表明白这么多,不知有没有发明不管是第一个路子照旧第二个路子,都有一个配合的对象存在,那就是漫衍式处事中全部处事器以及其能提供的处事的信息。这些信息无论怎样也是要存在的,区别在于第一个路子是把这部门信息单独来打点,用这些信息来和谐后端的多个独立的redis处事器;第二个路子则是让每一个redis处事器都持有这份信息,互相知道对方的存在,来告竣和第一个路子一样的目标,利益是不再必要一个特另外组件来处理赏罚这部门工作。

Redis Cluster的详细实现细节则是回收了Hash槽的观念,即预先分派出来16384个槽:在客户端通过对Key举办CRC16(key)% 16384运算获得对应的槽是哪一个;在redis处事端则是每个处事器认真一部门槽,当有新的处事器插手可能移除的时辰,再来迁徙这些槽以及其对应的数据,同时每个处事器都持有完备的槽和其对应的处事器的信息,这就使得处事器端可以举办对客户端的哀求举办重定向处理赏罚。

4 客户端的Redis

上面的第三末节首要先容的是Redis处事端的演前进调,表明白Redis怎样从一个单机的处事,进化为一个高可用的、去中心化的、漫衍式的存储体系。这一末节则是存眷下客户端可以斲丧的redis处事。

4.1 数据范例

redis支持富厚的数据范例,从最基本的string到伟大的常用到的数据布局都有支持:

  • string:最根基的数据范例,二进制安详的字符串,最大512M。
  • list:凭证添加次序保持次序的字符串列表。
  • set:无序的字符串荟萃,不存在一再的元素。
  • sorted set:已排序的字符串荟萃。
  • hash:key-value对的一种荟萃。
  • bitmap:更细化的一种操纵,以bit为单元。
  • hyperloglog:基于概率的数据布局。

这些浩瀚的数据范例,首要是为了支持各类场景的必要,虽然每种范例都有差异的时刻伟大度。其拭魅这些伟大的数据布局相等于之前我在《解读REST》这个系列博客基于收集应用的架构气魄威风凛凛中先容到的长途数据会见(Remote Data Access = RDA)的详细实现,即通过在处事器上执行一组尺度的操纵呼吁,在处事端之间获得想要的缩小后的功效集,从而简化客户端的行使,也可以进步收集机能。好比假如没有list这种数据布局,你就只能把list存成一个string,客户端拿到完备的list,操纵后再完备的提交给redis,会发生很大的挥霍。

4.2 事宜

上述数据范例中,每一个数据范例都有独立的呼吁来举办操纵,许多环境下我们必要一次执行不止一个呼吁,并且必要其同时乐成可能失败。redis对事宜的支持也是源自于这部门需求,即支持一次性按次序执行多个呼吁的手段,并担保其原子性。

4.3 Lua剧本

在事宜的基本上,假如我们必要在处事端一次性的执行更伟大的操纵(包括一些逻辑判定),则lua就可以排上用场了(好比在获取某一个缓存的时辰,同时延迟其逾期时刻)。redis担保lua剧本的原子性,必然的场景下,是可以取代redis提供的事宜相干的呼吁的。相等于基于收集应用的架构气魄威风凛凛中先容到的长途求值(Remote Evluation = REV)的详细实现。

4.4 管道

由于redis的客户端和处事器的毗连时基于TCP的, 默认每次毗连都时只能执行一个呼吁。管道则是应承操作一次毗连来处理赏罚多条呼吁,从而可以节减一些tcp毗连的开销。管道和事宜的差别在于管道是为了节减通讯的开销,可是并不会担保原子性。

4.5 漫衍式锁

官方保举回收Redlock算法,纵然用string范例,加锁的时辰给的一个详细的key,然后配置一个随机的值;打消锁的时辰用行使lua脚原来先执行获取较量,然后再删除key。详细的呼吁如下:

  1. SET resource_name my_random_value NX PX 30000 
  2. if redis.call("get",KEYS[1]) == ARGV[1] then 
  3.  return redis.call("del",KEYS[1]) 
  4. else 
  5.  return 0 
  6. end 

总结

本篇着重从抽象层面来表明下redis的各项成果以及其存在的目标,而没有体谅其详细的细节是什么。从而可以聚焦于其办理的题目,依据抽象层面的观念可以使得我们在特定的场景下选择更吻合的方案,而非范围于其技能细节。

以上均是笔者小我私人的一些领略,假如不妥之处,接待指正。

【编辑保举】

  1. Redis 这么火,它都办理了哪些题目?
  2. Redis内存裁减计策,看这一篇就够了!
  3. Redis 敢在线上做Keys正则匹配操纵!你可以去职了!
  4. Ehcache、Memcache、Redis三大缓存较量
  5. 为什么单线程的Redis却能支撑高并发?
【责任编辑:未丽燕 TEL:(010)68476606】
点赞 0

(编辑:湖南网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读