即使在大Key存在的一些业务场景，GaussDB(for Redis)的表现也是远优于开源Redis的。下面将介绍大Key经常引起的一些问题：
1、大key引发了CPU 100%，阻塞生产业务
在开源Redis中，大key容易引起CPU占用100%，使生产业务受损，引起线上问题。这是因为开源Redis本身就是单线程，尤其在这种比较脆弱的架构下使用大key，更容易引起线程阻塞，从而影响整个实例。
GaussDB(for Redis)的多线程架构天然就对大key更友好，不会有这个问题困扰。即使单个线程被个别大Key影响，整个GaussDB(for Redis)实例包含数十、上百个线程，整体业务基本都不会受到干扰。
2、大key因个别分片带宽高，被Redis频繁“流控”
目前市面上有一些开源Redis是基于一个大的容器混合部署很多租户的Redis进程，但在这种架构下，为了避免一个客户的Redis影响其他客户，往往会对客户的Redis进程进行流量控制，当某个客户业务中对大key有较为频繁的操作时，很容易触发给客户设定的该租户的带宽阈值并触发流控，从而导致线上业务受损。
相比之下，GaussDB(for Redis)的每个分片都是一个独立的容器，是客户的独享资源，更可靠，连接数、带宽等资源不设主动流控，尤其是节点带宽资源的“天花板”非常高。
3、大key导致倾斜，分片内存占用不均匀
开源Redis集群中，存储大key会导致内存空间不均匀、消耗不均衡，大key所在分片有OOM风险。
GaussDB(for Redis)采用高性能存储池，不会对某个节点分片造成数据量的倾斜，支持大key可靠存储，不会导致分片OOM。
GaussDB(for Redis)支持秒级无感扩容，不论扩容量，还是扩CPU，都不需要搬迁数据，因此也不受大Key影响，运维体验极佳。
