详解Redis基

本文将从Redis的根基特征入手，通过报告Redis的数据布局和首要呼吁对Redis的根基手段举办直观先容。之后概览Redis提供的高级手段，并在陈设、维护、机能调优等多个方面举办更深入的先容和指导。

本文得当行使Redis的平凡开拓职员，以及对Redis举办选型、架构计划和机能调优的架构计划职员。

目次

• 概述
• Redis的数据布局和相干常用呼吁
• 数据耐久化
• 内存打点与数据裁减机制
• Pipelining
• 事宜与Scripting
• Redis机能调优
• 主从复制与集群分片
• Redis Java客户端的选择

概述

Redis是一个开源的，基于内存的布局化数据存储前言，可以作为数据库、缓存处事或动静处事行使。

Redis支持多种数据布局，包罗字符串、哈希表、链表、荟萃、有序荟萃、位图、Hyperloglogs等。

Redis具备LRU裁减、事宜实现、以及差异级此外硬盘耐久化等手段，而且支持副本集和通过Redis Sentinel实现的高可用方案，同时还支持通过Redis Cluster实现的数据自动分片手段。

Redis的首要成果都基于单线程模子实现，也就是说Redis行使一个线程来处事全部的客户端哀求，同时Redis回收了非阻塞式IO，并风雅地优化各类呼吁的算法时刻伟大度，这些信息意味着：

• Redis是线程安详的(由于只有一个线程)，其全部操纵都是原子的，不会因并发发生数据非常
• Redis的速率很是快(由于行使非阻塞式IO，且大部门呼吁的算法时刻伟大度都是O(1))
• 行使高耗时的Redis呼吁是很伤害的，会占用独一的一个线程的大量处理赏罚时刻，导致全部的哀求都被拖慢。(譬喻时刻伟大度为O(N)的KEYS呼吁，严酷榨取在出产情形中行使)

Redis的数据布局和相干常用呼吁

本节中将先容Redis支持的首要数据布局，以及相干的常用Redis呼吁。本节只对Redis呼吁举办简要的先容，且只列出了较常用的呼吁。假如想要相识完备的Redis呼吁集，或相识某个呼吁的具体行使要领，请参考官方文档：

https://redis.io/commands

Key

Redis回收Key-Value型的根基数据布局，任何二进制序列都可以作为Redis的Key行使(譬喻平凡的字符串或一张JPEG图片)

关于Key的一些留意事项：

• 不要行使过长的Key。譬喻行使一个1024字节的key就不是一个好主意，不只会耗损更多的内存，还会导致查找的服从低落
• Key短到缺失了可读性也是欠好的，譬喻”u1000flw”比起”user:1000:followers”来说，节减了寥寥的存储空间，却激发了可读性和可维护性上的贫困
• 最好行使同一的类型来计划Key，好比”object-type:id:attr”，以这一类型计划出的Key也许是”user:1000″或”comment:1234:reply-to”
• Redis应承的最大Key长度是512MB(对Value的长度限定也是512MB)

String

String是Redis的基本数据范例，Redis没有Int、Float、Boolean等数据范例的观念，全部的根基范例在Redis中都以String浮现。

与String相干的常用呼吁：

• SET：为一个key配置value，可以共同EX/PX参数指定key的有用期，通过NX/XX参数针对key是否存在的环境举办区别操纵，时刻伟大度O(1)
• GET：获取某个key对应的value，时刻伟大度O(1)
• GETSET：为一个key配置value，并返回该key的原value，时刻伟大度O(1)
• MSET：为多个key配置value，时刻伟大度O(N)
• MSETNX：同MSET，假如指定的key中有恣意一个已存在，则不举办任何操纵，时刻伟大度O(N)
• MGET：获取多个key对应的value，时刻伟大度O(N)

上文提到过，Redis的根基数据范例只有String，但Redis可以把String作为整型或浮点型数字来行使，首要表此刻INCR、DECR类的呼吁上：

• INCR：将key对应的value值自增1，并返回自增后的值。只对可以转换为整型的String数据起浸染。时刻伟大度O(1)
• INCRBY：将key对应的value值自增指定的整型数值，并返回自增后的值。只对可以转换为整型的String数据起浸染。时刻伟大度O(1)
• DECR/DECRBY：同INCR/INCRBY，自增改为自减。
• INCR/DECR系列呼吁要求操纵的value范例为String，并可以转换为64位带标记的整型数字，不然会返回错误。

也就是说，举办INCR/DECR系列呼吁的value，必需在[-2^63 ~ 2^63 – 1]范畴内。

前文提到过，Redis回收单线程模子，自然是线程安详的，这使得INCR/DECR呼吁可以很是便利的实现高并发场景下的准确节制。

例1：库存节制

在高并发场景下实现库存余量的精准校验，确保不呈现超卖的环境。

配置库存总量：

SET inv:remain "100" 

库存扣减+余量校验：

DECR inv:remain 

当DECR呼吁返回值大于便是0时，声名库存余量校验通过，假如返回小于0的值，则声名库存已耗尽。

假设同时有300个并发哀求举办库存扣减，Redis可以或许确保这300个哀求别离获得99到-200的返回值，每个哀求获得的返回值都是独一的，绝对不会找呈现两个哀求获得一样的返回值的环境。

例2：自增序列天生

实现相同于RDBMS的Sequence成果，天生一系列独一的序列号

配置序列起始值：

SET sequence "10000" 

获取一个序列值：

INCR sequence 

直接将返回值作为序列行使即可。

获取一批(如100个)序列值：

INCRBY sequence 100 

假设返回值为N，那么[N – 99 ~ N]的数值都是可用的序列值。

当多个客户端同时向Redis申请自增序列时，Redis可以或许确保每个客户端获得的序列值或序列范畴都是全局独一的，绝对不会呈现差异客户端获得了一再的序列值的环境。

List

（编辑：河北网）

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