Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
25200 人已学习
立即订阅
登录后,你可以任选4讲全文学习
推荐试读
换一换
02 | 数据结构:快速的Redis有哪些慢操作?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
17 | 为什么CPU结构也会影响Redis的性能?
课程目录
已完结/共 53 讲
开篇词 (1讲)
开篇词 | 这样学Redis,才能技高一筹
基础篇 (10讲)
01 | 基本架构:一个键值数据库包含什么?
02 | 数据结构:快速的Redis有哪些慢操作?
03 | 高性能IO模型:为什么单线程Redis能那么快?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
05 | 内存快照:宕机后,Redis如何实现快速恢复?
06 | 数据同步:主从库如何实现数据一致?
07 | 哨兵机制:主库挂了,如何不间断服务?
08 | 哨兵集群:哨兵挂了,主从库还能切换吗?
09 | 切片集群:数据增多了,是该加内存还是加实例?
10 | 第1~9讲课后思考题答案及常见问题答疑
实践篇 (28讲)
11 | “万金油”的String,为什么不好用了?
12 | 有一亿个keys要统计,应该用哪种集合?
13 | GEO是什么?还可以定义新的数据类型吗?
14 | 如何在Redis中保存时间序列数据?
15 | 消息队列的考验:Redis有哪些解决方案?
16 | 异步机制:如何避免单线程模型的阻塞?
17 | 为什么CPU结构也会影响Redis的性能?
18 | 波动的响应延迟:如何应对变慢的Redis?(上)
19 | 波动的响应延迟:如何应对变慢的Redis?(下)
20 | 删除数据后,为什么内存占用率还是很高?
21 | 缓冲区:一个可能引发“惨案”的地方
22 | 第11~21讲课后思考题答案及常见问题答疑
23 | 旁路缓存:Redis是如何工作的?
24 | 替换策略:缓存满了怎么办?
25 | 缓存异常(上):如何解决缓存和数据库的数据不一致问题?
26 | 缓存异常(下):如何解决缓存雪崩、击穿、穿透难题?
27 | 缓存被污染了,该怎么办?
28 | Pika:如何基于SSD实现大容量Redis?
29 | 无锁的原子操作:Redis如何应对并发访问?
30 | 如何使用Redis实现分布式锁?
31 | 事务机制:Redis能实现ACID属性吗?
32 | Redis主从同步与故障切换,有哪些坑?
33 | 脑裂:一次奇怪的数据丢失
34 | 第23~33讲课后思考题答案及常见问题答疑
35 | Codis VS Redis Cluster:我该选择哪一个集群方案?
36 | Redis支撑秒杀场景的关键技术和实践都有哪些?
37 | 数据分布优化:如何应对数据倾斜?
38 | 通信开销:限制Redis Cluster规模的关键因素
期中测试 (2讲)
期中测试题 | 一套习题,测出你的掌握程度
期中测试题答案 | 这些问题,你都答对了吗?
未来篇 (3讲)
39 | Redis 6.0的新特性:多线程、客户端缓存与安全
40 | Redis的下一步:基于NVM内存的实践
41 | 第35~40讲课后思考题答案及常见问题答疑
加餐篇 (7讲)
加餐(一)| 经典的Redis学习资料有哪些?
加餐(二)| 用户Kaito:我是如何学习Redis的?
加餐(三)| 用户Kaito:我希望成为在压力中成长的人
加餐(四) | Redis客户端如何与服务器端交换命令和数据?
加餐(五) | Redis有哪些好用的运维工具?
加餐(六)| Redis的使用规范小建议
加餐(七) | 从微博的Redis实践中,我们可以学到哪些经验?
结束语 (2讲)
期末测试 | 这些Redis核心知识,你都掌握了吗?
结束语 | 从学习Redis到向Redis学习
Redis 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册
开通超级会员可免费学习本课程,还可解锁海量内容免费学特权。

加餐(六)| Redis的使用规范小建议

你好,我是蒋德钧。
今天的加餐,我们来聊一个轻松点儿的话题,我来给你介绍一下 Redis 的使用规范,包括键值对使用、业务数据保存和命令使用规范。
毕竟,高性能和节省内存,是我们的两个目标,只有规范地使用 Redis,才能真正实现这两个目标。如果说之前的内容教会了你怎么用,那么今天的内容,就是帮助你用好 Redis,尽量不出错。
好了,话不多说,我们来看下键值对的使用规范。

键值对使用规范

关于键值对的使用规范,我主要想和你说两个方面:
key 的命名规范,只有命名规范,才能提供可读性强、可维护性好的 key,方便日常管理;
value 的设计规范,包括避免 bigkey、选择高效序列化方法和压缩方法、使用整数对象共享池、数据类型选择。

规范一:key 的命名规范

一个 Redis 实例默认可以支持 16 个数据库,我们可以把不同的业务数据分散保存到不同的数据库中。
但是,在使用不同数据库时,客户端需要使用 SELECT 命令进行数据库切换,相当于增加了一个额外的操作。
其实,我们可以通过合理命名 key,减少这个操作。具体的做法是,把业务名作为前缀,然后用冒号分隔,再加上具体的业务数据名。这样一来,我们可以通过 key 的前缀区分不同的业务数据,就不用在多个数据库间来回切换了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
02 | 数据结构:快速的Redis有哪些慢操作?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
17 | 为什么CPU结构也会影响Redis的性能?
24 | 替换策略:缓存满了怎么办?
40 | Redis的下一步:基于NVM内存的实践
41 | 第35~40讲课后思考题答案及常见问题答疑
开通超级会员免费畅看本课程
开通会员
该文章仅可免费阅读部分内容,如需阅读完整文章,请开通超级会员或单独购买本课程。
登录 后留言

精选留言(12)

  • Kaito
    我总结的 Redis 使用规范分为两大方面,主要包括业务层面和运维层面。

    业务层面主要面向的业务开发人员:

    1、key 的长度尽量短,节省内存空间
    2、避免 bigkey,防止阻塞主线程
    3、4.0+版本建议开启 lazy-free
    4、把 Redis 当作缓存使用,设置过期时间
    5、不使用复杂度过高的命令,例如SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE
    6、查询数据尽量不一次性查询全量,写入大量数据建议分多批写入
    7、批量操作建议 MGET/MSET 替代 GET/SET,HMGET/HMSET 替代 HGET/HSET
    8、禁止使用 KEYS/FLUSHALL/FLUSHDB 命令
    9、避免集中过期 key
    10、根据业务场景选择合适的淘汰策略
    11、使用连接池操作 Redis,并设置合理的参数,避免短连接
    12、只使用 db0,减少 SELECT 命令的消耗
    13、读请求量很大时,建议读写分离,写请求量很大,建议使用切片集群

    运维层面主要面向的是 DBA 运维人员:

    1、按业务线部署实例,避免多个业务线混合部署,出问题影响其他业务
    2、保证机器有足够的 CPU、内存、带宽、磁盘资源
    3、建议部署主从集群,并分布在不同机器上,slave 设置为 readonly
    4、主从节点所部署的机器各自独立,尽量避免交叉部署,对从节点做维护时,不会影响到主节点
    5、推荐部署哨兵集群实现故障自动切换,哨兵节点分布在不同机器上
    6、提前做好容量规划,防止主从全量同步时,实例使用内存突增导致内存不足
    7、做好机器 CPU、内存、带宽、磁盘监控,资源不足时及时报警,任意资源不足都会影响 Redis 性能
    8、实例设置最大连接数,防止过多客户端连接导致实例负载过高,影响性能
    9、单个实例内存建议控制在 10G 以下,大实例在主从全量同步、备份时有阻塞风险
    10、设置合理的 slowlog 阈值,并对其进行监控,slowlog 过多需及时报警
    11、设置合理的 repl-backlog,降低主从全量同步的概率
    12、设置合理的 slave client-output-buffer-limit,避免主从复制中断情况发生
    13、推荐在从节点上备份,不影响主节点性能
    14、不开启 AOF 或开启 AOF 配置为每秒刷盘,避免磁盘 IO 拖慢 Redis 性能
    15、调整 maxmemory 时,注意主从节点的调整顺序,顺序错误会导致主从数据不一致
    16、对实例部署监控,采集 INFO 信息时采用长连接,避免频繁的短连接
    17、做好实例运行时监控,重点关注 expired_keys、evicted_keys、latest_fork_usec,这些指标短时突增可能会有阻塞风险
    18、扫描线上实例时,记得设置休眠时间,避免过高 OPS 产生性能抖动
    2020-11-18
    14
    172
  • zhou
    还有一个规范:不要把 Redis 当数据库使用
    2020-11-18
    4
    17
  • 独自等待
    【在集合元素个数小于一定的阈值时,会使用内存紧凑型的底层数据结构进行保存,从而节省内存。例如,假设 Hash 集合的 hash-max-ziplist-entries 配置项是 1000,如果 Hash 集合元素个数不超过 1000,就会使用 ziplist 保存数据。紧凑型数据结构虽然可以节省内存,但是会在一定程度上导致数据的读写性能下降】
    请问这个怎么理解,内存连续读写性能不应该更好吗?
    2020-11-18
    2
    2
  • 叶子。
    从 Redis 3.2 版本开始,当 key 字符串的长度增加时,SDS 中的元数据也会占用更多内存空间
    请问这句话怎么理解,之前讲SDS的时候说的好像是 长度和实际分配长度分别占用4B?
    2020-11-18
    2
    1
  • camel
    请问老师,如果一个hash非常大,比如超过10w个记录,避免了hgetall也会导致阻塞很久吗? 也就是说hget操作的性能与hash.size有没有关系,是什么复杂度的关系?(算法层面上能理解的是应该没关系,因为hash的查询操作是O(1)复杂度)
    2021-09-15
  • camel
    请问为什么特别强调sds元数据的大小?key超过32,元数据才从1到3,相对于本身key大小而言元数据不是才占很小比例吗?
    2021-09-15
  • 悟空聊架构
    总结得很棒,还需要在实践中不断地总结。谢谢老师!
    2021-05-14
    1
  • aoe
    非常实用,感谢老师
    2021-04-17
  • Geek_4d3b66
    就文中hash集合过大,我不明白的是hash不是key field value吗,一个key怎么可能过大呢,是存储了上万字段吗
    2021-04-13
    3
  • escray
    好像没怎么看到过 bigkey 的标准定义,之前误以为真的是"key"太大,后来才发现是 value 太大。

    键值对使用规范

    - key 命名规范:业务名作前缀,冒号分隔,加业务数据名,尽量避免数据库切换。key 的长度最好不超过 31(SDS结构元数据大小 1 字节)

    - 避免使用 bigkey:String 类型的数据控制在 10KB 一下,集合类型的元素个数控制在 1 万以内。

    - 使用高效的序列化和压缩方法:protostuff 和 kryo 优于 Java 内置的 java-build-in-serializer;如果使用 XML 或者 JSON 可以考虑压缩,snappy 或 gzip

    - 使用整数对象共享池:在满足业务数据需求的前提下,尽量用整数

    数据保存规范

    - 使用 Redis 保存热数据
    - 不同的业务数据分实例存储
    - 保存数据时,设置过期时间
    - 控制 Redis 实例的容量,2~6 GB

    命令使用规范

    - 线上禁用部分命令:KEYS、FLUSHALL、FLUSHDB
    - 慎用 MONITOR
    - 慎用全量操作命令

    课代表 @Kaito 大神的 Redis 使用规范值得收藏。
    2021-03-22
  • 喵喵喵
    打卡
    2020-12-30
  • 云海
    建议里的Redis实例容量控制在2~6GB,这个数据是如何而来的呢,现在很多大型集群动辄几十上百G。
    2020-11-22
    3
收起评论
12
返回
顶部