Memcached vs. Redis不同key大小性能测试报告_v1.0_20130123_廖诚

一、Memcached1.1、memcached简介Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web 应用以减轻数据库负载。

它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。

Memcached基于一个存储键/值对的hashmap。

其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。

但是它并不提供冗余（例如，复制其hashmap条目）；当某个服务器S停止运行或崩溃了，所有存放在S上的键/值对都将丢失。

Memcached由Danga Interactive开发，其最新版本发布于2010年，作者为Anatoly Vorobey和Brad Fitzpatrick。

用于提升LiveJournal . com访问速度的。

LJ每秒动态页面访问量几千次，用户700万。

Memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。

1.2、Memcached是如何工作的Memcached的神奇来自两阶段哈希（two-stage hash）。

Memcached就像一个巨大的、存储了很多<key,value>对的哈希表。

通过key，可以存储或查询任意的数据。

客户端可以把数据存储在多台memcached上。

当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈希），进而选中一个节点；客户端将请求发送给选中的节点，然后memcached节点通过一个内部的哈希算法（阶段二哈希），查找真正的数据（item）。

举个列子，假设有3个客户端1, 2, 3，3台memcached A, B, C：Client 1想把数据”tuletech”以key “foo”存储。

Client 1首先参考节点列表（A, B, C），计算key “foo”的哈希值，假设memcached B被选中。

Memcached与Redis对⽐及其优劣分析国外讨论本⽂主要总结缓存Redis和Memcached的区别,总结之前先参考外国知乎上的⼀篇问答:《》,为了⽅便今后查阅,将部分语句翻译记录⼀下:You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.没有必要过多的关⼼性能，因为⼆者的性能都已经⾜够⾼了。

由于Redis只使⽤单核，⽽Memcached可以使⽤多核，所以在⽐较上，平均每⼀个核上Redis在存储⼩数据时⽐Memcached性能更⾼。

⽽在100k以上的数据中，Memcached性能要⾼于Redis，虽然Redis最近也在存储⼤数据的性能上进⾏优化，但是⽐起Memcached，还是稍有逊⾊。

说了这么多，结论是，⽆论你使⽤哪⼀个，每秒处理请求的次数都不会成为瓶颈。

浅谈Redis的key和value⼤⼩限制今天研究了下将java bean序列化到redis中存储起来，突然脑袋灵光⼀闪，对象⼤⼩会不会超过redis限制？不管怎么着，还是搞清楚⼀下⽐较好，所以就去问了下百度，果然没多少⼈关⼼这个问题，没找到⽐较合适的答案，所以决定还是去官⽹找吧。

找到两句⽐较关键的话，截图如下。

结论redis的key和string类型value限制均为512MB。

补充知识：Redis获取所有键值通过遍历获取⽬标键值：import redisredis = redis.Redis(host='192.24.210.2', port='6666', password='',db=0)keys = redis.keys()for key in keys:t = str(key)print(t)# print(key)if t == "b'proxies'":type = redis.type(key)if type == b'string':vals = redis.get(key)elif type == b'list':vals = redis.lrange(key, 0, -1)# print(vals)elif type == b'set':vals = redis.smembers(key);elif type == b'zset':vals = redis.zrange(key, 0, -1)elif type == b"hash":vals = redis.hgetall(key)else:print(type, key)print(vals)以上这篇浅谈Redis的key和value⼤⼩限制就是⼩编分享给⼤家的全部内容了，希望能给⼤家⼀个参考，也希望⼤家多多⽀持。

Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析一、问题：数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。

二、解决方案：1.通过高速服务器Cache缓存数据库数据2.内存数据库（这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop HBase Hive等分布式存储分析平台）三、主流解Cache和数据库对比：上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。

而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。

从以上各数据可知，对于我们产品最可行的技术方案有两种：1.Memcached 内存Key-Value Cache2.Redis 内存数据库四、下面重点分析Memcached和Redis两种方案：4.1 Memcached介绍Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。

它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook、Vox、LiveJournal等公司所使用。

4.2 Memcached工作方式分析许多Web应用都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。

但随着数据量的增大、访问的集中，就会出现RDBMS的负担加重、数据库响应恶化、网站显示延迟等重大影响。

Memcached是高性能的分布式内存缓存服务器,通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web等应用的速度、提高可扩展性。

在Redis中，没有明确的标准来定义什么是大Key。

然而，一般来说，如果一个Key包含的数据量过大，导致操作该Key时需要消耗大量的内存和计算资源，那么这个Key就可以被认为是大Key。

以下是一些常见的特征和考虑因素，可以帮助你判断一个Key是否过大：
1. 键名长度：过长的键名可能会消耗较多的内存，特别是在大量键的情况下。

一般来说，如果键名长度超过几十个字符，就可以认为可能存在较大的开销。

2. 数据结构：使用复杂的数据结构（如列表、集合、哈希等）可能会增加内存消耗。

特别是当这些数据结构中的元素数量过多时，会导致内存占用增加。

3. 数据大小：存储在Key中的数据量过大，特别是字符串类型的数据，会占用大量的内存。

如果单个字符串值的大小超过几十个MB，就可以认为可能存在较大的开销。

4. 访问频率：如果对某个大Key进行频繁的读或写操作，会导致CPU和网络带宽的负载增加。

这种情况下，可以考虑对数据进行分片或使用更高效的数据结构来优化性能。

5. 监控和分析：通过监控Redis的性能指标和分析操作日志，可以发现哪些Key可能存在性能问题。

例如，监控内存使用情况、CPU 负载、网络带宽等指标，可以帮助你识别潜在的大Key。

总之，对于Redis中的大Key，需要根据实际情况进行判断。

如果发现某个Key可能过大，应该采取适当的措施来优化数据结构和减少内存消耗，以确保Redis的性能和稳定性。

Redis与Memcached的区别传统MySQL+ Memcached架构遇到的问题实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：1.MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。

2.Memcached与MySQL数据库数据一致性问题。

3.Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。

4.跨机房cache同步问题。

众多NoSQL百花齐放，如何选择最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题1.少量数据存储，高速读写访问。

此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。

2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。

3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。

前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。

4.Schema free，auto-sharding等。

比如目前常见的一些文档数据库都是支持schema-free 的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。

分析rediskey⼤⼩的⼏种⽅法当redis被⽤作缓存时，有时我们希望了解key的⼤⼩分布，或者想知道哪些key占的空间⽐较⼤。

本⽂提供了⼏种⽅法。

⼀. bigKeys这是redis-cli⾃带的⼀个命令。

对整个redis进⾏扫描，寻找较⼤的key。

例：redis-cli -h b.redis -p 1959 --bigkeys输出：# Scanning the entire keyspace to find biggest keys as well as# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec# per 100 SCAN commands (not usually needed).[00.00%] Biggest hash found so far 's_9329222' with 3 fields[00.00%] Biggest string found so far 'url_/mobile/170722090206890.html?qid=sgllq&ch=east_sogou_push&pushid=13' with 8 bytes[00.00%] Biggest string found so far 'foo' with 40 bytes[00.00%] Biggest hash found so far 's_9329084' with 4 fields[00.23%] Biggest zset found so far 'region_hot_菏泽地' with 625 members[00.23%] Biggest zset found so far 'region_hot_葫芦岛' with 914 members[00.47%] Biggest string found so far 'top_notice_list' with 135193 bytes[00.73%] Biggest zset found so far 'region_hot_⾃贡' with 2092 members[01.90%] Biggest hash found so far 'uno_facet_2018-12-20' with 59 fields[11.87%] Biggest zset found so far 'region_hot_上海' with 2233 members[27.05%] Biggest set found so far 'blacklist_set_key' with 31832 members[73.87%] Biggest string found so far 'PUSH_NEWS' with 3104237 bytes[86.18%] Biggest zset found so far 'region_hot_北京' with 2688 members-------- summary -------Sampled 4263 keys in the keyspace!Total key length in bytes is 174847 (avg len 41.02)Biggest string found 'PUSH_NEWS' has 3104237 bytesBiggest set found 'blacklist_set_key' has 31832 membersBiggest hash found 'uno_facet_2018-12-20' has 59 fieldsBiggest zset found 'region_hot_北京' has 2688 members1616 strings with 3771161 bytes (37.91% of keys, avg size 2333.64)0 lists with 0 items (00.00% of keys, avg size 0.00)1 sets with 31832 members (00.02% of keys, avg size 31832.00)2353 hashs with 7792 fields (55.20% of keys, avg size 3.31)293 zsets with 333670 members (06.87% of keys, avg size 1138.81)说明：1. 该命令使⽤scan⽅式对key进⾏统计，所以使⽤时⽆需担⼼对redis造成阻塞。

redis与mysql性能对⽐、redis缓存穿透、缓存雪崩
写在开始
redis是⼀个基于内存hash结构的缓存型db。

其优势在于速读写能⼒碾压mysql。

由于其为基于内存的db所以存储数据量是受限的。

redis性能
redis读写性能测试redis官⽹测试读写能到10万左右
redis读写能⼒为2W/s
mysql读能⼒5K/s、写能⼒为3K/s
数据上看redis性能碾压mysql
redis缓存穿透
缓存穿透是指查询⼀个⼀定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写⼊缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

在流量⼤时，可能DB就挂了。

　解决办法就是将从db过来的返回值进⾏缓存，根据实际情况重新加热，若db返回是空则缓存⼏分钟就可以了。

redis缓存雪崩
在我们设置缓存时采⽤了相同的过期时间或者缓存服务器因某些原因⽆法使⽤时，导致缓存在某⼀时刻同时失效，请求全部转发到DB，DB 瞬时压⼒过重雪崩。

　解决办法过期时间上增加⼀个范围的随机值，使⽤Redis Sentinel 和 Redis Cluster 实现⾼可⽤，另增设⼀个寿命更短的本机缓存来解决redis分布缓存抢修时的问题。

　在发⽣⽆论是缓存穿透还是缓存雪崩，都建议使⽤队列来排队、拒绝⼤量请求涌⼊和分布式互斥锁来避免后端数据服务被冲击，防⽌已有的数据出现问题。

redis和memcached的区别和使⽤场景Redis 和 Memcached 都是基于内存的数据存储系统。

Memcached是⾼性能分布式内存缓存服务，其本质上就是⼀个内存key-value数据库。

Redis是⼀个开源的key-value存储系统。

与Memcached类似，Redis将⼤部分数据存储在内存中，⽀持的数据类型包括：字符串、哈希表、链表、集合、有序集合以及基于这些数据类型的相关操作。

区别1、Redis和Memcache都是将数据存放在内存中，都是内存数据库。

不过memcache还可⽤于缓存其他东西，例如图⽚、视频等等；2、Redis不仅仅⽀持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储；3、虚拟内存–Redis当物理内存⽤完时，可以将⼀些很久没⽤到的value 交换到磁盘；4、过期策略–memcache在set时就指定，例如set key1 0 0 8,即永不过期。

Redis可以通过例如expire 设定，例如expire name 10；5、分布式–设定memcache集群，利⽤magent做⼀主多从;redis可以做⼀主多从。

都可以⼀主⼀从；6、存储数据安全–memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）；7、灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；8、Redis⽀持数据的备份，即master-slave模式的数据备份；9、应⽤场景不⼀样：Redis出来作为NoSQL数据库使⽤外，还能⽤做消息队列、数据堆栈和数据缓存等；Memcached适合于缓存SQL语句、数据集、⽤户临时性数据、延迟查询数据和session等。

使⽤场景1、如果有持久⽅⾯的需求或对数据类型和处理有要求的应该选择redis。

2、如果简单的key/value 存储应该选择memcached。

参考：。

redis和mongodb各⾃的优缺点，怎么选择？redis和mongodb各⾃的优缺点，怎么选择？RedisRedis是神马？Redis是⼀个开源的使⽤ANSI C语⾔编写、⽀持⽹络、可基于内存亦可持久化的⽇志型、Key-Value⾮关系型数据库，并提供多种语⾔的API。

redis是⼀个key-value存储系统。

Redis是⾮关系型数据库的⼀种，经常⽤作缓存。

和Memcached类似，它⽀持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。

这些数据类型都⽀持push/pop、add/remove及取交集并集和差集及更丰富的操作，⽽且这些操作都是原⼦性的。

在此基础上，redis⽀持各种不同⽅式的排序。

与memcached⼀样，为了保证效率，数据都是缓存在内存中。

区别的是redis会周期性的把更新的数据写⼊磁盘或者把修改操作写⼊追加的记录⽂件，并且在此基础上实现了master-slave(主从)同步。

Redis有以下的优点：⽀持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算）⽀持持久化操作，可以进⾏aof及rdb数据持久化到磁盘，从⽽进⾏数据备份或数据恢复等操作，较好的防⽌数据丢失的⼿段。

⽀持通过Replication进⾏数据复制，通过master-slave机制，可以实时进⾏数据的同步复制，⽀持多级复制和增量复制，master-slave机制是Redis进⾏HA的重要⼿段。

单线程请求，所有命令串⾏执⾏，并发情况下不需要考虑数据⼀致性问题。

⽀持pub/sub消息订阅机制，可以⽤来进⾏消息订阅与通知。

⽀持简单的事务需求，但业界使⽤场景很少，并不成熟。

Redis的缺点：Redis只能使⽤单线程，性能受限于CPU性能，故单实例CPU最⾼才可能达到5-6wQPS每秒（取决于数据结构，数据⼤⼩以及服务器硬件性能，⽇常环境中QPS⾼峰⼤约在1-2w左右）。

Redis缓存的性能测试Redis缓存是一种常见的缓存技术，它通过将数据存储在内存中，以提高系统的性能和响应速度。

然而，对于使用Redis缓存的应用程序来说，了解和评估其性能是非常重要的。

本文将介绍Redis缓存的性能测试方法和相关指标，以帮助读者更好地理解和使用Redis缓存。

一、性能测试的意义及流程性能测试是评估和验证系统性能的关键过程。

对于Redis缓存来说，性能测试可以帮助我们了解Redis在不同负载下的表现，检测潜在的性能瓶颈，并进行性能调优。

在进行性能测试之前，我们首先需要明确测试目标和测试场景，然后按照以下流程进行：1. 确定测试环境：包括硬件环境、操作系统、网络环境等。

准备好Redis服务器和客户端。

2. 设计测试场景：根据实际应用场景和负载特点，设计不同的测试用例。

例如，可以模拟并发读写操作、大数据量写入等。

3. 配置测试参数：设置Redis的配置参数，如缓存大小、连接数等。

设置客户端的并发数、请求频率等。

4. 执行性能测试：启动Redis服务器和客户端，并进行性能测试。

记录测试指标，如响应时间、吞吐量、并发数等。

5. 分析测试结果：通过对测试结果的分析和比较，找出潜在的性能问题，并进行性能调优。

二、性能测试指标在进行Redis缓存性能测试时，我们通常关注以下指标：1. 响应时间：指从请求发出到收到响应所需的时间。

较短的响应时间通常表示更好的性能。

2. 吞吐量：指系统单位时间内能够处理的请求数量。

高吞吐量表示系统能够处理更多的请求。

3. 并发数：指系统同时处理的请求数量。

较高的并发数表示系统具有更好的并发能力。

4. 内存占用：指Redis服务器使用的内存大小。

较低的内存占用可以节约成本，并提高性能。

5. CPU利用率：指Redis服务器使用的CPU资源比例。

较低的CPU利用率表示系统具有更好的性能。

三、性能测试工具在进行Redis缓存性能测试时，我们可以使用一些专门的性能测试工具，如：1. Redis-benchmark：是Redis官方提供的性能测试工具，可以模拟多个并发客户端对Redis服务器进行读写操作，并且提供了丰富的参数配置选项。

内存缓存服务器技术调研报告系列客户端性能比较分析报告2011年4月21日目录前言 (2)测试方案 (2)测试结果 (3)结论 (5)图目录图表1 简单对象查询Key对应Value（get操作）对比图 (3)图表2 简单对象设置Key-Value(set操作)对比图 (4)图表3 复杂对象查询Key对应Value(get操作)对比图 (5)图表4复杂对象设置Key-Value(set操作)对比图 (5)前言目前几乎所有主流的互联网站都引入内存对象缓存系统（key-value）来对常用对象进行内存缓存，目前应用最广泛的就是memcached开源软件。

关于Memcached的介绍可以参考下面百科的内容：Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。

它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。

Memcached基于一个存储键/值对的hashmap。

其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。

借助memcached作为缓存，可以实现更为灵活“云”化的分布式系统，而抛弃掉传统以JGroups为代表的底层消息通信为基础的集群架构。

预期在Portal个性化架构调整中引用这种架构来探索新的分布式系统。

Memcached主流的Java客户端中，目前流行的主要是Spymemcached和Xmemcached 两种。

为了验证memcached的使用、开发和性能，以及对客户端进行选型，特进行性能对比测试。

测试方案选择自己编写的Java方法并发测试框架，分别测试简单对象、复杂对象两种对象的保存和读取两种操作，采用集合点的模式分别验证单线程、100、200、500、1000、2000、3000、5000并发。

其中：简单对象的Key和Value均为当前时间的毫秒数；复杂对象的Key为当前时间的毫秒数、Value为Portal中用户对象的属性值映射出来的HashMap。

memcache和redis缓存对比及我为什么选择redis对比结论1. 性能上：性能上都很出色，具体到细节，由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。

而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起 Memcached，还是稍有逊色。

2. 内存空间和数据量大小：MemCached可以修改最大内存，采用LRU算法。

Redis增加了VM的特性，突破了物理内存的限制。

Memcached单个key-value大小有限，一个value最大只支持1MB，而Redis最大支持512MB。

3. 操作便利上：MemCached数据结构单一，仅用来缓存数据，而Redis支持更加丰富的数据类型，也可以在服务器端直接对数据进行丰富的操作,这样可以减少网络IO次数和数据体积。

4. 可靠性上：MemCached不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的。

Redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价。

5. 存储数据类别上的区别：redis支持很存储表：key-value、hash表、list表等memcache只支持key-value，不过memcache可以在内存中缓存图片、视频等。

6. 应用场景：Memcached：动态系统中减轻数据库负载，提升性能；做缓存，适合多读少写，大数据量的情况。

Redis：适用于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统。

我为什么选择redis其实redis也支持cas，而且最新的redis支持分布式集群，即使100k以上的流量性能不及memcache高，但是我自己的网站没有那么高的并发量啊，O(∩_∩)O哈哈~上个博客测试我sso登录的并发量2000反应3s，所以达不到那么高的并发，其次个人的服务器也存在不稳定情况，docker没有配置k8s管理，容易出现进程失效问题，所以redis还能很好的保护我的数据，故，我选择redis，欢迎大神指教也希望能结交大神，能带着我学习。

Redis如何查看指定key的⼤⼩（即所占内存空间⼤⼩）⽅式⼀：利⽤rdbtools⼯具的redis-memory-for-key命令即可查看的单个key的详细信息安装该⼯具需要有python的pip包管理，所以先安装环境:1、安装gcc[root soft]# yum install gcc上次元数据过期检查：2:22:05 前，执⾏于 2021年08⽉10⽇星期⼆ 07时00分30秒。

软件包 gcc-8.3.1-5.1.el8.x86_64 已安装。

依赖关系解决。

================================================================================================================软件包架构版本仓库⼤⼩================================================================================================================升级:cpp x86_64 8.4.1-1.el8 AppStream 10 Mgcc x86_64 8.4.1-1.el8 AppStream 23 Mlibgcc x86_64 8.4.1-1.el8 BaseOS 78 klibgomp x86_64 8.4.1-1.el8 BaseOS 204 k事务概要================================================================================================================升级 4 软件包总下载：34 M确定吗？[y/N]： y下载软件包：(1/4): libgcc-8.4.1-1.el8.x86_64.rpm 9.3 MB/s | 78 kB 00:00(2/4): libgomp-8.4.1-1.el8.x86_64.rpm 18 MB/s | 204 kB 00:00(3/4): cpp-8.4.1-1.el8.x86_64.rpm 71 MB/s | 10 MB 00:00(4/4): gcc-8.4.1-1.el8.x86_64.rpm 86 MB/s | 23 MB 00:00----------------------------------------------------------------------------------------------------------------总计 124 MB/s | 34 MB 00:00已升级:cpp-8.4.1-1.el8.x86_64 gcc-8.4.1-1.el8.x86_64 libgcc-8.4.1-1.el8.x86_64 libgomp-8.4.1-1.el8.x86_64完毕！2、安装epel-release[root soft]# yum -y install epel-release上次元数据过期检查：2:22:21 前，执⾏于 2021年08⽉10⽇星期⼆ 07时00分30秒。

在Redis 中，"大key" 通常指的是占用大量内存或存储大量数据的键（key）。

判断一个键是否为"大key" 取决于多个因素，主要是以下几个标准：1. **内存占用**：一个键的内存占用是判断其是否为大key的一个关键因素。

如果一个键存储的数据量非常大，导致Redis 实例的内存使用量急剧增加，那么它可能被认为是一个大key。

你可以使用Redis 的`MEMORY USAGE` 命令来查看键的内存使用情况。

2. **数据类型**：某些Redis 数据类型，如Hash 和List，更容易成为大key，因为它们可以包含大量的数据。

如果一个Hash 或List 的成员数量或元素数量非常大，那么它可能会被认为是大key。

3. **持续时间**：如果一个键在Redis 中存在的时间很长，且存储的数据在不断增长，那么它也可能成为大key。

长期存在的大key可能导致Redis 内存用量不断增加。

4. **数据访问频率**：如果一个键被频繁访问，但它的数据量很大，那么它可能对Redis 的性能产生负面影响。

这也可以被视为一个大key的标准。

为了识别和处理大key，可以考虑以下方法：- 使用Redis 的各种命令和工具，如`MEMORY USAGE`、`SCAN` 和`KEYS`，来检查键的内存占用和数据量。

- 定期监控Redis 实例的内存使用情况，以及键的增长趋势。

- 考虑使用Redis 的过期时间（TTL）来限制键的持续时间，以及定期清除不再需要的大key。

- 对于特别大的键，可以考虑拆分数据到多个键中，以减小每个键的大小。

总之，判断一个键是否为大key需要考虑多个因素，包括内存占用、数据类型、持续时间和访问频率等。

在运维Redis 实例时，定期监控和维护是管理大key的重要方法。

memcache、redis、tair性能对比测试报告第1章限制条件前一周所做的分布缓存技术预言中有包括ehcache、memcache、redis、tair，还包括了基于MongoDB的分布式技术。

测试中，考虑到各自功能的差异化特点，其中选择了memcache、redis、tair功能特性相近的缓存服务器进行性能对比，所以ehcache、MongoDB将不做为本次测试的规范，其原因如下：1）Ehcache是组件级别的缓存，要搭建一个独立的缓存服务器，需要用到ehcache server 模块，这是个war包，能运行在web 容器中，决定整个缓存服务器性能的好坏因素太多，比如web服务器，集群方式等。

跟memcache、redis、tair没有对比性。

2）MongoDB是面向文档的数据库，跟缓存没有可比性。

第2章测试场景概述性能测试包括单机环境和分布式环境，主要针对memcache、redis、tair各缓存服务器在缓存了不同级别的数据下,多个线程并发操作向缓存set/get缓存数据，考虑到网络方面的负载，又将每次set/get操作的缓存数据的大小分为三个不同的级别：1KB,10KB,100KB,通过对上述的条件进行排列，取得以下的测试场景。

第3章单机环境测试3.1.测试场景：1.当各缓存的数据库空时，以单线程通过各缓存客户端set调用向服务端推送数据，比较10000操作所消耗的时间，以上动作通过使用不同大小的单个缓存对象重复三次。

2.在场景一完成的情况下，以单线程通过各缓存客户端get调用向服务端获取数据，比较10000操作所消耗的时间，以上动作通过使用不同大小的单个缓存对象重复三次。

3.并发200个线程通过缓存软件的客户set调用向服务端推送数据，每个线程完成10000次的操作，比较服务器的tps大小，以上动作通过使用不同大小的单个缓存对象重复三次。

4.并发200个线程通过缓存软件的客户get调用向服务端获取数据，每个线程完成10000次的操作，比较服务器的tps大小，以上动作通过使用不同的key取不同大小的数据，重复三次。

关于redis的keys命令的性能问题查找所有符合给定模式 pattern 的 key 。

KEYS * 匹配数据库中所有 key 。

KEYS h?llo 匹配 hello ， hallo 和 hxllo 等。

KEYS h*llo 匹配 hllo 和 heeeeello 等。

KEYS h[ae]llo 匹配 hello 和 hallo ，但不匹配 hillo实际应⽤中有时候会出现需要遍历redis中的所有键值的需求，⽐如清理没⽤的键等等。

但是keys这个命令性能真的很差，redis官⽅⽂档是这么说的：Warning: consider KEYS as a command that should only be used in production environments with extreme care.It may ruin performance when it is executed against large databases.This command is intended for debugging and special operations, such as changing your keyspace layout.Don’t use KEYS in your regular application code. If you’re looking for a way to find keys in a subset of your keyspace,consider using SCAN or sets.Keys模糊匹配，请⼤家在实际运⽤的时候忽略掉。

因为Keys会引发Redis锁，并且增加Redis的CPU占⽤，情况是很恶劣的，实际应⽤中有时候会出现需要遍历redis中的所有键值的需求，⽐如清理没⽤的键等等。

但是keys这个命令性能真的很差。

上⾯是官⽅⽂档声明，KEYS命令不能⽤在⽣产的环境中，这个时候如果数量过⼤效率是⼗分低的。

redis 压测指标在使用Redis 进行性能测试（压测）时，有一些关键的指标和性能参数需要关注。

这些指标可以帮助你评估Redis 的性能，并确保它满足你的应用程序需求。

以下是一些常见的Redis 压测指标：1. 吞吐量（Throughput）：衡量Redis 服务器在单位时间内能够处理的请求数量。

通过检查每秒执行的操作数（如GET、SET 等）来评估。

2. 响应时间（Response Time）：衡量执行单个操作所需的时间。

低延迟通常是关键的性能指标。

3. 连接数（Connections）：监测并发连接的数量。

理解系统的最大连接数限制是很重要的。

4. 带宽利用率（Bandwidth Utilization）：监测网络带宽的使用情况，特别是在大量数据传输的情况下。

5. CPU 使用率（CPU Utilization）：检查Redis 服务器的CPU 使用率，确保系统能够有效地利用计算资源。

6. 内存使用率（Memory Utilization）：跟踪Redis 实例使用的内存量，以确保不会因为内存不足而导致性能问题。

7. 命中率（Cache Hit Ratio）：对于读取密集型操作，关注缓存的命中率，以评估缓存效果。

8. 并发性能（Concurrency）：测试系统在并发负载下的性能表现。

这包括并发连接和并发请求。

9. 持久性性能（Persistence Performance）：如果你在Redis 中启用了持久性选项（如RDB 快照或AOF 日志），确保检查持久性操作的性能。

10. 错误率（Error Rate）：监控Redis 执行操作时发生的错误的频率。

进行Redis 压测时，你可以使用一些工具来生成负载并收集这些指标，例如：-redis-benchmark：这是Redis 官方提供的基准测试工具。

它可以用于模拟并发请求，并提供有关Redis 性能的详细报告。

- memtier_benchmark：一个用于Redis 和Memcached 的基准测试工具，支持更复杂的负载模式。

redis和memcached选择，对⽐分析memcache和redis是互联⽹分层架构中，最常⽤的KV缓存。

不少同学在选型的时候会纠结，到底是选择memcache还是redis？memcache提供的功能是redis提供的功能的⼦集，不⽤想太多，选redis准没错？redis倾向：复杂的数据结构：value是哈希，列表，集合，有序集合这类复杂的数据结构时，会选择redis，因为mc⽆法满⾜这些需求。

⽤户订单列表，⽤户消息，帖⼦评论列表等。

持久化： mc⽆法满⾜持久化的需求，只得选择redis。

但是千万不要把redis真的做数据库⽤a. redis的定期快照不能保证数据不丢失b.redis的AOF会降低效率，并且不能⽀持太⼤的数据量c.不要期望redis做固化存储会⽐mysql做得好，不同的⼯具做各⾃擅长的事情d.redis挂掉重启后能够快速恢复热数据，但是如果着期间有数据修改，可能导致数据不⼀致，因此，只读场景，或者允许⼀些不⼀致的业务场景，可以尝试开启redis的固化功能⾃带⾼可⽤集群： redis⾃⾝⽀持集群，实现主从读写分离功能，官⽅也提供sentinal哨兵的集群管理⼯具，实现主从监控，故障转移，memcached实现集群需要⼆次开发了但是很多时候需要考虑，真的需要⾼可⽤么？缓存很多时候是运⾏cache miss的，cache挂了可以读db的存储的内容⽐较⼤： macache 单个value最⼤存储 1M，超过1M只能⽤redis了。

注意：纯的k-v ⽽且数据量特别⼤，并发也很⼤或许使⽤memcache更合适a.内存分配：memcache使⽤预分配内存池的烦事管理内存，更节省内存分配时间，redis使⽤临时申请的⽅式，kennel导致碎⽚。

对⽐看memcache更快⼀点b.memcache把所有的数据存储在物理内存⾥。

redis有⾃⼰的VM机制，理论上能够存储⽐物理内存更多的数据，当数据超量时，会引发swap，把冷数据刷到磁盘上。