Redis最佳实践与实战指南.pdf

Redis训练营电子书Redis最佳实践与实战指南源码核心贡献者带你学习Redis关键技术阿里云数据库1Redis训练营电子书31432466073Redis开发实操之春运迁徙页面Redis的运维实战Redis的开发规范和常见问题Redis架构与介质选择指引Redis 的高并发实战：抢购系统Redis生态Redis训练营阿里云Redis官网GitHub-Alibaba/TairHashGitHub-Alibaba/TairStringRedis实战课程34Redis训练营电子书Redis架构与介质选择指引（一）标准版如上图所示，Redis集群架构分为两大类：标准版与集群版。标准版是最原始的Redis单进程模式，标准版细分为双副本、单副本、读写分离三个类别。集群版分为代理模式与直连模式。业务从标准版迁移到集群版时的可能存在Redis命令不兼容，代理模式可以通过Proxy帮业务解决这方面问题。直连模式中，Redis Client通过Redis Cluster模式直连Redis DB节点，做到减少网络时延，提升一定的性能。这两种连接模式下分别支持了双副本跟单副本两种数据形态。Redis集群架构作者：民科Redis标准版单副本双副本读写分离代理模式直连模式双副本单副本集群版ECSSLB:Classic/VPCHA故障迁移进程BReplica进程AMasterECSSLB:Classic/VPCHAFailoverProcess BProcess AMaster如上图所示，标准版的拓扑结构是业务在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进程有同步延迟，可能存在部分数据丢失。此外，在双副本中可以做数据的克隆，即备份机，备份到另一个地方做数据持久化。当业务需要做数据回滚时，可以从备份机上进行恢复。ECSSLB:Classic/VPCHA故障迁移进程BReplica进程AMaster56Redis训练营电子书标准版-单副本采用单个数据库节点部署架构，没有可实时同步数据的备用节点，不提供数据持久化和备份策略，使用于数据可靠性要求不高的纯缓存业务场景使用。特点：1.纯缓存类业务使用，单副本只有一个在线数据节点，性价比高；2.阿里云自研HA高可用系统，异常30秒自动切换。单副本在使用时需要注意，当高可用节点A宕机后，需要先对B节点进行缓存的预热，避免切换后发现B节点无数据可用。3.读写分离2.标准版 单副本ECSSLB:Classic/VPCHAFailoverProcess BProcess AMasterECS实例读/写请求读请求读请求读请求主节点Proxy节点数据分片只读节点1高可用系统监控所有节点只读节点2只读节点N主节点同步数据针对读多写少的业务场景，云数据库Redis推出了读写分离版的产品形态，提供高可用、高性能、灵活的读写分离服务，满足热点数据集中及高并发读取的业务需求，最大化地节约运维成本。ECS实例通过Proxy节点，可以将读写请求分发到主节点数据分片，并将部分读请求分发到其他只读节点。使用场景：1.读取请求QPS压力较大：适合读多写少型业务；2.对Redis协议兼容要求较高的业务。建议与使用须知：1.非特殊需求不建议使用，QPS压力大的业务建议使用集群版；2.当一个只读节点发生故障时，请求会转发到其他节点；如果所有只读节点均不可用，请求会全部转发到主节点，导致主节点压力过大；3.只读节点发生异常时，高可用系统会暂停异常节点服务进行重搭恢复，但不承诺只读节点的恢复时间指标；4.只读节点数据旧于主节点且落后时间可能很长。使用场景：1.数据量较大的场景；2.QPS压力较大的场景；3.吞吐密集型（网络带宽较大）应用场景。（二）集群版ECSSLB:Classic/VPCHAMaster 1HAHAProxyServersConfigServerMaster 2Master NECSSLB:Classic/VPCMaster 1ProxyServersConfigServerMaster 2Master NReplica 1Replica 2Replica N78Redis训练营电子书云数据库Redis版提供双副本集群版实例，可轻松突破Redis自身单线程瓶颈，满足大容量、高性能的业务需求。集群版支持代理和直连两种连接模式。使用场景：1.数据量大：相比Redis标准版，集群版可以有效地扩展存储量，最大可达4098 GB，能有效的满足业务扩展的需求；2.QPS压力较大：标准版Redis无法支撑较大的QPS，需要采用多分片的部署方式来突破Redis单线程的性能瓶颈；3.吞吐密集型应用：相比Redis标准版，集群版的内网吞吐限制相对较低，可以更好地支持热点数据读取、大吞吐类业务；4.对Redis协议兼容性不敏感的应用：集群版对Redis协议支持上相比标准版本有一定的限制。1.集群版 双副本Proxy代理模式直连模式ECSSLB:Classic/VPCHAMaster 1HAHAProxyServersConfigServerMaster 2Master NReplica 1Replica 2Replica NECSHASLBMaster 1HAHAMaster 2Master NReplica 1Replica 2Replica NVIPVIPVIPRedis Cluster ProtocolFirst time特点：代理模式因所有请求都需要通过代理服务器转发，代理模式在降低业务开发难度的同时也会小幅度影响Redis服务的响应速度，如果业务响应速度的要求非常高，可以选择直连模式，绕过代理服务器直连后端数据分片，从而降低网络开销和服务响应时间，直连模式适用于对响应要求较高的业务。2.集群版 命令限制不支持命令1.SWAPDB2.CLIENT ID3.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官方文档。受限命令族HyperLogLogPFMERGE,PFCOUNTRENAME,RENAMENX,SORTRPOPLPUSH,BRPOP,BLPOP,BRPOPLPUSHEVAL,EVALSHA,SCRIPT EXISTS,SCRIPT FLUSH,SCRIPT KILL,SCRIPT LOADMSETNXDISCARD,EXEC,MULTI,UNWATCH,WATCHKeysListsScriptingStringsTransaction具体命令910Redis训练营电子书如上图所示，简言之，如果业务qps低且容量低（小于32GB）选择标准版，否则选择集群版。在选择标准版的情况下，根据数据可靠性与读写情况可再进行细分。如果业务数据单纯作为缓存加速或数据可丢，可以选择单副本，减少一半的成本。如果要求数据在异常情况下不能全部丢失，对可靠性要求较高的情况下，此时要根据读写情况进行选择。如果读写情况没有明显差异，可以选择双副本，如果读请求数量远大于写请求，可以选择读写分离。但是除去特殊情况，读写分离有诸多限制，大多数情况下不是一个很好的选择，我们还是建议考虑集群的模式。如果用户原本使用标准版，随着业务的发展QPS容量上升，需要由标准版切换成集群版，根据命令兼容性可选择不同模式。3.集群模式如何选型选型时应注意以下两点：1.评估QPS和容量时一定要为未来留有余量；2.不同架构间存在一定的兼容性问题，业务允许的情况下尽量使用不同架构命令支持集合的交集，以便后续架构切换。StartQPS低低低高高高标准版集群版容量容量标准版可靠性低高否是双副本单副本读写分离读多写少集群版兼容性高低代理模式直连模式低高单副本双副本可靠性如果用户业务代码有太多需要修改，或者不想修改代码，对命令兼容性要求较高，可以选择代理模式，兼容性问题由阿里云提供的Proxy解决。如果业务对兼容性要求较低，或者新业务在开发时本就是按照集群版标准进行，则可选择直连模式。模式选择完之后，可根据业务对数据可靠性的要求，进一步选择单副本或双副本。此处的单双副本使用注意事项，与标准版类似。Redis存储介质持久内存型内存型容量存储型混合存储型Redis购买Redis时还需选择存储介质，目前阿里云提供四种存储介质，分别为内存型、持久内存型、容量存储型和混合存储型。内存型为我们常见的纯内存，混合存储型正逐步被持久内存型与容量存储型替代，下面重点介绍持久内存型与容量存储型。Redis企业版持久内存型（简称持久内存型）基于Intel傲腾TM数据中心级持久内存（AEP），为用户提供大容量、兼容Redis的内存数据库产品。单实例成本对比Redis社区版最高可降低30%，且数据持久化不依赖传统磁盘，保证每个操作持久化的同时提供近乎Redis社区版的吞吐和延时，极大提升业务数据可靠性。特点：1.超高性价比：相同容量下对比阿里云Redis社区版本，价格降低30%左右；2.大规格优化：解决AOF的造成的性能开销，无需在性能和持久化之间取舍；3.掉电数据不丢失：每个写操作都同步持久化；4.高兼容性：兼容现有阿里云Redis数据库体系。（一）持久内存型CPUProcessingMemory HierarchySize:1xLatency:1xSize:10 xLatency:100 xSize:100 xLatency:1,000 xSize:100 xLatency:100,000 xSize:10,000 xLatency:10,000,000 xMemoryStorage将内存持久化到硬盘SCMSSDHDDDRAMNVDIMM1112Redis训练营电子书从社区到企业版Redis企业版容量存储型（简称容量存储型）基于云盘ESSD研发，兼容Redis核心数据结构与接口，可提供大容量、低成本、强持久化的数据库服务。容量存储型在降低成本和提升数据可靠性的同时，也解决了原生Redis固有的Fork命令而预留部分内存的问题。适用于兼容Redis、需要大容量且较高访问性能的温冷数据存储场景。特点：1.兼容性：兼容大部分原生Redis命令；2.成本：最低为Redis社区版的15%。（一）阿里云集群能力（二）开源Redis集群实现（二）容量存储型集群能力对比高可靠管控高可用迁移平滑性成本迁移异常，丢失部分数据，需手动恢复无中心化控制集群状态收敛慢怠机需手动进行重搭扩缩容需借助额外服务高可用心跳探测准确性受慢查询影响，造成故障切换时间过长或者切换不准确数据高可靠，迁移失败自动回滚可重试中心化控制迅速准确日常运维由系统自动完成自研探测机制规避慢查询风险导致的误切换高可用探测更准确故障切换时间平均8秒，SLA15秒无感迁移无明显rt上涨无新增错误低支持细粒度扩缩容集群内存是用优化大Key迁移影响服务RT，严重时触发HALua脚本丢失迁移期间多key命令失败高集群模式有额外内存开销，大key小value场景内存容量接近翻倍开源版Redis阿里云Redis阿里云Redis与开源版Redis集群能力对比GossipClientBClientAClientC实现细节：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 低RT能让我的服务运行的更好;我把存储都公用在一个redis里。区分cache和内存数据库用法，区分应用;我有一个大排行榜/大集合/大链表/消息队列；我觉得服务能力足够了。尽量拆散，服务能力不够可通过分布式集群版可以打散;我有一个特别大的Value，存在redis里，访问能好些。redis吞吐量有瓶颈。Redis不要触碰边界Redis阿里内部开发规约高计算消耗高网络消耗高存储消耗Wildcard模块结构化操作复杂Lua事务Lua并发点查Bigkey审计大Value高并发访问集群mget/msetHuge Batch mget/msetKeys等扫全表通用命令运算复杂结构小rangeStreaming慢消费1对N PUBSUBN200全局配置/热点企业版（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，严重造成数据倾斜。1920Redis训练营电子书Sharding Function100个keyKey1 val1key2 val2key100 val100102个keyKey200 val200key201 val201key302 val302102个keyKey500 val500key501 val501key602 val602101个key，中间有一个放了200w 的hashKey300 val300Hash301 skey1 val1skey2 val2skey200000 val2000000key401 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打满、服务夯住。TransactionTransaction是一种伪事物，没有回滚条件；集群版需要所有key使用hashtag保证，代码比较复杂，hashtag也可能导致算力和存储倾斜；Lua中封装了multi-exec，但更耗费CPU，比如编译、加载时，经常出现问题。PipelinePipeline用的比较多，如下面的示意图，实际上是把多个请求封装在一个请求中，合并在一个请求里发送，服务端一次性返回，能够有效减少IO，提高执行效率。需要注意的是，用户需要聚合小的命令，避免在pipeline里做大range。注意Pipeline中的批量任务不是原子执行的（从来不是），所以要处理Pipeline其中部分命令失败的场景。KEYS命令，一定会出问题，即使当前没有，客户数据量上涨后必然引发慢查，出现后无能为力。这种情况，需要在一开始就提前预防，可以在控制台通过危险命令禁用，禁止掉keys命令，出现时也可以使用一些手段优化。KEYS命令的模糊匹配：Redis存储key是无序的，匹配时必然全表扫描，key数目一多必然卡住，所以一定要去优化。如下图所例子中所示，修改为hash结构：可以从全表扫描变为点查/部分range,虽然hash结构中field太多也会慢，但比keys性能提升一个到两个数量级。Script+EVALSHA1、可以先把脚本在redis中预编译和加载（不会unload和clean），使用EVALSHA执行2、会比纯EVAL省CPU，但是Redis重启/切换/变配code cache会失效，需要reload3、仍是缺陷方案。建议使用复杂数据结构，或者module来取代luaEVAL scriptSCRIPT LoadEVALSHARecord SHARedisReturn ResultReturn ResultReturn SHALua JIT CompileLoading bytecodeunloadCleaningGuarded by TXNRun With ParamprocessCommandThe LUA Iceberg inside Redis1、脚本的compile-load-run-unload非常耗费CPU2、整个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 123NormalPipelinedApplicationOKINCR key1124INCR key1125ApplicationSET key1123INCR key1INCR key1OK1241252122Redis训练营电子书这个例子里面，Product1前缀可以提取成为hash的KEY，如果要去product1前缀的所有东西，其实可以下发一个HGETALL，这样的就是优化了。一定会出问题（sooner or later）客户数据量上涨后必然引发的慢查出现后无能为力可以在控制台通过危险命令禁用优化product_23:nameproduct_7788:descproduct_32123:priceiamotherkey:11random:nameproduct_1:nameredis:is:not:orderedhello:slowlogproduct_11:whateverproduct_1:price修改为hash结构：安全表扫描为点查/部分range虽然hash结构中field太多也会慢，但比keys性能提升一个到两个数量级KEYS命令的模糊匹配：Redis的存储key是无序的，必然全表扫描Key数目一多必然卡住product_1 name:iphone price:2999product_23:nameproduct_7788:descproduct_32123:priceiamotherkey:11random:nameproduct_1 name priceredis:is:not:orderedhello:slowlogproduct_11:whateverKEYS 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的API4.接受主动运维在阿里云上，如果机器宕机，或者是机器后面有风险，我们会做主动运维保证服务的稳定性。内存控制是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（32M64M）通常来说比较小。（一）Tair/Redis内存模型Redis常见问题处理2324Redis训练营电子书Per link Mem1、正常较小2、Range操作/快发慢收3、影响数据区ODMLua JIT Mem1、Code cache2、伪装成link3、Lua执行缓存User Dataset静态buff1、启动较小，比较恒定2、管理data的hash开销3、Key-to-slot：每key到槽4、Repl-buff,aof-buff(32M-64M)InputbuffOutputbuffFake LuaLinkJITOverheadMgrbuff+mem总内存=链路内存(动态)+数据内存+管理内存(静态)OOM场景，大都是动态内存管理失效，例如限流的影响（plus timer mem），限流的时候请求出不去，导致请求堆积后动态内存极速飙升，造成OOM；无所畏惧的Lua脚本也有可能造成OOM。原生的Redis被定义为“缓存”，在动态内存上控制比较粗糙。Tair对这部分做了加强，致力于footprint control，售卖内存接近User Dataset。对于内存，阿里云有现成的功能一键分析，使用入口在“实例管理”-“CloudDBA”下面的“缓存分析”，热Key分析无需主动触发。数据源支持历史备份集，现有备份集，可以准实时或者对历史备份做分析。支持线上所有的社区版和企业版。也支持线上所有的架构，包括标准版、读写分离版、集群版。使用入口“实例管理”-“CloudDBA”-“缓存分析”-“立即分析”；热Key分析无需主动触发。数据源支持已有备份集；支持自动新建备份集。支持版本社区版（2.86.0）；企业版（Tair）。支持架构标准版；读写分离版；集群版。下图所示，是阿里云控制台使用截图，这个功能比较常用，已开放OpenApi，可被集成。下图所示，是缓存分析报告，可以看到每一个DB内存分布统计，包括不同类型的数据结构内存统计，key对应的元素数分级统计，可以统计到总体上大概有多少个大key；统计 key过期时间分布，可以发现过期时间设置的是否合理。Top 100 BigKey(按内存)，可以发现具体有哪些大key，业务上可以参照这个做优化。Top 100 BigKey前缀是做了key pattern统计，如果key是按照业务模块来制定的前缀，可以统计到各个业务上用了多少内存，也可以大体上指导业务优化。（二）缓存分析内存分布统计、bigKey，key pattern2526Redis训练营电子书阿里云提供了在线和离线两种热Key分析方式：在线实时分析热key使用入口：“实例管理”-“CloudDBA”-“缓存分析”-“HotKey”；使用须知：Tair版，或Redis版本=redis4.0；精确统计（非采样），能抓出当前所有 Per Key QPS 3000的记录；参考文档：https:/ 分析出热点Key；方法3：使用审计日志查询历史热Key，参考文档https:/ DNS等）；4.大查询，发快收慢。网络1.丢包，收敛；2.运营商网络抖动。后端排查：主要是慢查和CPU排查，包括“VIP”、“Proxy”、“DB”。Tair/Redis 80%的问题是RT（latency）相关。VIP（SLB/NGLB）1.建链接瓶颈（极少）；2.流量不均衡（少）；3.流量瓶颈（极少）。Proxy1.分发慢查；2.流量高（扩容proxy）；3.消息堆积；4.Backend网络抖动。DB1.容量，CPU，流量（见前文）；2.主机故障，HA速度；3.慢查询。（三）热Key分析（四）Tair/Redis全链路诊断热Key分析 在线实时分析热key使用入口：“实例管理”-“CloudDBA”-“缓存分析”-“HotKey”使用须知：Tair版，或Redis版本=redis4.0精确统计（非采样），能抓出当前所有 Per Key QPS 3000的记录参考文档：https:/ 离线分析热key方法1：缓存分析也可以分析出相对较热的key，通过工具实现方法2：最佳实践，imonitor命令+redis-faina 分析出热点Key方法3：使用审计日志查询历史热Key，参考文档https:/ DNS等）4、大查询，发快收慢Proxy1、分发慢查2、流量高（扩容proxy）3、消息堆积4、Backend网络抖动前端排查：一台出问题，还是全部有问题Tair/Redis 80%的问题是RT（latency）相关后端排查：主要是慢查和CPU排查DB1、容量，CPU，流量（见前文）2、主机故障，HA速度3、慢查询网络1、丢包，收敛2、运营商网络抖动VIPProxyAPPSDK对于全链路诊断，我们推出了诊断报告功能，可以对某个时间段发起“一键诊断”，这里主要是后端排查，目前都是“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慢日志2930Redis训练营电子书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 云Redis3132Redis训练营电子书全球多活等强大功能；成本与大规格强需求可选Tair持久内存型与容量存储型，多种形态存储形态针对不同性能容量要求可以进一步降低成本，并提升数据持久化能力（Tair持久内存型较内存版降成本25%、Tair 容量