Redis缓存原理与实战应用

20XX/XX/XXRedis缓存原理与实战应用汇报人:XXXCONTENTS目录01

Redis核心数据结构解析02

缓存策略与机制03

Redis分布式部署方案04

实战场景应用05

性能优化实践06

实战操作演示Redis核心数据结构解析01String类型核心特性RedisString是二进制安全的动态字符串，支持存储文本、数字及二进制数据，单个值最大容量512MB。底层采用SDS结构，通过预分配冗余空间和惰性释放策略减少内存分配开销，支持O(1)时间复杂度的长度获取和原子增减操作。基础缓存应用作为最常用的缓存类型，String适合存储用户信息、商品详情等结构化数据。例如将用户对象序列化为JSON字符串，以"user:info:1001"为键存储，设置合理TTL实现自动过期，可将数据库查询延迟从毫秒级降至微秒级。分布式计数器实现利用INCR/DECR命令的原子性，可实现高并发场景下的计数器功能。如视频播放量统计，通过"video:play:10086"键执行INCR操作，确保计数准确性，支持每秒10万级QPS的计数需求，广泛应用于阅读量、点赞数等场景。分布式锁实践基于SETNXEX命令实现分布式锁，例如"SETlock:ordertrueNXEX10"，仅当锁不存在时设置成功，结合唯一Value和过期时间防止死锁。Redisson等客户端已封装Redlock算法，解决单点故障问题，保障分布式环境下的资源互斥访问。String类型及应用场景Hash类型及对象存储实践Hash类型核心特性

Hash类型是一个键值对集合，适合存储对象信息，支持字段级操作。底层根据字段数量和大小自动选择压缩列表（ziplist）或哈希表（hashtable）编码，实现内存优化。常用命令与操作示例

HSETuser:1001name"张三"age25：存储用户对象；HGETuser:1001age：获取用户年龄；HINCRBYuser:1001balance100：原子增减字段值；HGETALLuser:1001：获取全部字段。对象存储场景应用

电商购物车：以用户ID为key，商品ID为field，数量为value，支持单独增减商品数量；用户信息缓存：拆分存储用户属性，实现部分更新，减少网络传输量。与String类型对比优势

相比String存储JSON对象，Hash类型无需全量序列化/反序列化，支持单个字段修改，节省内存和网络开销。例如更新用户年龄时，仅需HSET操作，无需传输整个对象。List类型与消息队列实现

List类型核心特性RedisList是有序字符串集合，基于双向链表实现，支持LPUSH/RPUSH头部/尾部插入，LPOP/RPOP头部/尾部弹出，BRPOP阻塞式弹出等操作，适合构建队列、栈等数据结构。

消息队列基础实现方案使用LPUSH命令从左侧生产消息，如LPUSHtask_queue"order_1001"；消费者通过BRPOPtask_queue0命令阻塞获取消息，0表示永久阻塞直到有消息，实现简单的FIFO消息队列。

实战案例：分布式任务队列电商订单处理场景：生产者LPUSHorder_tasks"{\"orderId\":1001,\"action\":\"pay\"}"，消费者服务通过BRPOP阻塞消费，处理订单支付逻辑，保障任务不丢失且顺序执行。

消息队列局限性与优化原生List队列缺乏消息确认机制和持久化保障，高版本可使用Stream结构替代，支持消费者组、消息ACK和持久化，适合更复杂的消息场景。Set与SortedSet典型应用01Set：自动去重与集合运算Set是无序且元素唯一的集合，支持交集（SINTER）、并集（SUNION）、差集（SDIFF）等运算。适用于标签系统、共同好友计算、抽奖系统等场景，利用其自动去重特性可实现高效数据管理。02Set实战案例：社交关系计算通过SINTER命令计算共同好友，如用户A关注列表（SetA）与用户B关注列表（SetB）的交集，快速获取共同关注用户ID。某社交平台利用此特性，将共同好友查询响应时间从500ms降至10ms。03SortedSet：带权重的有序集合SortedSet（ZSet）为每个元素关联分数（Score），支持按分数排序和范围查询。核心应用包括排行榜、延迟队列、滑动窗口限流等，通过ZADD、ZREVRANGE等命令实现高效排序与统计。04SortedSet实战案例：实时排行榜电商平台商品热度榜使用ZSet存储商品ID及点击量，通过ZREVRANGE命令实时获取TopN商品。某平台采用此方案，支持每秒10万+点击量更新，排行榜查询延迟控制在5ms内。高级数据结构实战（Bitmap/HyperLogLog）

Bitmap：高效布尔值集合Bitmap通过位操作存储大规模布尔值，1000万用户在线状态仅需1.2MB内存。核心命令包括SETBIT（设置位）、GETBIT（获取位）、BITCOUNT（统计置位数量），适用于用户签到、在线状态标记等场景。

HyperLogLog：海量数据基数统计HyperLogLog提供近似去重计数功能，内存占用极低（约12KB），误差率小于1%。通过PFADD添加元素、PFCOUNT获取基数，适用于UV统计、搜索关键词去重等无需精确计数的场景。

Bitmap实战：用户签到系统使用SETBITuser:sign:uid202604011记录用户当日签到，BITCOUNTuser:sign:uid统计月签到天数，实现高效存储与查询，单个用户全年签到数据仅需365位（约46字节）。

HyperLogLog实战：页面UV统计通过PFADDuv:page:homepageuser1user2...记录访问用户，PFCOUNTuv:page:homepage实时获取独立访客数，相比Set存储节省99%内存，支持每日/每周粒度统计。缓存策略与机制02缓存更新策略对比（CacheAside/WriteThrough）01CacheAsidePattern（旁路缓存）读操作：先查缓存，命中直接返回；未命中则查数据库并回写缓存。写操作：先更新数据库，再删除对应缓存项。实现简单，天然避免脏写，适合读多写少场景，如Twitter用户时间线。02WriteThrough（读写穿透）应用仅与缓存交互，缓存层自动同步数据到数据库。读未命中时缓存加载数据，写操作同步更新缓存和数据库。需自研或使用中间件支持，简化应用层逻辑，但可能增加缓存层复杂度。03核心差异与适用场景CacheAside需应用层处理缓存与数据库交互，灵活性高；WriteThrough由缓存层统一管理，一致性更好。读多写少、简单架构首选CacheAside；对一致性要求高、有中间件支持时可采用WriteThrough。缓存淘汰算法原理（LRU/LFU）LRU（最近最少使用）算法LRU算法基于数据最近被访问的时间进行淘汰，核心思想是"如果数据最近被访问过，那么将来被访问的概率也更高"。当缓存空间不足时，优先淘汰最久未被访问的数据。Redis中通过维护一个记录访问顺序的链表实现，新数据插入表头，访问数据移至表头，淘汰表尾数据。LFU（最不经常使用）算法LFU算法基于数据的访问频率进行淘汰，核心思想是"如果数据在最近一段时间内访问次数很少，那么将来被访问的概率也更低"。Redis通过记录每个key的访问次数（计数器）和访问时间戳实现，当缓存空间不足时，优先淘汰访问次数最少的数据；若次数相同，则淘汰最早访问的数据。Redis中的缓存淘汰策略Redis提供多种基于LRU/LFU的缓存淘汰策略，包括volatile-lru（仅淘汰设置过期时间的键中最近最少使用的）、allkeys-lru（从所有键中淘汰最近最少使用的）、volatile-lfu（仅淘汰设置过期时间的键中最不经常使用的）、allkeys-lfu（从所有键中淘汰最不经常使用的）等，可通过maxmemory-policy参数配置。缓存穿透解决方案

缓存空值策略对数据库查询结果为null的key，在Redis中缓存空值并设置短过期时间（如5分钟），避免无效请求反复穿透到数据库。

布隆过滤器拦截通过布隆过滤器预先存储所有有效key，对不存在的key直接拦截。某社交平台使用后拦截99.2%的非法查询，显著降低数据库压力。

接口层参数校验在API网关对请求参数进行合法性校验，例如用户ID格式验证、业务参数范围检查，提前过滤异常请求。缓存击穿与雪崩防御措施缓存击穿的定义与危害缓存击穿指热点Key在过期瞬间，大量并发请求直接访问数据库，可能导致数据库瞬间压力骤增甚至宕机。缓存击穿防御策略采用互斥锁机制，当缓存失效时，只有一个请求能获取锁并查询数据库重建缓存，其他请求等待或返回降级数据；或对热点数据设置"永不过期"，通过后台异步更新保证数据新鲜度。缓存雪崩的定义与诱因缓存雪崩是短时间内大量Key同时过期，导致数据库查询操作激增。主要诱因是为Key设置了统一的过期时间，或Redis集群整体故障。缓存雪崩防御策略为Key添加随机过期时间偏移（如基础时间±300秒）避免集体过期；采用多级缓存架构（本地缓存+Redis）；配置Redis集群实现高可用，同时设置限流、熔断降级机制应对极端情况。缓存预热的定义与价值缓存预热是指在系统启动或新缓存节点上线时，主动将热点数据加载到Redis缓存中的过程。可避免缓存未命中导致的数据库瞬时压力，某电商平台通过预热将系统启动初期数据库负载降低82%。缓存预热的实现方式常用方式包括：基于访问频率统计的定期预热（如每日凌晨执行）、全量数据预加载（适用于静态配置）、分布式任务调度预热（如使用XXL-Job分批次加载）。某支付系统采用分级预热策略，核心交易数据5分钟内完成加载。缓存降级的触发条件当Redis集群负载过高（如CPU使用率>70%）、响应延迟>500ms或出现部分节点故障时，需启动降级策略。某社交平台设置三级降级阈值：警告（QPS下降10%）、限流（拒绝非核心请求）、熔断（临时关闭缓存服务）。降级策略的实施方法包括：返回缓存旧数据（如商品详情页30分钟前快照）、启用本地缓存兜底（Caffeine缓存命中率需达90%以上）、服务熔断（通过Resilience4j设置50%失败率阈值）。某金融系统降级后成功将数据库负载控制在安全阈值内。缓存预热与降级策略Redis分布式部署方案03主从复制架构搭建环境准备与配置文件修改准备至少2台服务器或同一服务器不同端口（如6379为主节点，6380为从节点），修改从节点配置文件：设置slaveof<主节点IP><端口>，开启replica-read-onlyyes，并确保主从节点bind配置允许跨机访问。主从节点启动与连接验证分别启动主从节点，通过redis-cli连接从节点执行inforeplication命令，查看role是否为slave，master_host和master_port是否正确，确认master_link_status为up表示连接成功。数据同步测试与状态监控在主节点执行SETtestkey"hello"，从节点执行GETtestkey验证数据同步；通过主节点inforeplication查看connected_slaves数量，从节点查看master_repl_offset确保数据同步正常，使用redis-cli--stat命令监控复制延迟。哨兵模式配置与故障转移

哨兵配置核心参数主要配置项包括sentinelmonitor（监控主节点）、sentineldown-after-milliseconds（主观下线时间）、sentinelparallel-syncs（故障转移时从节点同步数量）、sentinelfailover-timeout（故障转移超时时间）。

哨兵集群部署步骤1.配置哨兵配置文件（sentinel.conf）；2.启动哨兵进程；3.验证哨兵状态（使用sentinelmaster<master-name>命令）。通常建议部署3个及以上哨兵节点以保证高可用。

故障转移自动流程1.主观下线：哨兵检测到主节点不可达；2.客观下线：多数哨兵同意主节点下线；3.选举领导者哨兵；4.挑选最优从节点升级为主节点；5.其他从节点指向新主节点；6.原主节点恢复后作为从节点加入集群。

实战验证与监控使用redis-cli连接哨兵，执行sentinelfailover<master-name>手动触发故障转移测试。通过sentinelinfo命令监控哨兵状态，确保故障转移平均耗时在10-30秒内。RedisCluster集群部署（3主3从）集群架构设计推荐采用3主3从架构，每个主节点负责部分哈希槽，从节点提供故障转移能力。主节点分摊16384个哈希槽，任意节点故障可自动切换，确保高可用。环境准备要点操作系统推荐Linux内核3.2+（如Ubuntu20.04/CentOS8），每节点至少2GB内存，节点间TCP6379（数据）和16379（集群总线）端口需互通。配置文件核心参数主要配置包括：port（如7001-7006）、cluster-enabledyes、cluster-config-filenodes.conf、cluster-node-timeout15000、appendonlyyes，每个节点需修改端口与目录。集群创建与验证使用命令redis-cli--clustercreate127.0.0.1:7001...127.0.0.1:7006--cluster-replicas1创建集群。通过clusterinfo和clusternodes命令验证集群状态，确保16384个槽全部分配。哈希槽分配与数据分片机制

01哈希槽的概念与数量RedisCluster将整个数据空间划分为16384个哈希槽（hashslots），作为数据分布的基本单位。每个主节点负责管理一部分槽位，实现数据的分布式存储。

02数据分片算法原理每条数据（key）通过CRC16算法计算后对16384取模，得到对应的槽位：slot=CRC16(key)mod16384。通过该算法将数据自动映射到具体的槽位，进而分配到相应的节点。

03典型槽位分配示例以3主3从集群为例，主节点M1管理0~5460槽，M2管理5461~10922槽，M3管理10923~16383槽，实现数据在不同节点的均匀分布。

04客户端路由机制客户端连接集群任意节点后，通过发送CLUSTERSLOTS命令获取槽位分配表并缓存。计算key对应的槽位后，直接向负责该槽位的节点发送请求，实现高效路由。扩容操作流程1.启动新节点：按集群规范配置并启动新的Redis实例；2.加入集群：使用redis-cli--clusteradd-node命令将新节点加入现有集群；3.迁移槽位：通过redis-cli--clusterreshard命令交互式分配哈希槽，实现数据均衡分布。缩容操作流程1.迁移槽位：使用reshard命令将待下线节点的槽位迁移至其他主节点；2.移除节点：执行redis-cli--clusterdel-node命令从集群中删除目标节点；3.验证集群状态：通过clusterinfo和clusternodes确认缩容后集群健康状态。槽位迁移策略采用渐进式迁移方式，单个槽位迁移包含导出、导入、槽位分配三个阶段。可通过--cluster-replace参数实现原子化迁移，避免数据丢失。生产环境建议控制单批次迁移槽位数量（如每次100个），降低对集群性能影响。实战注意事项1.扩容前备份关键数据；2.缩容前确保目标节点槽位已完全迁移；3.迁移过程中监控集群负载，避免在业务高峰期操作；4.使用redis-cli--clustercheck命令验证迁移后数据一致性。集群扩容与缩容实战实战场景应用04分布式锁实现（Redisson）

Redisson分布式锁核心优势Redisson是基于Redis的Java分布式锁框架，提供自动续期（看门狗机制）、可重入锁、公平锁等特性，解决原生Redis锁的死锁、续期难题，简化分布式锁实现复杂度。

基础分布式锁实现代码通过RedissonClient获取RLock对象，调用tryLock方法尝试加锁，支持设置等待时间和自动释放时间，业务执行完毕后调用unlock释放锁，确保分布式环境下的资源互斥访问。

看门狗机制与锁续期Redisson默认开启看门狗机制，当业务未执行完毕且锁即将过期时，自动延长锁有效期（默认30秒续期一次），避免因业务执行时间超过锁过期时间导致的锁提前释放问题。

实战注意事项使用Redisson分布式锁需确保Redis集群高可用，避免单点故障；锁的value需使用唯一标识（如UUID）防止误删；建议结合业务场景合理设置锁超时时间，平衡性能与安全性。购物车功能设计与实现购物车数据结构选型采用RedisHash结构存储购物车，用户ID为key，商品ID为field，商品信息（数量、规格等）为value。相比String类型，Hash支持字段级操作，无需全量读写，更适合对象化存储。核心操作实现方案添加商品：HSETcart:user:1001goods:2001"数量:2,规格:红色"；修改数量：HSETcart:user:1001goods:2001"数量:3,规格:红色"；删除商品：HDELcart:user:1001goods:2001；查询购物车：HGETALLcart:user:1001。实战案例：用户购物车操作某电商平台使用RedisHash实现购物车，支持用户实时添加、修改、删除商品，通过HINCRBY实现商品数量增减，结合EXPIRE设置购物车过期时间，提升用户体验与系统性能。实时排行榜系统构建ZSet数据结构核心优势Redis有序集合(ZSet)通过分数(Score)自动排序，支持毫秒级更新与查询，单键可存储百万级元素，是构建实时排行榜的理想选择。排行榜实现核心命令使用ZADD添加/更新元素分数（如ZADDgame_rank1000"player1"），ZREVRANGE获取TopN排名（如ZREVRANGEgame_rank09WITHSCORES），ZINCRBY实现分数自增。实战场景与性能优化电商商品销量榜：每成交一笔执行ZINCRBY，定时ZREVRANGE生成榜单；游戏天梯榜：结合EXPIRE设置分数有效期，通过ZRANGEBYSCORE实现分段排名查询，单节点支持10万+QPS。接口限流策略（滑动窗口）

滑动窗口限流原理基于时间窗口的流量控制机制，将时间轴划分为多个连续的小窗口，实时统计每个窗口内的请求量，当请求数超过阈值时触发限流。

RedisZSet实现方案使用ZSet存储请求时间戳，Score为时间戳，Member为唯一标识。通过ZREMRANGEBYSCORE清理过期时间戳，ZCOUNT统计窗口内请求数。

核心命令与参数ZADDrequest_record用户ID:接口名时间戳；ZREMRANGEBYSCORErequest_record-inf(当前时间-窗口大小)；ZCOUNTrequest_record(当前时间-窗口大小)+inf。

实战应用场景适用于登录验证码、评论发布、秒杀活动等高频接口，可通过调整窗口大小（如60秒）和阈值（如120次/分钟）控制流量。分布式会话挑战与Redis优势传统单机Session在分布式系统中存在跨节点共享难题，Redis凭借高性能、原子操作和持久化特性，成为分布式会话存储的首选方案，可支持每秒数十万次会话读写。基于Redis的会话存储实现用户登录时生成唯一Token，以Token为Key、用户信息JSON为Value存入Redis，设置合理TTL（如2小时）。每次请求通过拦截器验证Token有效性并自动续期，实现无状态服务架构。实战配置与安全最佳实践使用StringRedisTemplate操作会话数据，结合SETNX命令防止重复登录；敏感信息需加密存储，建议采用SSL传输，某在线教育平台采用该方案后支持200+节点横向扩展，会话管理成本降低65%。分布式会话共享方案性能优化实践05内存优化策略（大Key处理）

大Key的识别与危害大Key指占用内存超过100MB或包含10万+元素的键，会导致内存碎片、网络阻塞和慢查询。可通过redis-cli--bigkeys命令或RedisInsight工具识别。

大Key拆分策略将大Hash拆分为多个小Hash（如按用户ID哈希分片），大List按时间范围拆分，ZSet按分数区间分割，降低单次操作压力。

冷热数据分离存储将低频访问的历史数据迁移至对象存储（如S3），仅缓存热点数据。例如电商订单历史仅保留最近3个月数据在Redis。

批量操作与异步清理使用Pipeline批量操作代替单条命令，采用UNLINK命令异步删除大Key，避免阻塞主线程。案例：某支付系统通过异步清理将删除耗时从500ms降至10ms。持久化配置优化（RDB/AOF）

RDB配置优化策略通过调整save参数设置合理的RDB触发时机，如"save360010"表示1小时内有10次修改触发快照；开启rdbcompressionyes压缩文件，默认使用LZF算法；设置dbfilename和dir参数规范文件存储路径，建议独立磁盘分区存储RDB文件。

AOF配置优化策略appendfsync推荐配置为everysec，平衡数据安全性与性能；开启no-appendfsync-on-rewriteyes避免重写时阻塞主进程；设置auto-aof-rewrite-percentage100和auto-aof-rewrite-min-size64mb控制重写触发条件；启用aof-use-rdb-preambleyes使用混合持久化模式。

持久化性能调优实践通过设置stop-writes-on-bgsave-errorno允许主进程在RDB持久化失败时继续写入；调整aof-rewrite-incremental-fsyncyes减少重写时的磁盘IO压力；生产环境建议RDB与AOF同时启用，RDB用于数据备份，AOF保障数据安全性，混合持久化提升恢复速度。Pipeline与批量操作应用

Pipeline原理与优势Pipeline通过一次性发送多条命令并批量接收响应，减少网络往返次数。相比单条命令执行，可将QPS提升3-5倍，特别适用于批量数据读写场景。

核心批量命令实战MSET/MGET支持一次性设置/获取多个键值对，原子性操作确保数据一致性；HMSET/HMGET可批量处理Hash类型字段，减少50%以上的网络开销。

应用场景与最佳实践适用于用户信息批量加载、商品库存批量更新等场景。建议单次Pipeline命令数控制在100-500条，避免过大批量导致阻塞；结合事务保证操作原子性。连接池参数调优

最大连接数（max-active）设置连接池可创建的最大连接数，建议根据业务并发量和Redis服务器承载能力调整，一般设为50-200。例如，SpringBoot中可通过spring.redis.lettuce.pool.max-active配置，避免连接数过多导致Redis性能下降。

最大空闲连接数（max-idle）设置连接池允许保持空闲状态的最大连接数，通常建议与max-active保持一致或略低，确保有足够的空闲连接应对突发请求，减少连接创建开销。

最小空闲连接数（min-idle）设置连接池必须保持的最小空闲连接数，建议设为5-10，避免频繁创建和销毁连接，尤其适用于访问量波动较大的场景，提升系统响应速度。

连接等待超时时间（max-wait）设置获取连接的最大等待时间，单位毫秒，建议设为1000-3000ms。超过该时间未获取到连接将抛出异常，防止线程长时间阻塞，保障系统稳定性。核心监控指标包括内存使用率（建议阈值<85%）、命中率（目标>90%）、QPS（根据业务峰值设定基线）、连接数（不超过maxclients配置）、主从复制延迟（建议<1秒）等关键指标。性能指标监控关注命令耗时分布（如P99延迟应<1ms）、内存碎片率（理想值1.0-1.5）、持久化操作（AOF重写/RDB生成频率及耗时），可通过INFOstats和INFOmemory命令获取。告警规则配置设置多级告警阈值：内存使用率>85%触发预警，>95%紧急告警；命中率<80%告警；主从复制延迟>3秒告警；命令失败率>1%立即告警。监控工具推荐官方工具RedisInsight提供可视化监控；Prometheus+Grafana适合构建全面监控面板；ELKstack可用于日志分析；redis-cli--bigkeys用于大Key检测。监控指标与告警体系实战操作演示06RedisCluster环境搭建步骤环境准备与依赖检查操作系统推荐Linux内核3.2+（如Ubuntu20.04/CentOS8），每节点至少2GBRAM，确保节点间TCP6379（数据）和16379（集群总线）端口互通。需安装GCC、make等编译工具。节点配置文件创建为每个节点创建独立配置文件，核心配置包括：port（如7001-7006）、cluster-enabledyes、cluster-config-filenodes.conf、cluster-node-timeout15000、appendonlyyes、daemonizeyes。启动集群节点通过redis-server命令依次启动所有节点实例，例如：redis-server/usr/local/redis-cluster/7001/redis.conf。可通过ps-ef|grepredis命令检查进程是否正常启动。创建Redis集群使用redis-cli--clustercreate命令创建集群，指定节点地址并设置副本数，如：redis-cli--clustercreate127.0.0.1:7001...127.0.0.1:7006--cluster-replicas1。确认槽位分配完成提示"All16384slotscovered"。集群状态验证通过redis-cli-c-p7001连接任意节点，执行clusterinfo查看集群状态（cluster_state:ok），clusternodes查看节点角色与槽位分配，测试数据读写验证自动路由功能。缓存策略代码实现演示CacheAsidePattern实现publicUsergetUser(Longid){Stringkey="user:"+id;Useruser=redis.get(key);if(user!=null)returnuser;user=db.queryUser(id);if(user!=null)redis.setex(key,3600,user);returnuser;}缓存穿透防御代码//空值缓存示例redis.setex("user:9999",60,"null");//布隆过滤器前置拦截if(!bloomFilter.mightContain(merchantId)){returnnull;}热点Key互斥锁实现try(RLocklock=redissonClient.getLock("lock:order:"+orderId)){if(lock.tryLock(3,10,TimeUnit.SECONDS)){//双重检查后重建缓存redis.setex(key,3600,value);}}多级缓存实现//本地缓存+Redis双层架构Objectconfig=localCache.get(merchantId);if(config==null){config=redisClient.get(key);if(config!=null)localCache.put(merchantId,config,5,TimeUnit.MINUTES);}关键性能指标监控核心监控指标包括：内存使用率（建议阈值<85%）、缓存命中率（目标>90%）、QPS（每秒查询数）、平均响应时间（目标<1ms）、连接数及主从复制延迟。可通过redis-cliinfomemory/stats命令获取实时数据。性能测试工具与方法推荐使用redis-benchmark进行基准测试，例如执行"redis-benchmark-tset,get-n100000-q"测试SET/GE