Tair（以及Redis开源版）实例的CPU使用率升高可能是由于以下三种原因：高并发、高吞吐的业务消耗较多CPU资源，如果CPU资源未达到瓶颈，属于正常业务场景；业务运行超预期，Redis开源版实例的CPU资源无法满足业务需求，可通过增加分片数、副本数或者升级为Tair（企业版）来解决资源瓶颈；使用不当，例如高消耗命令、热Key、大Key等，导致CPU使用率异常升高。当平均CPU使用率高于70%、连续5分钟内的CPU平均峰值使用率高于90%时，您需要及时关注并排查该问题，以保障应用的稳定运行。
哪些因素会导致CPU使用率异常升高
高消耗命令：即时间复杂度为O(N)的命令，其中N为较大值，例如KEYS、HGETALL或使用MGET、MSET、HMSET、HMGET一次操作大量Key等。通常情况下，命令的时间复杂度越高，在执行时会消耗越多的资源，从而导致CPU使用率上升。
由于命令执行单元为单线程的特性，实例在执行高消耗命令时会引发排队导致应用响应变慢。极端情况下，甚至可能导致实例被整体阻塞，引发应用超时中断或流量跳过缓存层直接到达后端的数据库侧，引发雪崩效应。
说明关于各命令对应的时间复杂度信息，请参见Redis官网。
热Key：某个或某部分Key的请求访问次数显著超过其他Key时，代表此时可能产生了热Key。热Key将会消耗实例的大量CPU资源，从而影响其他Key的访问时延。并且，在集群架构中，如果热Key较为集中地分布在部分数据分片节点，可能会导致CPU使用率倾斜（个别分片的CPU使用率远超其他分片）。
大Key：大Key会占用更多的内存，同时，对大Key的访问会显著增加实例的CPU负载和流量。大Key在一定程度上更容易形成热点从而造成CPU使用率高。如果大Key较为集中地分布在部分数据分片节点，可能会导致CPU使用率倾斜、带宽使用率倾斜及内存使用率倾斜。
短连接：频繁地建立连接，导致实例的大量资源消耗在连接处理上。
AOF：实例默认开启了AOF（append-only file），当实例处于高负载状态时，AOF的写盘行为将会导致CPU使用率升高及实例整体的响应时延增加。
CPU使用率异常升高的现象分类
CPU使用率高，主要分为以下三种现象：
在某个时间段，CPU使用率突然升高，甚至到100%。原因排查和解决方案，请参见CPU使用率突然升高。
某个数据节点的CPU使用率较高，而其他数据节点的CPU使用率较低。原因排查和解决方案，请参见数据节点CPU使用率不一致。
某个Proxy节点的CPU使用率较高，而其他Proxy节点的CPU使用率较低。原因排查和解决方案，请参见代理节点CPU使用率不一致。
请根据不同现象，分别采取措施降低CPU使用率。
CPU使用率突然升高
如果实例全局的CPU使用率升高，可参考以下步骤排查并优化。
排查并禁用高消耗命令
排查步骤
通过性能监控功能，确认CPU使用率高的具体时间段。具体操作，请参见查看性能监控。
通过下述方法，找出高消耗的命令：
解决办法
评估并禁用高风险命令和高消耗命令，例如FLUSHALL、KEYS、HGETALL等。具体操作，请参见禁用高风险命令。
可选：根据业务情况，选择下述方法对实例进行调整：
说明如何变更实例的架构和类型，请参见变更实例配置。
排查并优化短连接
排查步骤
通过性能监控功能，确认CPU使用率高的具体时间段。具体操作，请参见查看性能监控。
在性能监控页面，查看是否有CPU使用率较高，连接数较高，但QPS（每秒访问次数）未达到预期的现象。如果有，说明可能存在短连接，请参考下文的解决方法。
解决方法
关闭AOF
实例默认开启了AOF（append-only file），当实例处于高负载状态时，频繁地执行AOF会一定程度上导致CPU使用率升高。
在业务允许的前提下，您可以考虑关闭持久化。另外将实例的数据备份时间设定到低访问/维护时间窗口内，降低影响。
如果您的实例为Tair内存型，关闭AOF后，您将无法通过AOF文件恢复数据（即无法使用数据闪回功能），仅能通过备份集恢复数据（即从备份集恢复至新实例），请谨慎操作。
评估服务能力
经过上文的步骤排查优化后，在业务正常运行的情况下，还是经常遇到实例整体的负载较高（平均CPU使用率在70%以上），可能存在性能瓶颈。
首先，应排查是否存在异常的业务访问，例如异常的命令、来自某台应用主机的异常访问等，此类情况需要从业务上进行优化。如果均为正常访问，此时的高负载是正常业务行为，为保障业务平稳运行，建议升级实例的规格，或将其升级为集群架构或读写分离架构。关于如何升级实例，请参见变更实例配置。
为保障业务的正常运行，在正式升级实例前，建议先购买一个按量付费的实例，完成业务负载和兼容性测试，测试完成后可将其释放。
数据节点CPU使用率不一致
如果实例为集群架构或读写分离架构，您发现实例的部分数据分片节点的CPU使用率高，而其他数据分片节点的CPU使用率较低，可参考以下步骤排查并优化。
排查并优化热点Key
排查步骤
通过性能监控功能，确认CPU使用率高的具体时间段。具体操作，请参见查看性能监控。
在实时Top Key统计的历史页面，选择CPU使用率高的数据节点，然后根据步骤1，选择时间筛选条件，单击查看，可看到CPU使用率高的时间段内有哪些热点Key。具体操作，请参见实时Top Key统计。
解决方法
启用代理查询缓存功能（Proxy Query Cache），代理节点会缓存热点Key对应的请求和查询结果，当在有效时间内收到同样的请求时直接返回结果至客户端，无需和后端的数据分片交互，可改善对热点Key的发起大量读请求导致的访问倾斜。通过Proxy Query Cache优化热点Key问题。
如果热Key的产生来自于读请求，您可以将实例改造成读写分离架构来降低每个数据分片的读请求压力。
说明在请求量极大的场景下，读写分离架构会产生不可避免的延迟，此时会有读取到脏数据的问题。因此，在读、写压力都较大且对数据一致性要求很高的场景下，读写分离架构并不是最优方案。
排查并禁用高消耗命令
排查步骤
通过性能监控功能，确认CPU使用率高的具体时间段。具体操作，请参见查看性能监控。
通过下述方法，找出高消耗的命令：
解决办法
评估并禁用高风险命令和高消耗命令，例如FLUSHALL、KEYS、HGETALL等。具体操作，请参见禁用高风险命令。
排查并优化大Key
排查步骤
通过性能监控功能，确认CPU使用率高的具体时间段。具体操作，请参见查看性能监控。
在离线全量Key分析的页面，单击立即分析。选择CPU使用率高的数据节点，单击确定，可看到CPU使用率高的时间段内有哪些大Key。具体操作，请参见离线全量Key分析。
解决方法
根据业务的实际情况，将大Key拆分为小Key，以分散请求压力。
代理节点CPU使用率不一致
如果实例为集群架构或读写分离架构，您发现实例的部分Proxy节点的CPU使用率高，而其他代理分片节点的CPU使用率较低，可参考以下步骤排查并优化。
排查步骤
在性能趋势的代理节点页面，确认连接数使用率是否均衡。具体操作，请参见性能趋势。
解决方法
根据连接数使用率是否均衡，采取下述措施：
均衡：重启业务所属的客户端或Proxy节点使连接重分配。重启Proxy节点，请参见重启或重搭代理节点。
不均衡：通常因pipeline或batch的操作规模过大引起，需要减少对应的操作规模，例如将其拆分为多个操作来执行。