Redis操作命令小结


=Start=

缘由:

最初学过一段时间的Redis的使用,但是后来长时间没有接触,就又忘了,往复这么弄了几次,感觉比较浪费时间,所以今天决定整理一下Redis的常见操作命令,记录到blog上来,方便以后查阅。

正文:

Redis的安装什么的就不说了,比较简单(不过要注意安全就是了),有需要的可以去看看「如何在 CentOS 7 上安装 Redis 服务器」这篇文章,内容基本都有。下面说一下Redis常见的操作命令:

0.连接
$ redis-cli -h localhost -p 6397
> auth 'redis-pass'
1.查看大体情况
info
CONFIG GET *
CONFIG GET requirepass
CLIENT LIST
MONITOR
SLOWLOG GET 25
2.查看(并切换)有哪些数据库
info keyspace
CONFIG GET databases
select 0
select 1
3.查看有哪些KEYS
keys * #Redis 2.8 之前版本(部分公司内部一般会禁用`keys`这个命令)
scan 0 #Redis 2.8 之后版本
4.如何获取所有的 VALUES
5.对KEY进行增删改查
#标量(Scalar)
get <key>
set <key> <value>
setnx <key> <value> # Set key value only if key does not exist

#列表(List)
lrange <key> <start> <stop>
lrange mylist 0 -1      # Get all of a list
lindex mylist 5         # Get by index
llen mylist         # Get length

lpush mylist "value"
lpush mylist 5
rpush mylist "value"

lpushx mylist 6         # Only push in mylist exists

#哈希值(Hash)
hexists myhash field1       # Check if hash key exists

hget myhash field1
hdel myhash field2
hset myhash field1 "value"
hsetnx myhash field1 "value"

hgetall myhash
hkeys myhash
hlen myhash

 

参考链接:

=END=

, ,

《“Redis操作命令小结”》 有 20 条评论

  1. 用 Go 来了解一下 Redis 通讯协议
    https://github.com/EDDYCJY/blog/blob/master/golang/2018-06-07-%E7%94%A8Go%E6%9D%A5%E4%BA%86%E8%A7%A3%E4%B8%80%E4%B8%8BRedis%E9%80%9A%E8%AE%AF%E5%8D%8F%E8%AE%AE.md
    http://doc.redisfans.com/topic/protocol.html
    `
    Redis 的客户端和服务端是通过 TCP 连接来进行数据交互, 服务器默认的端口号为 6379 。

    客户端和服务器发送的命令或数据一律以 \r\n (CRLF)结尾(这是一条约定)。

    在 Redis 中分为请求和回复,而请求协议又分为新版和旧版,新版统一请求协议在 Redis 1.2 版本中引入,最终在 Redis 2.0 版本成为 Redis 服务器通信的标准方式。

    在这里我们完成了整个 Redis 客户端和服务端交互的流程,分别如下:
    1、读取命令行参数:获取执行的 Redis 命令
    2、获取请求协议参数
    3、连接 Redis 服务器,获取连接句柄
    4、将请求协议参数写入连接:发送请求的命令行参数
    5、从连接中读取返回的数据:读取先前请求的回复数据
    6、根据回复“协议”内容,处理回复的数据集
    7、输出处理后的回复内容及原始回复内容
    `

  2. redis开发设计规范及案例分析
    https://mp.weixin.qq.com/s/vS8IMgBIrfGpZYNUwtXrPQ
    `
    redis不是垃圾桶也不是 SUPER MAN,能力和资源都有限,不合理的使用会降低它的健康度,严重时甚至会引起redis抖动、阻塞等进而导致服务不可用,每一个使用redis的开发人员都应当掌握规范的开发和使用方法。本文整理出redis开发过程中七个较常出现的使用不合理的场景,并辅以案例进行分析说明。

    01 合理使用集合类
    使用 sortedset、set、list、hash等集合类的O(N)操作时要评估当前元素个数的规模以及将来的增长规模,对于短期就可能变为大集合的key,要预估O(N)操作的元素数量,避免全量操作,可以使用HSCAN、SSCAN、ZSCAN进行渐进操作。

    02 合理设置过期时间
    如果key没有设置超时时间,会导致一直占用内存。对于可以预估使用生命周期的key应当设置合理的过期时间或在最后一次操作时进行清理,避免垃圾数据残留redis。

    03 合理利用批操作命令
    对于大量频繁的hset操作可以使用 HMSET替代减少redis操作次数同时提升处理速度,但是要考虑单次请求操作的数量,避免慢日志。

    04 减少不必要的请求
    redis的所有请求对于不存在的key都会有输出返回,合理利用返回值处理,避免不必要的请求,提升业务吞吐量。

    05 避免value设置过大
    String类型尽量控制在10KB以内。虽然redis对单个key可以缓存的对象长度能够支持的很大,但是实际使用场合一定要合理拆分过大的缓存项,1k 基本是redis性能的一个拐点。当缓存项超过10k、100k、1m性能下降会特别明显。

    06 设计规范的key名
    可读性、简洁性、不包含特殊转义字符

    07 留心禁用命令
    keys、monitor、flushall、flushdb应当通过redis的rename机制禁掉命令,若没有禁用,开发人员要谨慎使用。其中flushall、flushdb会清空redis数据;keys命令可能会引起慢日志;monitor命令在开启的情况下会降低redis的吞吐量,根据压测结果大概会降低redis50%的吞吐量,越多客户端开启该命令,吞吐量下降会越多。
    `

  3. 为什么说Redis是单线程的以及Redis为什么这么快!
    https://blog.csdn.net/xlgen157387/article/details/79470556
    `
    1、完全基于内存,绝大部分请求是纯粹的内存操作,非常快速。数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1);

    2、数据结构简单,对数据操作也简单,Redis中的数据结构是专门进行设计的;

    3、采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗;

    4、使用多路I/O复用模型,非阻塞IO;

    5、使用底层模型不同,它们之间底层实现方式以及与客户端之间通信的应用协议不一样,Redis直接自己构建了VM 机制 ,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求;
    `

  4. 那些年用过的Redis集群架构(含面试解析)
    https://mp.weixin.qq.com/s/8H-Hd169s5Hlwn5F2ec25A
    `
    Replication+Sentinel
    Proxy+Replication+Sentinel
    Redis Cluster

    问题1:懂Redis事务么?
    问题2:Redis的多数据库机制,了解多少?
    问题3:Redis集群机制中,你觉得有什么不足的地方吗?
    问题4:懂Redis的批量操作么?
    问题5:那在Redis集群模式下,如何进行批量操作?
    问题6:你们有对Redis做读写分离么?
    `

  5. 用户日活月活怎么统计 – Redis HyperLogLog 详解
    https://mp.weixin.qq.com/s/AvPoG8ZZM8v9lKLyuSYnHQ
    `
    HyperLogLog 是一种概率数据结构,用来估算数据的基数。数据集可以是网站访客的 IP 地址,E-mail 邮箱或者用户 ID。

    基数就是指一个集合中不同值的数目,比如 a, b, c, d 的基数就是 4,a, b, c, d, a 的基数还是 4。虽然 a 出现两次,只会被计算一次。

    使用 Redis 统计集合的基数一般有三种方法,分别是使用 Redis 的 HashMap,BitMap 和 HyperLogLog。前两个数据结构在集合的数量级增长时,所消耗的内存会大大增加,但是 HyperLogLog 则不会。

    Redis 的 HyperLogLog 通过牺牲准确率来减少内存空间的消耗,只需要12K内存,在标准误差0.81%的前提下,能够统计2^64个数据。所以 HyperLogLog 是否适合在比如统计日活月活此类的对精度要不不高的场景。

    这是一个很惊人的结果,以如此小的内存来记录如此大数量级的数据基数。下面我们就带大家来深入了解一下 HyperLogLog 的使用,基础原理,源码实现和具体的试验数据分析。

    基本原理
    HyperLogLog 是一种概率数据结构,它使用概率算法来统计集合的近似基数。而它算法的最本源则是伯努利过程。

    伯努利过程就是一个抛硬币实验的过程。抛一枚正常硬币,落地可能是正面,也可能是反面,二者的概率都是 1/2 。伯努利过程就是一直抛硬币,直到落地时出现正面位置,并记录下抛掷次数k。比如说,抛一次硬币就出现正面了,此时 k 为 1; 第一次抛硬币是反面,则继续抛,直到第三次才出现正面,此时 k 为 3。

    对于 n 次伯努利过程,我们会得到 n 个出现正面的投掷次数值 k1, k2 … kn , 其中这里的最大值是k_max。
    `

  6. 分享几道 Redis 高频面试题,面试不用愁
    https://mp.weixin.qq.com/s/HWBgv2cKku7uY7fM-yWx1g
    `
    1、说说 Redis 都有哪些应用场景?
    2、单线程的 Redis 为什么这么快?
    3、说说 Redis 的数据结构及使用场景
    4、说一说 Redis 的数据过期淘汰策略
    5、如何解决 Redis 缓存穿透和缓存雪崩问题
    `

  7. DTCC2023中国数据库技术大会议程抢先看- 专场18NoSQL数据库应用
    http://blog.itpub.net/29568843/viewspace-2969581/
    `
    演讲主题(二): 快手Redis架构演进实践

    演讲简介: 介绍快手超大规模 Redis 最佳实践,包含如下:

    (1) 超大规模介绍(top 3水平):180万实例、3万台机器、数十个IDC(国内、海外、物理机、云主机)、2万集群、5PB内存、日均百万亿级访问。
    (2) 成本优化:三阶段(精细化运营、降冷优化、容器化优化)
    a) 精细化运营:资源精细化、低成本硬件(例如AEP)、键值优化、版本升级
    b) 降冷优化:自研KV缓存存储
    c) 容器化优化:Redis容器化
    (3) 稳定性优化:多年无P级故障,SLA:99.9995%以上的最佳实践
    (4) 效率优化:2人100%白屏自动化运维最佳实践
    (5)Redis 相关优化:大热key、限流、版本升级、异地多活等
    `

    Redis消息队列发展历程
    https://bbs.huaweicloud.com/forum/thread-189028-1-1.html
    `
    兼顾成本、性能、持久化,这就有了Tair持久内存版。

    Tair持久内存版特性

    1. 更大空间,更低成本

    Tair持久内存版引入了Intel傲腾持久内存(下面称作AEP),它的性能略低于内存,但相同容量下成本低于内存。Tair持久内存版将主要数据存储在AEP上,使得相同容量下,成本更低,这使同样单价下stream能堆积更多的消息。

    2. 兼容社区版

    Tair持久内存版兼容原生Redis绝大部分的数据结构和接口,对于stream相关接口做到了100%兼容,如果你之前使用了社区版stream,那么不需要修改任何代码,只需要换一个连接地址就能切换到持久内存版。并且通过工具完成社区版和持久内存版数据的双向迁移。

    3. 数据的实时持久化

    Tair持久内存版并不是简单将Redis中的数据换了一个介质存储,因为这样仅能通过AEP降低成本,但没用到AEP断电数据不丢失的特性,对持久化能力没有任何提升。

    开源Redis通过在磁盘上记录AppendOnlyLog来持久化数据,AppendOnlyLog记录了所有的写操作,相当于redolog,在宕机恢复时通过回放这些log恢复数据。但受限于磁盘介质的高延时和Redis内存数据库使用场景下对低延时的要求,并不能在每次写操作后fsync持久化log,最新写入的数据可能并没有持久化到磁盘,这也是数据可能丢失的根因。

    Tair持久内存版的数据恢复没有使用AppendOnlyLog来完成,而是将redis数据结构存储在AEP上,这样宕机后这些数据结构并不会丢失,并且对这些数据结构增加了一些额外的描述信息,宕机后在recovery时能够读到这些额外的描述信息,让这些redis数据结构重新被识别和索引,将状态恢复到宕机前的样子。Tair通过将redis数据结构和描述信息实时写入AEP,保证了写入数据的实时持久化。
    `

    Redis on AEP 实践
    https://xie.infoq.cn/article/90c2a8030f0c9fcad73562cb9
    `
    # 背景
    由于公司 Redis 实例规模比较大 45000+,使用服务器数量多 2000+,而且使用内存存储成本相比磁盘要高很多,基于 Redis 集群进行现状分析,针对以下集群决定使用傲腾 AEP 存储进行成本优化。

    1. 请求量低的小集群非常多,部署比较分散,服务器资源成本高。
    2. 大容量集群每次申请 200G 到 2T 容量不等,使用服务器数量多。

    傲腾 AEP 性能如何
    首先性能测试,整体来讲跟纯内存相比有 10%左右的损耗,测试数据如下。目前我们在该机型仅支持小集群、大容量的业务,目前不存在性能问题。

    总结
    1)非核心业务可以先上 AEP,如果性能不够再迁移到纯内存服务器上。
    2)目前存量小实例继续进行迁移。
    `

    58 同城使用英特尔® 傲腾™ 持久内存打造高经济性的 Redis 与云搜系统
    https://www.intel.cn/content/dam/www/central-libraries/cn/zh/documents/2022-08/140-58-com-build-cost-effective-redis-and-cloud-search-systems-based-on-optane-persistent-memory-solution-brief.pdf

回复 hi 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注