ASPIRE

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=

admin

, ,

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

  7. 用 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、输出处理后的回复内容及原始回复内容
    `

    回复

  9. 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%的吞吐量，越多客户端开启该命令，吞吐量下降会越多。
    `

    回复

  13. 为什么说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 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；
    `

    回复

  15. 那些年用过的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做读写分离么？
    `

    回复

  17. 用户日活月活怎么统计 – 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。
    `

    回复

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

    回复

  20. 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

    回复

发表回复

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