Redis最佳实践与实战指南 (it-ebooks) (Z-Library)

Redis训练营电子书 Redis最佳实践 与实战指南 源码核心贡献者带你学习Redis关键技术 阿里云数据库

1 Redis训练营电子书 3 14 32 46 60 73 Redis开发实操之春运迁徙页面 Redis的运维实战 Redis的开发规范和常见问题 Redis架构与介质选择指引 Redis 的高并发实战：抢购系统 Redis生态 Redis训练营 微信关注公众号：阿里云数据库 第一时间，获取更多技术干货 阿里云开发者“藏经阁” 海量免费电子书下载 阿里云Redis官网 GitHub-Alibaba/ TairHash GitHub-Alibaba/ TairString Redis实战课程

3 4Redis训练营电子书 Redis架构与介质选择指引 （一）标准版 如上图所示，Redis集群架构分为两大类：标准版与集群版。 标准版是最原始的Redis单进程模式，标准版细分为双副本、单副本、读写分离三个类别。 集群版分为代理模式与直连模式。业务从标准版迁移到集群版时的可能存在Redis命令不兼容，代理模式可以通过Proxy 帮业务解决这方面问题。直连模式中，Redis Client通过Redis Cluster模式直连Redis DB节点，做到减少网络时延，提 升一定的性能。这两种连接模式下分别支持了双副本跟单副本两种数据形态。 Redis集群架构 作者：民科 Redis 标准版 单副本双副本 读写分离 代理模式 直连模式 双副本 单副本 集群版 ECS SLB:Classic/VPC HA 故障迁移 进程B Replica 进程A Master ECS SLB:Classic/VPC HA Failover Process B Process A Master 如上图所示，标准版的拓扑结构是业务在ECS直接通过SLB连接到后端的 Redis节点。这里Redis节点会有两种情况，第 一种情况是左图的一组一备，进程B是一个热备，主备之间数据直接进行同步。第二种情况是右图的冷备，只有在主节点 挂掉以后，冷备会被拉起，这个时候数据是空的。 ·使用场景： 1.对Redis协议兼容性要求较高的业务； 2.单个Redis性能压力可控的场景； 3.Redis命令相对简单，排序和计算之类的命令较少的场景。 标准版细分为：双副本、单副本和读写分离三种形态，下面逐一介绍。 1.标准版 - 双副本 标准版-双副本模式采用主从（Master-Replica）模式搭建。主节点提供日常服务访问，备节点提供HA高可用，当主节 点发生故障，系统会自动在30秒内切换至备节点，保证业务平稳运行。 ·特点： 1.可靠性：采用双机主从（Master-Replica）架构，主从节点位于不同物理机。主节点对外提供访问，用户可通过 Redis命令行和通用客户端进行数据的增删改查操作。当主节点出现故障，自研的HA系统会自动进行主从切换，保证 业务平稳运行。 2.数据可靠：默认开启数据持久化功能，数据全部落盘。支持数据备份功能，用户可以针对备份集回滚实例或者克隆 实例，有效地解决数据误操作等问题。同时，在支持容灾的可用区（例如杭州可用区H+I）创建的实例，还具备同城 容灾的能力。 两个副本之间的数据实时异步同步，切换主备时可能存在延迟情况。当主节点宕机的时候，可能存在一部分数据没有同步 到B进程（即备节点）上，此时如果进行主备切换，B进程相对于A进程有同步延迟，可能存在部分数据丢失。 此外，在双副本中可以做数据的克隆，即备份机，备份到另一个地方做数据持久化。当业务需要做数据回滚时，可以从备 份机上进行恢复。 ECS SLB:Classic/VPC HA 故障迁移 进程B Replica 进程A Master

5 6Redis训练营电子书 标准版-单副本采用单个数据库节点部署架构，没有可实时同步数据的备用节点，不提供数据持久化和备份策略，使用于 数据可靠性要求不高的纯缓存业务场景使用。 ·特点： 1.纯缓存类业务使用，单副本只有一个在线数据节点，性价比高； 2.阿里云自研HA高可用系统，异常30秒自动切换。 单副本在使用时需要注意，当高可用节点A宕机后，需要先对B节点进行缓存的预热，避免切换后发现B节点无数据可用。 3.读写分离 2.标准版 – 单副本 ECS SLB:Classic/VPC HA Failover Process B Process A Master ECS实例 读/写 请求 读 请 求 读 请 求 读 请 求 主节点 Proxy节点 数据分片 …… 只读节点1 高可用系统监控所有节点 只读节点2 … 只读节点N 主节点 同 步 数 据 针对读多写少的业务场景，云数据库Redis推出了读写分离版的产品形态，提供高可用、高性能、灵活的读写分离服务， 满足热点数据集中及高并发读取的业务需求，最大化地节约运维成本。 ECS实例通过Proxy节点，可以将读写请求分发到主节点数据分片，并将部分读请求分发到其他只读节点。 ·使用场景： 1.读取请求QPS压力较大：适合读多写少型业务； 2.对Redis协议兼容要求较高的业务。 ·建议与使用须知： 1.非特殊需求不建议使用，QPS压力大的业务建议使用集群版； 2.当一个只读节点发生故障时，请求会转发到其他节点；如果所有只读节点均不可用，请求会全部转发到主节点，导 致主节点压力过大； 3.只读节点发生异常时，高可用系统会暂停异常节点服务进行重搭恢复，但不承诺只读节点的恢复时间指标； 4.只读节点数据旧于主节点且落后时间可能很长。 ·使用场景： 1.数据量较大的场景； 2.QPS压力较大的场景； 3.吞吐密集型（网络带宽较大）应用场景。 （二）集群版 ECS SLB:Classic/VPC HA Master 1 HA HA Proxy Servers …… …… Config Server Master 2 Master N ECS SLB:Classic/VPC Master 1 Proxy Servers …… Config Server Master 2 Master N Replica 1 Replica 2 Replica N

7 8Redis训练营电子书 云数据库Redis版提供双副本集群版实例，可轻松突破Redis自身单线程瓶颈，满足大容量、高性能的业务需求。集群版支 持代理和直连两种连接模式。 ·使用场景： 1.数据量大：相比Redis标准版，集群版可以有效地扩展存储量，最大可达4098 GB，能有效的满足业务扩展的需求； 2.QPS压力较大：标准版Redis无法支撑较大的QPS，需要采用多分片的部署方式来突破Redis单线程的性能瓶颈； 3.吞吐密集型应用：相比Redis标准版，集群版的内网吞吐限制相对较低，可以更好地支持热点数据读取、大吞吐类 业务； 4.对Redis协议兼容性不敏感的应用：集群版对Redis协议支持上相比标准版本有一定的限制。 1.集群版 – 双副本 Proxy代理模式 直连模式 ECS SLB:Classic/VPC HA Master 1 HA HA Proxy Servers …… …… Config Server Master 2 Master N Replica 1 Replica 2 Replica N ECS HA SLB Master 1 HA HA…… Master 2 Master N Replica 1 Replica 2 Replica N VIP VIP VIP Redis Cluster Protocol First time ·特点： 代理模式因所有请求都需要通过代理服务器转发，代理模式在降低业务开发难度的同时也会小幅度影响Redis服务的响应 速度，如果业务响应速度的要求非常高，可以选择直连模式，绕过代理服务器直连后端数据分片，从而降低网络开销和服 务响应时间，直连模式适用于对响应要求较高的业务。 2.集群版 – 命令限制 ·不支持命令 1.SWAPDB 2.CLIENT ID 3.SORT (BY和GET) ·受限命令 在集群模式下如果需要执行受限制的命令，需要使用Hash Tag确保所要操作的Key在同个Hash Slot中，Hash Tag的详 细用法参见Redis官方文档。 可以看到，许多受限命令为多Key命令，为什么多Key命令会受到限制？ 因为集群版会根据数据的Key做一次性Hash，分散到不同的数据节点上，这些涉及到多Key的命令，key经过Hash后如 果分布在不同的节点上，命令就不能在一个单数据节点里面完成，这些命令会直接返回错误。 如果要使用这些多Key命令，需要每一个Key准确Hash到同一个Slot上。Redis的Key可以添加一个Hash Tag，相同的Tag会 被Hash到同一个Slot上，在同一个Slot中，这些受限的命令就可以支持。 ·Lua脚本使用限制： 1.所有Key都应该由KEYS数组来传递； 2.所有Key必须在同一个Slot上； 3.调用必须要带有Key； 4.不支持发布订阅消息； 5.不支持UNPACK函数； 6.其他详细限制参见Redis官方文档。 受限命令族 HyperLogLog PFMERGE, PFCOUNT RENAME, RENAMENX, SORT RPOPLPUSH, BRPOP, BLPOP, BRPOPLPUSH EVAL, EVALSHA, SCRIPT EXISTS, SCRIPT FLUSH, SCRIPT KILL, SCRIPT LOAD MSETNX DISCARD, EXEC, MULTI, UNWATCH, WATCH Keys Lists Scripting Strings Transaction 具体命令

9 10Redis训练营电子书 如上图所示，简言之，如果业务qps低且容量低（小于32GB）选择标准版，否则选择集群版。 在选择标准版的情况下，根据数据可靠性与读写情况可再进行细分。 如果业务数据单纯作为缓存加速或数据可丢，可以选择单副本，减少一半的成本。如果要求数据在异常情况下不能全部丢 失，对可靠性要求较高的情况下，此时要根据读写情况进行选择。 如果读写情况没有明显差异，可以选择双副本，如果读请求数量远大于写请求，可以选择读写分离。但是除去特殊情况， 读写分离有诸多限制，大多数情况下不是一个很好的选择，我们还是建议考虑集群的模式。 如果用户原本使用标准版，随着业务的发展QPS容量上升，需要由标准版切换成集群版，根据命令兼容性可选择不同 模式。 3.集群模式如何选型 ·选型时应注意以下两点： 1.评估QPS和容量时一定要为未来留有余量； 2.不同架构间存在一定的兼容性问题，业务允许的情况下尽量使用不同架构命令支持集合的交集，以便后续架构切换。 Start QPS 低 低 低 高 高 高 标准版 集群版 容量 容量 标准版 可靠性 低 高 否 是 双副本单副本 读写分离 读多写少 集群版 兼容性 高 低 代理模式 直连模式 低 高 单副本 双副本 可靠性 如果用户业务代码有太多需要修改，或者不想修改代码，对命令兼容性要求较高，可以选择代理模式，兼容性问题由阿 里云提供的Proxy解决。如果业务对兼容性要求较低，或者新业务在开发时本就是按照集群版标准进行，则可选择直连 模式。 模式选择完之后，可根据业务对数据可靠性的要求，进一步选择单副本或双副本。此处的单双副本使用注意事项，与标准 版类似。 Redis存储介质 持久内存型内存型 容量存储型 混合存储型 Redis 购买Redis时还需选择存储介质，目前阿里云提供四种存储介质，分别为内存型、持久内存型、容量存储型和混合存储型。 内存型为我们常见的纯内存，混合存储型正逐步被持久内存型与容量存储型替代，下面重点介绍持久内存型与容量存储型。 Redis企业版持久内存型（简称持久内存型）基于Intel傲腾TM数据中心级持久内存（AEP），为用户提供大容量、兼容 Redis的内存数据库产品。单实例成本对比Redis社区版最高可降低30%，且数据持久化不依赖传统磁盘，保证每个操作持 久化的同时提供近乎Redis社区版的吞吐和延时，极大提升业务数据可靠性。 ·特点： 1.超高性价比：相同容量下对比阿里云Redis社区版本，价格降低30%左右； 2.大规格优化：解决AOF的造成的性能开销，无需在性能和持久化之间取舍； 3.掉电数据不丢失：每个写操作都同步持久化； 4.高兼容性：兼容现有阿里云Redis数据库体系。 （一）持久内存型 CPUProcessing Memory Hierarchy Size:1x Latency:1x Size:10x Latency:100x Size:100x Latency:1,000x Size:100x Latency:100,000x Size:10,000x Latency:10,000,000x Memory Storage 将内存持久化到硬盘 SCM SSD HDD DRAM NVDIMM

11 12Redis训练营电子书 从社区到企业版 Redis企业版容量存储型（简称容量存储型）基于云盘ESSD研发，兼容Redis核心数据结构与接口，可提供大容量、低成 本、强持久化的数据库服务。容量存储型在降低成本和提升数据可靠性的同时，也解决了原生Redis固有的Fork命令而预留 部分内存的问题。适用于兼容Redis、需要大容量且较高访问性能的温冷数据存储场景。 ·特点： 1.兼容性：兼容大部分原生Redis命令； 2.成本：最低为Redis社区版的15%。 （一）阿里云集群能力 （二）开源Redis集群实现 （二）容量存储型 集群能力对比 高可靠 管控 高可用 迁移平滑性 成本 迁移异常，丢失部分数据，需手动恢复 无中心化控制集群状态收敛慢 怠机需手动进行重搭 扩缩容需借助额外服务 高可用心跳探测准确性受慢查询影响， 造成故障切换时间过长或者切换不准确 数据高可靠，迁移失败自动回滚可重试 中心化控制迅速准确 日常运维由系统自动完成 自研探测机制规避慢查询风险导致的误 切换高可用探测更准确 故障切换时间平均8秒，SLA15秒 无感迁移 无明显rt上涨 无新增错误 低 支持细粒度扩缩容 集群内存是用优化 大Key迁移影响服务RT，严重时触发HA Lua脚本丢失 迁移期间多key命令失败 高 集群模式有额外内存开销，大key小value 场景内存容量接近翻倍 开源版Redis 阿里云Redis 阿里云Redis与开源版Redis集群能力对比 Gossip ClientBClientA ClientC ·实现细节： 1.通过Gossip使所有Redis节点彼此相互心跳探活，使用内部的二进制协议优化传输速度和带宽； 2.节点Fail时通过集群中超过半数节点探活协商确定失败，如果集群较大则会拉长协商时间； 3.节点间数据迁移是按照Key的粒度进行的，迁移过程中一个Slot的数据会分布在两个节点上。 ·优点： 使用Gossip协议无中心控制，无额外控制节点。 ·缺点： 1.无中心控制，集群状态更新慢，故障HA慢； 2.探活方式单一，受慢查询干扰，容易误切换； 3.按Key迁移，大Key迁移造成服务卡顿； 4.迁移异常中断，无法自动恢复； 5.迁移期间多Key命令失败； 6.迁移依赖外部组件。 ·实现细节： 1.中心控制节点采用自研的多因子进行准确的探活； 2.数据迁移采用Slot粒度Precopy的方式，迁移快速，异常可回滚。 ·优点： 1.准确快速的探活，保障服务质量(SLA<15s)； （三）阿里云Redis集群实现 ClientBClientA ClientC Raft

13 14Redis训练营电子书 2.同时支持直连模式和代理模式； 3.扩缩容业务无感知（大Key，多key，Lua），不断连接； 4.迁移流量在节点间直接传输，不需要外部组件中转。 Redis的开发规范和常见问题 （一）Run-to-Completion in a solo thread–Redis最大的问题 （二）扩展为集群版，问题可解？ Redis最大的问题是后台主要线程是一个单线程，如下图所示，用户所有的来自不同client的请求，实际上在每个 event到来后，交由后端单线程执行。等每个event处理完成后，才处理下一个；单线程run-to-completion就是没有 dispatcher，没有后端的multi-worker。所以如果慢查询，诸如单机版的keys、lrange、hgetall等拖慢了一次查询，那么 后面的请求就会被拖慢。 既然一个Redis进程不行，采用分布式方案扩展成集群版可以吗？集群板确实能解决一部分问题，常见的请求是可以分散 到不同DB上的。 但是，集群版也还是解决不了单个DB被卡住的问题，因为Redis的key hash规则是按照外面的一层PK来做的，没有按照里 面的子key或者是field的来做，如果用户调用了跨分片的命令，如mget，访问到出问题的db，仍会block住，问题还是会 存在。 使用Sentinel判活的trick： ·Ping命令判活：ping命令同样受到慢查询影响，如果引擎被卡住，则ping失败； ·Duplex Failure：sentinel由于慢查询切备（备变主）再遇到慢查询，Redis将出现OOS。 Redis–从问题说起 作者：晓翌 Process TCP send()TCP recv()epoll_wait Redis Client Redis Client 1 2 3 1、SET key 1 value 1 3、UNLINK Key3 2、SADD Skey Pkey1 1、用户所有的来自不同client的请求，实际上在每个event到来后， 交由后端单线程执行。等每个event处理完成后，才处理下一个。 2、单线程run-to-completion就是没有dispatcher，没有后端的 multi-worker 如果慢查询诸如单机版的keys，和 trange，hgetall等拖慢了一次查询， 那么后面的请求就会被拖慢

15 16Redis训练营电子书 Process TCP send()TCP recv()epoll_wait Proxy ProxyProxy 12.34.56.78:9999 1 2 3 1、同样的，集群版解决不了单个DB被卡住的问题 2、查询空洞：如果用户调用了跨分片的命令，如mget，访问到出 问题的db，仍会block住 Dataset Process TCP send()TCP recv()epoll_wait12.34.56.78:10000 … 1 2 3 Dataset Process TCP send()TCP recv()epoll_wait12.34.56.80:9999 1 2 3 Dataset （三）Protocol问题–大量客户端与引擎Fully-Meshed问题 （四）“Could not get a resource from the pool” 采用Redis协议（RESP）的问题: ·扩展性太差：基于Question-Answer模式，由于在Question/Answer里面没有对应的Sequence的存在，(如果不做复 杂的转换wrapper层)存储引擎端没法match请求和响应，只能采用Run-To-Completion来挂住链接; 如下图所示，由于Redis执行Run-To-Completion特性，客户端只能采用连接池的方案；Redis协议不支持连接池收敛， 是因为Message没有ID，所以Request和Response对不起来。连接池具体运作方式是每次查询，都要先从连接池拿出 一根连接来，当服务端返回结果后，再放回连接池。 如果用户返回的及时，那么连接池一直保有的连接数并不高，但是一旦服务端未及时返回，客户端又有新的请求，就只能 再checkout一根连接。 当Engine层出现慢查询，就会让请求返回的慢，造成的后果是很容易让用户把连接池用光，当应用机器特别多的情况，按 每个client 连接池50个max link来算，很容易打到10K链接的限制，导致engine回调速度慢。 当连接池被checkout完，就会爆没有连接的异常："Could not get a resource from the pool"，这是非常常见的错误， 有恶性循环的逻辑在里面。比如说服务端返回的慢，连接池的连接就会创建的很快，用户很容易达到1万条，创建的连接越 多，性能越差，返回越慢，服务容易血崩。 ·C10K的问题：当引擎挂住太多active链接的时候，性能下降太多。测试结果是当有10k active连接时，性能下降30- 35%，由于引擎端挂住的链接不能被返回，用户大量报错。 1、‘*3’代表Array类型，表示该command有3个参数，arraylen 2、每一个子串，‘$n’代表这个串内结构有多长 1、RESP协议使用‘\r\n’作为行结尾（EOL） set k va *3\r\n$3\r\nSET\r\n$1\r\nk\r\n$2\r\nva\r\n 2.5 2 1.5 1 0.5 0 Normal C2K C4K C10K C10K 10min 大链接（active）平均响应时间（ms） RT-99% RT-95 RT-80% RT-AVG 1200 1100 1000 900 800 700 600 500 400 Normal C2K C4K C10K C10K 10min 大链接（active）32子实例OPS（KOPS/s） GET MGET Redis Client SLOW 2、如果用户返回的及时，那么连接池一直保有的连接数并不高 ·但是一旦返回不了，又有新的请求，就只能再checkout一根连接 ·当连接池被checkout完，就会爆没有连接的异常： “Could not get a resource from the pool” 1、每次查询，都要先从连接池拿出一根 连接来，当返回后，再放回连接池 1、 S E T k e y1 v a lu e 1 1、 O K 2 、 H G E T A L L b ig k e y1 当Engine层出现慢查询，就会让请求返回的慢 ·很容易让用户把连接池用光 ·当应用机器特别多的情况，按每个client连接池50个max link来 算，很容易打到10K链接的限制，导致engine回调速度慢 之所以使用连接池，是因为Redis协议不支持连接收敛 ·Message没有ID，所以Request和Response对不起来 ·非常类似HTTP 1.x消息 Redis Client Redis Client

17 18Redis训练营电子书 Redis的边界 Redis的使用建议 --红色区域代表危险 上述罗列的问题，是为了让我们在开发业务的时候，不要触碰Redis的边界。下面从计算、存储、网络三个维度出发，总 结了这张图： 推荐： ·确定场景，是缓存（cache）还是存储型； ·Cache的使用原则是：“无它也可，有它更强”； ·永远不要强依赖Cache，它会丢，也会被淘汰； ·优先设计合理的数据结构和逻辑； ·设计避免bigKey，就避免了80%的问题； ·Keyspace能分开，就多申请几个Redis实例； ·pubsub不适合做消息分发； ·尽量避免用lua做事务。 不建议： ·我的服务对RT很敏感。 >> 低RT能让我的服务运行的更好; ·我把存储都公用在一个redis里。 >> 区分cache和内存数据库用法，区分应用; ·我有一个大排行榜/大集合/大链表/消息队列；我觉得服务能力足够了。 >> 尽量拆散，服务能力不够可通过分布式 集群版可以打散; ·我有一个特别大的Value，存在redis里，访问能好些。 >> redis吞吐量有瓶颈。 Redis–不要触碰边界 Redis–阿里内部开发规约 高计算消耗 高网络消耗 高存储消耗 Wildcard 模块结构化操作 复杂Lua事务 Lua并发 点查 Bigkey 审计大Value 高并发访问 集群mget/mset Huge Batch mget/mset Keys等扫全表 通用命令运算 复杂结构小range Streaming慢消费 1对N PUBSUB N>200 全局配置/热点 企业版（Tair）较好 Bigkey Range 如hgetall，smembers 超大规模连接数 企业版（Tair）较好 大量冷存 企业版（Tair）较好 计算方面：Wildcard、Lua并发、1对N PUBSUB、全局配置/热点，会大量消耗计算资源（高计算消耗）； 存储方面：Streaming慢消费、Bigkey等，造成高存储消耗。 网络方面：Keys等扫全表、Huge Batch mget/mset、大Value、Bigkey Range （如hgetall，smembers），造成高网 络消耗。 Redis的边界总结： ·高并发不等于高吞吐 大 Value 的问题：高速存储并不会有特别大的高吞吐收益，相反会很危险； ·数据倾斜和算力倾斜 bigKey 的问题：break掉存储的分配律； 热点的问题，本质上是cpu上的分配律不满足； 大 Range 的问题：对NoSQL的慢查询和导致的危害没有足够的重视。 ·存储边界 Lua使用不当造成的成本直线上升； 数据倾斜带来的成本飙升，无法有效利用； ·对于 Latency 的理解问题（RT高） 存储引擎的 Latency 都是P99 Latency，如：99.99%在1ms以内，99.5%在3ms以内，等； 偶发性时延高是必然的。这个根因在于存储引擎内部的复杂性和熵。 （一）BigKey–洪水猛兽 BigKey，我们称之为洪水猛兽，据初步统计，80%问题由bigKey导致。如下图所示：集群中有4个分片，每个分片大约 有102个key，实际上是均匀分布。图中第三个key叫key301，hash301，中间有一个放了200w的hash，但因为根据 hash301打散的这个key是个 bigkey，严重造成数据倾斜。

19 20Redis训练营电子书 BigKey – 洪水猛兽 --据初步统计，80%问题由bigKey导致 Sharding Function 100个key Key1 val1 key2 val2 … key100 val100 102个key Key200 val200 key201 val201 … key302 val302 102个key Key500 val500 key501 val501 … key602 val602 101个key，中间有一个放了200w 的hash Key300 val300 Hash301 skey1 val1 skey2 val2 … skey200000 val2000000 … key401 val401 各个分片的实际Key个数， 容量，应该都大差不差， 但因为根据hash301打散 的这个key是个 bigkey， 严重造成数据倾斜 • 大key，大概率是热点 别的key只用了10%或20%的内存，key301用了约80%，而且大概率是热点。上图的使用用法，有可能造成有一个分片 内存满了，访问出了问题，但是其他分片却用的很闲。问题分片的访问比较热，造成网卡打满，或者CPU打满，导致限 流，服务可能就夯住了。 （二）Redis LUA JIT （三）Pubsub/Transaction/Pipeline （四）KEYS 命令 下面的示意图表示了一次脚本的执行过程，客户端调用EVAL script之后会产生SCRIPT Load的行为，Lua JIT开始编译 生成字节码，这时产生一个SHA字符串，表示 bytecode的缓存。Loading bytecode之后，开始执行脚本，还需要保证在 副本上执行成功，最后unload和Cleaning，整个过程结束。 Pubsub的典型场景 Pubsub适合悲观锁和简单信号，不适合稳定的更新，因为可能会丢消息。在1对N的消息转发通道中，服务瓶颈。还有模 糊通知方面，算力瓶颈。在channel和client比较多的情况下，造成CPU打满、服务夯住。 Transaction Transaction是一种伪事物，没有回滚条件；集群版需要所有key使用hashtag保证，代码比较复杂，hashtag也可能导 致算力和存储倾斜；Lua中封装了multi-exec，但更耗费CPU，比如编译、加载时，经常出现问题。 Pipeline Pipeline用的比较多，如下面的示意图，实际上是把多个请求封装在一个请求中，合并在一个请求里发送，服务端一次 性返回，能够有效减少IO，提高执行效率。需要注意的是，用户需要聚合小的命令，避免在pipeline里做大range。注意 Pipeline中的批量任务不是原子执行的（从来不是），所以要处理Pipeline其中部分命令失败的场景。 KEYS命令，一定会出问题，即使当前没有，客户数据量上涨后必然引发慢查，出现后无能为力。这种情况，需要在一开 始就提前预防，可以在控制台通过危险命令禁用，禁止掉keys命令，出现时也可以使用一些手段优化。 KEYS命令的模糊匹配： ·Redis存储key是无序的，匹配时必然全表扫描， key数目一多必然卡住，所以一定要去优化。 如下图所例子中所示，修改为hash结构： ·可以从全表扫描变为点查/部分range, 虽然hash结构中field太多也会慢，但比keys性能提升一个到两个数量级。 Script + EVALSHA 1、可以先把脚本在redis中预编译和加载（不会 unload和clean），使用EVALSHA执行 2、会比纯EVAL省CPU，但是Redis重启/切换/ 变配code cache会失效，需要reload 3、仍是缺陷方案。建议使用复杂数据结构，或者 module来取代lua EVAL script SCRIPT Load EVALSHA Record SHA Redis Return Result Return Result Return SHA Lua JIT Compile Loading bytecode unload Cleaning Guarded by TXN Run With Param processCommand The LUA Iceberg inside Redis 1、脚本的compile-load-run-unload 非常耗费CPU 2、整个lua相当于把复杂事务推送到 Redis中执行，如果稍有不慎内存会 爆，引擎算力耗光后挂住redis 示意图中有3个火形图标，表示耗费CPU的程度，脚本的compile-load-run-unload非常耗费CPU。整个lua相当于把复 杂事务推送到Redis中执行，如果稍有不慎CPU会爆，引擎算力耗光后挂住redis。 对上述的情况，Redis做了一些优化，比如“Script + EVALSHA”，可以先把脚本在redis中预编译和加载（不会unload和 clean），使用EVALSHA执行，会比纯EVAL省CPU，但是Redis重启/切换/变配bytecode cache会失效，需要reload， 仍是缺陷方案。建议使用复杂数据结构，或者module来取代lua。 ·对于JIT技术在存储引擎中而言，“EVAL is evil”，尽量避免使用lua耗费内存和计算资源（省事不省心）； ·某些SDK（如Redisson）很多高级实现都内置使用lua，开发者可能莫名走入CPU运算风暴中，须谨慎。 SET key1 123 Normal Pipelined Application OK INCR key1 124 INCR key1 125 Application SET key1 123 INCR key1 INCR key1 OK 124 125

21 22Redis训练营电子书 这个例子里面，Product1前缀可以提取成为hash的KEY，如果要去product1前缀的所有东西，其实可以下发一个 HGETALL，这样的就是优化了。 一定会出问题（sooner or later） ·客户数据量上涨后必然引发的慢查 ·出现后无能为力 ·可以在控制台通过危险命令禁用 ·优化 product_23::name product_7788::desc product_32123::price iamotherkey::11 random::name product_1::name redis::is::not::ordered hello::slowlog product_11::whatever … … product_1::price … … 修改为hash结构： ·安全表扫描为点查/部分range ·虽然hash结构中field太多也会慢，但比 keys性能提升一个到两个数量级 KEYS命令的模糊匹配： ·Redis的存储key是无序的，必然全表扫描 ·Key数目一多必然卡住 product_1 name:iphone price:2999 product_23::name product_7788::desc product_32123::price iamotherkey::11 random::name product_1 name price redis::is::not::ordered hello::slowlog product_11::whatever … … KEYS product_1::* HGETALL product_1 （五）除去KEYS，下面命令依然危险 规范总结 [ Just FYI ] ·hgetall，smembers，lrange，zrange，exhgetall 直接与数据结构的subkey（field）多少相关，O(n)，携带value爆网卡。 建议使用scan来替代。 ·bitop，bitset 设置过远的bit会直接导致OOM。 ·flushall，flushdb 数据丢失。 用户在操作的时候，需要很小心，因为会清空数据库。在阿里云Redis控制台里面点清除数据时，需要使用二次校验，避 免随意清除数据。另外还可以单独清理过期数据，对其他正常访问的数据没有影响。 ·配置中和ziplist相关的参数 Redis在存储相关数据结构时，数据量比较小，底层使用了ziplist结构，达到一定的量级，比如key/field变多了，会转 换数据结构。当结构在ziplist结构体下时，算力开销变大，部分查询变O(n)级别，匹配变O(m*n)，极端情况容易打满 CPU，不过占用的内存确实变少了（需要评估带来的收益是否匹配付出的代价？）。 建议用户尽量使用默认参数。 1.选型：用户需要确定场景是cache还是内存数据库使用 ·Cache场景，关闭AOF；内存数据库选择双副本 ·如果keyspace能够分开，就申请不同的实例来隔离 2.使用：避免触发高速存储的边界 ·set/hash/zset/list/tairhash/bloom/gis等大key（内部叫做godkey）不要超过3000，会记录sillylog ·避免使用keys，hgetall，lrange0-1等大range（使用scan替代） ·避免使用大value（10k以上就算大value，50k会记录） 3.SDK：使用规范 ·严禁设置低读超时和紧密重试（建议设置200ms以下read timeout） ·需要接受P99时延，对超时和慢做容错处理 ·尽量使用扩展数据结构，避免使用lua ·尽量避免pubsub和blocking的API 4.接受主动运维 ·在阿里云上，如果机器宕机，或者是机器后面有风险，我们会做主动运维保证服务的稳定性。 内存控制是Redis的精华部分，大部分遇到的问题都是跟内存有，Tair/Redis内存模型，如下图所示，总内存分为3个部 分：链路内存（动态）、数据内存、管理内存（静态）。 ·链路内存（动态）：主要包括Input buff、Output buff等，Input buff与Output buff跟每个客户端的连接有关系，正常情 况下比较小，但是当Range操作的时候，或者有大key收发比较慢的时候，这两个区的内存会增大，影响数据区，甚至会 造成OOM。还包括JIT Overhead、Fake Lua Link，包含了Code cache执行缓存等等。 ·数据内存：用户数据区，就是用户实际存储的value。 ·管理内存（静态）：是静态buff，启动的时候比较小，比较恒定。这个区域主要管理data的hash开销，当key非常多的 时候，比如几千万、几个亿，会占用非常大的内存。还包括Repl-buff、aof-buff（32M～64M）通常来说比较小。 （一）Tair/Redis内存模型 Redis–常见问题处理

23 24Redis训练营电子书 Per link Mem 1、正常较小 2、Range操作/快发慢收 3、影响数据区ODM Lua JIT Mem 1、Code cache 2、伪装成link 3、Lua执行缓存 User Dataset 静态buff 1、启动较小，比较恒定 2、管理data的hash开销 3、Key-to-slot：每key到槽 4、Repl-buff,aof-buff(32M-64M) Input buff Output buff Fake Lua LinkJIT Overhead Mgr buff + mem 总内存 = 链路内存 (动态) + 数据内存 + 管理内存(静态) OOM场景，大都是动态内存管理失效，例如限流的影响（plus timer mem），限流的时候请求出不去，导致请求堆积后 动态内存极速飙升，造成OOM；无所畏惧的Lua脚本也有可能造成OOM。 原生的Redis被定义为“缓存”，在动态内存上控制比较粗糙。Tair对这部分做了加强，致力于footprint control，售卖内 存接近User Dataset。 对于内存，阿里云有现成的功能一键分析，使用入口在“实例管理”-》“CloudDBA”下面的“缓存分析”，热Key分 析无需主动触发。数据源支持历史备份集，现有备份集，可以准实时或者对历史备份做分析。支持线上所有的社区版和企 业版。也支持线上所有的架构，包括标准版、读写分离版、集群版。 使用入口 ·“实例管理”-->“CloudDBA”-->“缓存分析”-->“立即分析”；热Key分析无需主动触发。 数据源 ·支持已有备份集； ·支持自动新建备份集。 支持版本 ·社区版（2.8~6.0）； ·企业版（Tair）。 支持架构 ·标准版； ·读写分离版； ·集群版。 下图所示，是阿里云控制台使用截图，这个功能比较常用，已开放OpenApi，可被集成。 下图所示，是缓存分析报告，可以看到每一个DB内存分布统计，包括不同类型的数据结构内存统计，key对应的元素数分 级统计，可以统计到总体上大概有多少个大key；统计 key过期时间分布，可以发现过期时间设置的是否合理。 Top 100 BigKey(按内存)，可以发现具体有哪些大key，业务上可以参照这个做优化。 Top 100 BigKey前缀是做了key pattern统 计，如果key是按照业务模块来制定的前缀，可以统计到各个业务上用了多少内存，也可以大体上指导业务优化。 （二）缓存分析–内存分布统计、bigKey，key pattern 缓存分析 – 内存分布统计、bigKey，key pattern •使用入口 -“实例管理” --> “CloudDBA” --> “缓存分析” --> “立即分析”；热Key分析无需主动触发 •数据源 -支持已有备份集 -支持自动新建备份集 •支持版本 -社区版（2.8~6.0） -企业版（Tair） •支持架构 -标准版 -读写分离版 -集群版 缓存分析 – 内存分布统计、bigKey，key pattern

25 26Redis训练营电子书 阿里云提供了在线和离线两种热Key分析方式： 在线实时分析热key ·使用入口：“实例管理” --> “CloudDBA” --> “缓存分析” -->“HotKey”； ·使用须知：Tair版，或Redis版本>=redis4.0； ·精确统计（非采样），能抓出当前所有 Per Key QPS > 3000的记录； ·参考文档：https://help.aliyun.com/document_detail/160585.html。 离线分析热key ·方法1：缓存分析也可以分析出相对较热的key，通过工具实现； ·方法2：最佳实践，imonitor命令 + redis-faina 分析出热点Key； ·方法3：使用审计日志查询历史热Key，参考文档https://help.aliyun.com/document_detail/181195.html。 Tair/Redis全链路诊断，从“APP端的SDK”到“网络”到“VIP”到“ Proxy”再到“DB”，每个部分都有可能会出 问题。 问题排查包括：前端排查和后端排查。前段排查首先需要确定是一台出问题，还是全部有问题，如果是一台出问题，大概 率是客户端自己的问题，包括： ·ECS 1. Load，内存等； 2. PPS限制。 ·客户端 1. 链接池满； 2. RT高（跨地域，gc等）； 3. 建链接慢（K8s DNS等）； 4. 大查询，发快收慢。 ·网络 1. 丢包，收敛； 2. 运营商网络抖动。 后端排查：主要是慢查和CPU排查，包括“VIP”、“ Proxy”、“DB”。Tair/Redis 80%的问题是RT（latency）相关。 ·VIP（SLB/NGLB） 1. 建链接瓶颈（极少）； 2. 流量不均衡（少）； 3. 流量瓶颈（极少）。 ·Proxy 1. 分发慢查； 2. 流量高（扩容proxy）； 3. 消息堆积； 4. Backend网络抖动。 ·DB 1. 容量，CPU，流量（见前文）； 2. 主机故障，HA速度； 3. 慢查询。 （三）热Key分析 （四）Tair/Redis全链路诊断 热Key分析 • 在线实时分析热key • 使用入口：“实例管理” --> “CloudDBA” --> “缓存分析” --> “HotKey” • 使用须知：Tair版，或Redis版本>=redis4.0 • 精确统计（非采样），能抓出当前所有 Per Key QPS > 3000的记录 • 参考文档：https://help.aliyun.com/document_detail/160585.html • 离线分析热key • 方法1：缓存分析也可以分析出相对较热的key，通过工具实现 • 方法2：最佳实践，imonitor命令 + redis-faina 分析出热点Key • 方法3：使用审计日志查询历史热Key，参考文档 https://help.aliyun.com/document_detail/181195.html

27 28Redis训练营电子书 ECS 1、Load，内存等 2、PPS限制 VIP(SLB/NGLB) 1、建链接瓶颈（极少） 2、流量不均衡（少） 3、流量瓶颈（极少） 客户端 1、链接池满 2、RT高（跨地域，gc等） 3、建链接慢（K8s DNS等） 4、大查询，发快收慢 Proxy 1、分发慢查 2、流量高（扩容proxy） 3、消息堆积 4、Backend网络抖动 前端排查：一台出问题，还是全部有问题 Tair/Redis 80%的问题是RT（latency）相关 后端排查：主要是慢查和CPU排查 DB 1、容量，CPU，流量（见前文） 2、主机故障，HA速度 3、慢查询 网络 1、丢包，收敛 2、运营商网络抖动 VIP ProxyAPP SDK 对于全链路诊断，我们推出了诊断报告功能，可以对某个时间段发起“一键诊断”，这里主要是后端排查，目前都 是“DB”相关，可以看到有哪些异常情况发生。如下图所示： 核心曲线：核心指标的曲线，可以看哪些时间点，哪些节点有峰值。 慢请求：展示了Top 10节点的Top 10慢命令统计； 性能水位：可以看到哪些指标、哪些节点超过了预设水位，或者是这些节点是不是发生了倾斜，对发现问题有很大的帮助。 诊断：准实时的对过去最近半小时，1小时，或者对过去某一天、某几天的诊断。目前还没有完全对外开放，如果有兴趣， 可以在阿里云上提工单，我们会单独开放访问。 设置合理的Proxy和DB慢日志采集参数 ·slowlog-log-slower-than：DB分片上慢日志阈值，不可设置过低！； ·slowlog-max-len：DB分片slowlog链表最大保持长度； ·rt_threshold_ms：Proxy上慢日志阈值，不可设置过低！。 以上建议使用默认的参数，不要设置过小，因为如果这些阈值设置的过小，那么DB在采集慢日志的时候会频繁记录，可能 造成引擎的性能降低，所以尽量使用默认参数。 慢日志查询功能分为历史慢日志和实时慢日志，入口也不相同，区别在于历史慢日志可获取近72小时内的慢日志。实时 慢日志能抓出当前所有分片slowlog，但是有一个局限性，如果节点发生了HA或者手动清理慢日志，这部分慢日志就没有 了。使用入口如下图所示： 历史慢日志 ·使用入口：“实例管理” --> “日志管理” --> “慢日志”； ·使用须知：Tair版，或Redis版本>=redis4.0，具体查看帮助文档； ·可获取近72小时内的慢日志。 实时慢日志 ·使用入口：“实例管理” --> “CloudDBA” --> “慢请求”； ·实时获取，能抓出当前所有分片slowlog。 （五）Tair/Redis诊断报告 （六）Tair/Redis慢日志 Tair/Redis诊断报告

29 30Redis训练营电子书 Tair/Redis慢日志 • 设置合理的Proxy和DB慢日志采集参数 • slowlog-log-slower-than：DB分片上慢日志阈值，不可设置过低！ • slowlog-max-len：DB分片slowlog链表最大保持长度 • rt_threshold_ms：Proxy上慢日志阈值，不可设置过低！ • 历史慢日志 • 使用入口：“实例管理” --> “日志管理” --> “慢日志” • 使用须知：Tair版，或Redis版本>=redis4.0，具体查看帮助文档 • 可获取近72小时内的慢日志 • 实时慢日志 • 使用入口：“实例管理” --> “CloudDBA” --> “慢请求” • 实时获取，能抓出当前所有分片slowlog 采购目标：一个24G Redis主从版。上云方案包括ECS自建Redis与云Redis服务（Redis/Tair）。 ECS自建Redis： 优点： ·便宜； ·拥有最高权限，完全自主可控，操控性强。 缺点： ·不能做到快速弹性的资源创建，业务突发高峰无法快速满足系统性能要求； ·需要专职DBA甚至是基础架构开发人员长期维护与技术演进； ·管控节点/平台需要使用第三方工具或额外研发，而且要额外购买资源安装部署； ·Redis原生社区版内核无优化； ·无专家服务兜底。 规格配置： ·实例规格和数量： ecs.r6e.xlarge （4 vCPU 32 GiB，内存平衡增强型 r6e）； ecs.g6a.large（2 vCPU 8 GiB，通用型 g6a）； ·实例数量: 2 + 3 （管控系统：2*APP+ 数据库主从/Sentinel * 3）； ·部署资源分布：主从各24G，同时按照最普遍情况（见下文计算原理）主从各预留8GB作为COW的资源，另外包含三 台服务器作为管控系统的应用服务器与数据库服务器，以及sentinel进程部署。 列表价(元/月)： 2033.6（700*2+211.2*3）。 云Redis服务（Redis/Tair） 优点： ·开箱即用，随时弹性升降配和产品类型转换； ·内核优化，如简化集群使用并支持跨SLOT多key操作的Proxy，安全加固，账号权限控制； ·众多企业级管控增值功能特性，如：高可用无脑裂、账号鉴权体系、操作审计、RDB+AOF备份、5秒监控粒度、全量 大key分析、命令读写统计等； ·性能强需求可选Tair性能增强型：具备多线程（性能是社区版的3倍）和丰富实用的数据结构，同时拥有秒级数据恢复、 （七）资源的规划–自建 VS 云Redis

31 32Redis训练营电子书 全球多活等强大功能； ·成本与大规格强需求可选Tair持久内存型与容量存储型，多种形态存储形态针对不同性能容量要求可以进一步降低成 本，并提升数据持久化能力（Tair持久内存型较内存版降成本25%、Tair 容量存储型较内存版降成本85%）； ·7*24小时专家服务支持；即使出现重大问题，有阿里云专家在线支持，可以快速止血。 缺点： ·黑盒子，不开放最高权限。 规格配置： ·版本类型：社区版； ·版本号：Redis 5.0； ·架构类型：标准版； ·节点类型：双副本； ·实例规格：24G标准版。 列表价(元/月)： 1950（成本稍低于自建，如果负载压力满足条件，进一步降低成本可以使用Tair持久内存型，可以进一步降低30%的成 本，而使用Tair容量存储型会是ECS自建的1/5成本）。 Redis的运维实战 （一）Redis社区发展历程 Redis于2009年诞生，从第一个版本至今已经经历了12年，目前也是全球最受欢迎的KV数据库，在各个领域都有大规模 的应用。社区基本上每1～2年就会有一个版本推出，大版本为X.0格式，如3.0、4.0、5.0、6.0，小版本如3.2。每一个大 版本都会有一些重要的特性，而小版本一般都会有一些局部特性的增强。 从2.8版本开始，Redis就有很多功能完备的特性，已经实现基本的数据集以及一系列使用命令，如简单的字符串String， List的数据结构，还有字典型的Hash，集合型的Set以及有序集合Sorted Set，十分贴合软件开发的实际需求。 同时，支持主备复制和持久化，对服务的可用性和数据的可靠性都有一定的保证，而且支持像事务Multi、Exec这种批量 操作。还有内置的Lua虚拟机，可以在Redis里面执行Lua脚本，以及像阻塞操作，比如Blocking的Brpop，还有事件通知 等高级特性，此时的Redis已初步具备在生产环境中使用的能力。 2015年社区推出3.0版本，发布集群Cluster这一重量级的特性。在2.8版本之前都只是支持主从版本，即最多一个节点提 供服务。集群版本之后就可以有很多节点共同组成一个集群来提供服务，这样可以有效地扩展数据的存储能力和服务的性 能。社区提供了集群管理的软件，方便平时对集群的运维。 2016年推出3.2版本，主要是对Lua复制等方面进行优化。 2017年推出4.0版本，这个版本有很多重量级的特性。如Lazy Free，可以对Big Key进行秒删，避免业务清理Big Key时 造成Latency时延的突增，让运行更平滑更稳定，业务也就更稳定。 PSYNC2是对原有的PSYNC协议的增强，在各个主从复制的场景下面做了相当多的优化，大大减少了在实际场景中进行 全量复制的情况，有效节省了CPU、磁盘还有网络带宽等资源。 Modules可以让用户自定义数据结构和命令，相比于之前的Lua脚本，Modules更为灵活，可以让Redis在各种定制的业 务中发挥更大的作用。 Redis社区 作者：仲肥 2009 2013 2015 2016 2017 2018 2020 2020 2021 First release 2.8 3.0 3.2 4.0 5.0 6.0 Antirez退出 6.2 Redis诞生 基础数据结构 主备复制 持久化 事务、lua、blocking 事件通知 集群版发布 Lua复制优化等 PSYNC2 Lazy free Modules Streams IO threads Client side cache ACL TLS Core team成立 更丰富的命令 性能优化 简化运维

33 34Redis训练营电子书 Redis于2009年诞生，从第一个版本至今已经经历了12年，目前也是全球最受欢迎的KV数据库，在各个领域都有大规模 的应用。社区基本上每1～2年就会有一个版本推出，大版本为X.0格式，如3.0、4.0、5.0、6.0，小版本如3.2。每一个大 版本都会有一些重要的特性，而小版本一般都会有一些局部特性的增强。 从2.8版本开始，Redis就有很多功能完备的特性，已经实现基本的数据集以及一系列使用命令，如简单的字符串String， List的数据结构，还有字典型的Hash，集合型的Set以及有序集合Sorted Set，十分贴合软件开发的实际需求。 同时，支持主备复制和持久化，对服务的可用性和数据的可靠性都有一定的保证，而且支持像事务Multi、Exec这种批量 操作。还有内置的Lua虚拟机，可以在Redis里面执行Lua脚本，以及像阻塞操作，比如Blocking的Brpop，还有事件通知 等高级特性，此时的Redis已初步具备在生产环境中使用的能力。 2015年社区推出3.0版本，发布集群Cluster这一重量级的特性。在2.8版本之前都只是支持主从版本，即最多一个节点提 供服务。集群版本之后就可以有很多节点共同组成一个集群来提供服务，这样可以有效地扩展数据的存储能力和服务的性 能。社区提供了集群管理的软件，方便平时对集群的运维。 2016年推出3.2版本，主要是对Lua复制等方面进行优化。 Redis发展到现在，从最初的2万行代码，到现在6.2版本已经有12万行代码。从代码量上可以看出，Redis的功能越来越 复杂，同时也意味着提供的功能越来越丰富。 标准版采用主从模式搭建，主节点提供日常的访问需求，备节点是一个热备，提供HA高可用。Master一旦发生宕机或者 其它异常，会在30秒内自动切换到备节点，保证业务平稳运行，并且兼容社区的协议。 集群版是多个Redis节点的组合，在容量和性能上都有大幅提升，满足用户对容量与高性能的需求，同时支持直连和代理 两种访问模式。 直连模式与社区Cluster协议完全一致，这同时需要业务使用支持Cluster协议的 Smart Client 接入访问。代理模式额外开发 了Proxy组件，通过Proxy组件访问业务的话，就可以只通过一个统一的地址访问Redis集群。客户端的请求会通过代理服 务器转发到不同的分片，不需要Smart Client就可以访问整个Redis的集群，降低了应用开发的难度和业务代码的复杂度。 读写分离板是由主备节点和只读节点以及Proxy代理一起组成的系统。代理节点会自动把读写请求路由分发到Master节点 和只读节点，用来支撑这种写少读多的业务场景。 Redis系列产品主要分为三大系列，分别是标准版、集群版与读写分离版，适用于不同的业务场景。 （二）Redis社区现状 （二）阿里云Redis运维体系 目前社区Core Team一共有5名成员，3名来自于Redis Labs，1名来自亚马逊云服务（AWS），1名来自阿里云，这5名 成员共同组成了Core Team，维护社区的建设。 目前，Core Team每两周会举行一次线上会议，会议内容如PR要不要合并，然后有没有一些好的建议能从用户那边吸收过 来的，有没有一些用户的需求可以得到实现，大家提出来的这些Issue要如何解决，同时也会讨论制定未来的发展方向，如 7.0版本的Roadmap现在就正在讨论中。 比如要对主从复制、持久化与资源管理等做优化。由于现在管理Redis内存的话，数据区跟管理区是没有区分的，因此7.0 版本在这方面也会做出优化。 代码行数 2.0 0 20000 40000 60000 80000 100000 120000 140000 2.2 2.4 2.6 2.8 3.0 3.2 4.0 5.0 6.0 6.2 （一）阿里云Redis产品系列 阿里云Redis 自定义告警 账号/安全 日志/审计 参数调节 备份/恢复 数据分析 细粒度监控 连接管理 热点/慢日志 控制台

35 36Redis训练营电子书 阿里云建立了一套Redis的运维体系，涵盖日常运维管理各方面的需求，例如实例运行状况实时和历史的监控，配置告 警，修改参数等，以及在接入层提供各种类型的连接访问。 数据安全方面开发了账号体系，在网络安全方面开发了SSL提供网络安全传输加密，以及定期的备份恢复功能。如果发生误 操作的话，也可以及时恢复数据，并且支持实时的热点分析以及离线的数据分析，让用户对业务的运行状态有更直观的了解。 同时我们还提供了审计日志，当业务需要纠察时可以进行溯源，这些功能都可以通过控制台来接入使用。 集群版支持对集群架构下面各种指标的查看，如Proxy节点的运行指标，独立数据节点运行指标等，同时也可以查看节点 聚合的运行状态。 用户对于监控频率有需求的话，可以设置监控的频率，默认为60秒/次。如果说需要细粒度监控，可以在控制台上进行修 改。目前支持最细粒度为是5秒/次采集。 在连接管理方面，我们同时支持内网的VPC网络访问和公网访问，公网访问一般是做练习或者调试。 在集群版的话，我们提供直连访问和Proxy普通访问的方式，都可以在控制台连接管理进行开通。 登录控制台 -> 点击实例ID -> 账号管理 -> 创建账号 性能监控是非常基础且有用的一环，也是用户经常使用的功能。 Redis提供了非常丰富的监控项，从实例的基础运行状态，如CPU、内存、QPS和网络带宽，以及各种类型Key的数量， 如过期key是否被删除，Key的总量等。还有像实例运行的最大延迟，平均延迟，支持自定义监控项，对各种数据结构进 行监控。 1.标准版 1.创建账号 2.集群版 3.监控频率 （三）性能监控 （四）连接管理 （五）账号管理

37 38Redis训练营电子书 关于账号管理，在实际的业务场景中，有时一个实例可能会有多个业务线使用，不同的业务线用法不一样。 为了避免相互干扰，需要做好权限控制。目前云Redis支持设置账号管理体系，支持读写账号和只读账号，帮助用户更加 灵活地管理实例，最大限度避免误操作，提升数据的安全性。 审计日志是对实际的运行操作记录提供的一站式管理服务，由阿里巴巴集团经历了大量大数据场景之后锤炼而成，业务无 需额外的开发，就可以在云端完成运行日志的采集、消费投递以及查询分析，是提升运维与运营效率非常有用的工具。 审计日志服务可以帮助用户时刻掌握产品的运行状况和安全。 具体操作步骤如下： 1）登录控制台 2）点击实例ID进入实例管理页面 3）点击日志管理->审计日志 4）选择审计日志设置 5）开通服务 开通审计日志之后，系统会记录写操作，也就是对数据进行修改后的操作就都会被记录下来。审计的操作会有额外的性能 消耗，大概有5%～15%的性能损失。 2.查询日志 审计日志开通之后，如果用户需要查看数据库运行的历史记录，包括写请求的记录，可以在审计日志查询进行操作，寻找 Release的资源突增的这些原因。 例如查找哪些数据被修改、删除的记录，云数据库Redis版的审计日志就可以提供这些线索，通过不同的过滤条件筛选日 志，精确的定位目标记录，可以选择划定时间，然后根据关键字，如IP，执行过哪些命令，有哪些账号访问等关键字来对 审计日志进行过滤，定位到之前的操作记录。 首先进入实例的管理页面，然后点击账号管理，进入后在右上角点击创建账号，就可以看到新建一个读写或者只读的账号。 2.权限修改 另外，用户可以对已有的账号进行修改。比如说可以把一个只读的账号改为读写账号。如果账号不再使用，也可以进行删 除，非常方便地满足日常运维的管理需求。 （六）审计日志 1.开通服务