Ehcache-Redis-Tair缓存性能对比
8种缓存框架介绍
8种缓存框架介绍缓存框架是一种用于存储和管理缓存数据的软件工具或库。
它们用于提高应用程序的性能，减少数据库或其他远程资源的访问次数。
在本文中，我们将介绍8种流行的缓存框架，包括Redis、Memcached、Ehcache、Guava Cache、Caffeine、Hazelcast、Infinispan和Apache Geode。
1. Redis： Redis是一个基于内存的缓存框架，提供了丰富的数据结构和灵活的功能，包括缓存、消息队列和数据持久化。
Redis的性能出色，并且具有高可用性和扩展性。
2. Memcached： Memcached是另一个流行的基于内存的缓存框架，广泛用于提高Web应用程序的性能。
它具有简单的架构和易于使用的API。
Memcached可以在多台服务器上进行水平扩展，以提供更高的负载能力。
3. Ehcache： Ehcache是一个Java缓存框架，可以用于将缓存添加到应用程序中。
它具有简单易用的API，并提供了多种缓存策略，如LRU （最近最少使用）和FIFO（先进先出）。
Ehcache还支持磁盘持久化和分布式缓存。
4. Guava Cache： Guava Cache是Google开发的一个轻量级缓存库，可以在本地JVM中实现缓存功能。
它具有内存敏感的淘汰策略和异步加载机制，可以优化资源利用和应用程序响应时间。
5. Caffeine： Caffeine是另一个基于本地内存的缓存库，由Google开发。
它被设计为高性能、无锁的缓存框架，并且具有比Guava Cache更高的吞吐量和更低的延迟。
6. Hazelcast： Hazelcast是一个分布式缓存框架和数据网格，可以在多个服务器上共享缓存数据。
它提供了分布式数据结构和分布式计算功能，并支持高可用性和容错性。
7. Infinispan： Infinispan是另一个开源的分布式缓存框架，用于构建高性能和高可靠性的应用程序。
ehcache、memcache、redis三大缓存比较
ehcache、memcache、redis三⼤缓存⽐较最近项⽬组有⽤到这三个缓存，去各⾃的官⽅看了下,觉得还真的各有千秋！今天特意归纳下各个缓存的优缺点，仅供参考！Ehcache在项⽬⼴泛的使⽤。
它是⼀个开源的、设计于提⾼在数据从RDBMS中取出来的⾼花费、⾼延迟采取的⼀种缓存⽅案。
正因为Ehcache具有健壮性（基于java开发）、被认证（具有apache 2.0license）、充满特⾊（稍后会详细介绍），所以被⽤于⼤型复杂分布式web application的各个节点中。
什么特⾊？1. 够快Ehcache的发⾏有⼀段时长了，经过⼏年的努⼒和不计其数的性能，Ehcache终被设计于large, high concurrency systems.2. 够简单开发者提供的接⼝⾮常简单明了，从Ehcache的搭建到运⽤运⾏仅仅需要的是你宝贵的⼏分钟。
其实很多开发者都不知道⾃⼰⽤在⽤Ehcache，Ehcache被⼴泛的运⽤于其他的开源项⽬⽐如：3.够袖珍关于这点的特性，官⽅给了⼀个很可爱的名字small foot print ，⼀般Ehcache的发布版本不会到2M，V 2.2.3 才 668KB。
4. 够轻量核⼼程序仅仅依赖slf4j这⼀个包，没有之⼀！5.好扩展Ehcache提供了对的内存和硬盘的存储，最近版本允许多实例、保存对象⾼灵活性、提供LRU、LFU、FIFO淘汰，基础属性⽀持热配置、⽀持的插件多6.监听器缓存管理器监听器（CacheManagerListener）和缓存监听器（CacheEvenListener）,做⼀些统计或数据⼀致性⼴播挺好⽤的如何使⽤？够简单就是Ehcache的⼀⼤特⾊，⾃然⽤起来just so easy!贴⼀段基本使⽤代码CacheManager manager = CacheManager.newInstance("src/config/ehcache.xml");Ehcache cache = new Cache("testCache", 5000, false, false, 5, 2);cacheManager.addCache(cache);name:缓存名称。
Redis缓存的适用性与替代方案的对比分析
Redis缓存的适用性与替代方案的对比分析随着互联网应用的快速发展，数据访问的性能和效率变得越来越重要。
为了提高系统的响应速度，很多开发者开始使用缓存技术来存储经常使用的数据。
而Redis作为一个高性能的内存缓存系统，被广泛应用于各个领域。
然而，对于某些应用场景，Redis缓存并不一定是最合适的选择，本文将对Redis缓存的适用性以及替代方案进行比较和分析。
一、Redis缓存的适用性1. 高性能：Redis以其快速的读写速度而闻名，尤其在读取大量数据时表现出色。
对于需要频繁读取的应用场景，Redis缓存能够显著提升系统的性能。
2. 内存存储：Redis将数据存储在内存中，相比于传统的磁盘存储，具备更高的读写速度。
这对于对数据访问有较高实时性要求的应用非常重要。
3. 数据结构丰富：Redis支持多种数据结构，包括字符串、哈希、列表、集合和有序集合等。
这些特性使得Redis适用于不同的业务需求，并能够方便地进行数据处理和计算。
二、Redis缓存的替代方案1. Memcached：Memcached是另一个常用的内存缓存系统，与Redis相比，它更加专注于缓存的功能，不支持像Redis那样丰富的数据结构。
然而，Memcached在缓存写操作的性能方面表现更好，适用于对读取性能要求较高的场景。
2. Hazelcast：Hazelcast是一个开源的分布式缓存系统，它提供了分布式数据缓存和计算功能。
相较于Redis，Hazelcast的主要优势在于其在分布式计算方面的支持，适用于需要进行分布式任务处理的场景。
3. Ehcache：Ehcache是一个基于Java的开源缓存框架，它提供了丰富的缓存功能和配置选项。
相较于Redis，Ehcache更适用于单机缓存的应用场景，并且具备更好的与Java应用程序的集成支持。
三、对比分析1. 性能比较：在内存访问速度方面，Redis具备较高的性能，尤其在读取方面更胜一筹。
memcache、redis、tair性能对比测试报告材料
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取不同大小的数据，重复三次。
Java中的分布式缓存框架有哪些
Java中的分布式缓存框架有哪些随着互联网应用的快速发展，分布式缓存已经成为了提高系统性能和扩展性的关键技术之一。
在Java开发领域，也涌现了许多优秀的分布式缓存框架。
本文将介绍几个Java中常用的分布式缓存框架，并分析它们的特点和适用场景。
一、EhcacheEhcache是一个开源的Java缓存框架，被广泛应用于各种Java应用中。
它提供了基于内存和磁盘的缓存机制，支持分布式部署，能够满足大规模应用的缓存需求。
Ehcache具有轻量级、易于使用和快速的特点，适合用于小型和中型的应用系统。
二、RedisRedis是一种高性能的内存数据存储系统，支持多种数据结构，可以用作分布式缓存的解决方案。
Redis提供了持久化和复制机制，可以实现高可用性和数据持久化。
同时，Redis还具有丰富的功能，如发布订阅、事务管理等，使得它不仅可以作为缓存系统，还可以用于其他用途，如消息队列等。
Redis适用于各种规模的应用系统。
三、MemcachedMemcached是一个简单的高性能分布式内存对象缓存系统。
它使用键值对的方式存储数据，提供了多种API，支持分布式部署。
Memcached具有高速的读写性能和可扩展性，通常被用于缓存数据库查询结果、页面内容等。
它适用于大规模应用和高并发场景，但需要注意的是，Memcached不提供数据持久化功能。
四、HazelcastHazelcast是一个基于Java的开源分布式缓存框架，它提供了分布式数据结构和集群管理功能。
Hazelcast采用了集中式架构，能够实现多节点之间的数据共享和同步。
它具有简单易用的特点，并提供了多种数据结构和并发算法的支持。
Hazelcast适用于构建复杂的分布式应用系统。
五、CaffeineCaffeine是一个在Java中最受欢迎的缓存库之一，它提供了高性能、无锁的内存缓存解决方案。
Caffeine采用了分片策略来管理缓存对象，提供了各种缓存策略和配置选项，可以根据实际需求进行灵活配置。
Redis缓存的LRU与LFU算法实现与性能对比
Redis缓存的LRU与LFU算法实现与性能对比缓存是提升系统性能和响应速度的重要组成部分。
Redis是一个高性能的键值存储系统，常用于缓存数据。
在Redis中，LRU（最近最少使用）和LFU（最不经常使用）是两种常见的缓存淘汰算法，用于确定哪些数据应该被从缓存中移除。
本文将对Redis缓存的LRU和LFU算法进行实现和性能对比。
一、LRU算法的实现LRU（最近最少使用）算法是根据数据的访问时间进行淘汰的一种缓存淘汰算法。
实现LRU算法的一种常见方式是使用双向链表和哈希表的结合。
具体实现如下：```1. 设置一个双向链表用于存储缓存的键值对，链表头部为最近被访问的数据，尾部为最近最少被访问的数据。
2. 设置一个哈希表用于存储缓存的键和对应的节点在链表中的位置。
3. 当需要访问一个键值对时，按照以下步骤进行操作：- 如果键存在于哈希表中，则将对应的节点移到链表头部，并返回节点的值。
- 如果键不存在于哈希表中，则返回null。
4. 当需要插入一个键值对时，按照以下步骤进行操作：- 如果键存在于哈希表中，则将对应的节点移到链表头部，并更新节点的值。
- 如果键不存在于哈希表中，则进行以下操作：- 如果缓存已满，则删除链表尾部的节点，并从哈希表中删除对应的键。
- 创建一个新的节点，并将其添加到链表头部，同时将键值对存储到哈希表中。
```二、LFU算法的实现LFU（最不经常使用）算法是根据数据的访问频率进行淘汰的一种缓存淘汰算法。
实现LFU算法的一种常见方式是使用哈希表和最小堆的结合。
具体实现如下：```1. 设置一个哈希表用于存储缓存的键和对应的节点。
2. 设置一个最小堆用于存储缓存的节点，堆顶节点表示访问频率最低的数据。
3. 当需要访问一个键值对时，按照以下步骤进行操作：- 如果键存在于哈希表中，则更新节点的访问频率，并调整最小堆中节点的位置，并返回节点的值。
- 如果键不存在于哈希表中，则返回null。
redis的hGetAll函数的性能问题（记Redis那坑人的HGETALL）
redis的hGetAll函数的性能问题（记Redis那坑⼈的HGETALL）在没关注这个函数之前，⼀直⽤的Memcache的数据存储⽅式，但是⾃从更换了redis之后，对于⼀个hash的数据存与取对于Memcache⽅便甚多，但是问题来了，⼀个hash的列表如果量不⼤的情况，⽤hGetAll函数⼏乎看不出问题，⼀旦这个列表超过50或者更多时，此时⽤hGetAll函数便能很直观的看到性能问题，这⾥就不作数据分析了。
Redis是单线程的！当它处理⼀个请求时其他的请求只能等着。
通常请求都会很快处理完，但是当我们使⽤HGETALL的时候，必须遍历每个字段来获取数据，这期间消耗的CPU资源和字段数成正⽐，如果还⽤了PIPELINING，⽆疑更是雪上加霜。
复制代码代码如下:PERFORMANCE = CPUs / OPERATIONs也就是说，此场景下为了提升性能，要么增加运算过程中的CPU数量；要么降低运算过程中的操作数量。
在为了继续使⽤hash结构的数据，⼜要解决此问题，⽐较⽅便的⽅法就是将hash以序列化字符串存储，取的时候先取出反序列化的数据，再⽤hGet(key,array(hash..))。
例如：复制代码代码如下:....$arrKey = array('dbfba184bef630526a75f2cd073a6098','dbfba184bef630526a75f2cd0dswet98')$strKey = 'test';$obj->hGet($strKey,$arrKey);把原本的hGetAll操作简化为hGet，也就是说，不再需要遍历hash中的每⼀个字段，因此即便不能让多个CPU参与运算，但是却⼤幅降低了操作数量，所以性能的提升仍然是显著的；当然劣势也很明显，和所有的冗余⽅式⼀样，此⽅案浪费了⼤量的内存。
有⼈会问，这样虽然没有了遍历字段的过程，但是却增加了反序列化的过程，⽽反序列化的成本往往也是很⾼的，难道这样也能提升性能？问题的关键在于开始我们遍历字段的操作是在⼀个cpu上完成的，后来反序列化的操作，不管是什么语⾔，都可以通过多进程或多线程来保证是在多个cpu上完成的，所以性能总体上是提升的。
redis和memcache对比
redis和memcache对⽐1、性能⽅⾯：没有必要过多的关⼼性能，因为⼆者的性能都已经⾜够⾼了。
由于Redis只使⽤单核，⽽Memcached可以使⽤多核，所以在⽐较上，平均每⼀个核上Redis在存储⼩数据时⽐Memcached性能更⾼。
⽽在100k以上的数据中，Memcached性能要⾼于Redis，虽然2、Redis最近也在存储⼤数据的性能上进⾏优化，但是⽐起Memcached，还是稍有逊⾊。
说了这么多，结论是，⽆论你使⽤哪⼀个，每秒处理请求的次数都不会成为瓶颈。
（⽐如瓶颈可能会在⽹卡）3、内存使⽤效率：使⽤简单的key-value存储的话，Memcached的内存利⽤率更⾼，⽽如果Redis采⽤hash结构来做key-value存储，由于其组合式的压缩，其内存利⽤率会⾼于Memcached。
当然，这和你的应⽤场景和数据特性有关。
4、数据持久化：如果你对数据持久化和数据同步有所要求，那么推荐你选择Redis，因为这两个特性Memcached都不具备。
即使你只是希望在升级或者重启系统后缓存数据不会丢失，选择Redis也是明智的。
5、数据结构:当然，最后还得说到你的具体应⽤需求。
Redis相⽐Memcached来说，拥有更多的数据结构和并⽀持更丰富的数据操作，通常在Memcached⾥，你需要将数据拿到客户端来进⾏类似的修改再set回去。
这⼤⼤增加了⽹络IO的次数和数据体积。
在Redis中，这些复杂的操作通常和⼀般的GET/SET⼀样⾼效。
所以，如果你需要缓存能够⽀持更复杂的结构和操作，那么Redis会是不错的选择。
⽹络IO模型⽅⾯：Memcached是多线程，分为监听线程、worker线程，引⼊锁，带来了性能损耗。
Redis使⽤单线程的IO复⽤模型，将速度优势发挥到最⼤，也提供了较简单的计算功能6、内存管理⽅⾯：Memcached使⽤预分配的内存池的⽅式，带来⼀定程度的空间浪费并且在内存仍然有很⼤空间时，新的数据也可能会被剔除，⽽Redis使⽤现场申请内存的⽅式来存储数据，不会剔除任何⾮临时数据 Redis更适合作为存储⽽不是cache7、数据的⼀致性⽅⾯：Memcached提供了cas命令来保证.⽽Redis提供了事务的功能，可以保证⼀串命令的原⼦性，中间不会被任何操作打断总结：如果简单地⽐较Redis与Memcached的区别，⼤多数都会得到以下观点：1 、Redis不仅仅⽀持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Ehcache/Redis/Tair缓存性能对比
后面介绍的不同方式都有测试数据，这些测试数据都是在同一的测试环境下得出的测试结果：
测试机器的配置如下：
64位5核CPU, E5620 @ 2.40GHz，内存8G
CDN端缓存
由于计数器的价值并不在，具体的值是多少，尤其是对一些大访问量的商品来说个位或者十位的数据并没有什么意义，所以对这些热门商品的计数器访问可以采用定时更新的办法，可以将计数器的值直接缓存在CDN上或者后端Nginx的缓存中，定时再到数据库服务器上获取最新的计数器的值，这样能够大量减少对后端服务器的访问请求，而且计数器的数据量很小对缓存服务器的空间需求也不大。
改进的结构图如下：
直接在Nginx中利用Cache策略缓存住热门计数器的值，利用http协议的cache+max age来失效缓存的方式更新计数器的值。
优点：
实现方式简单，改动小，能够挡住热门商品的计数器访问请求，采用这种方式对查询请求来说，能达到类似于静态服务器的性能，如Nginx能达到2w的QPS
缺点：没有解决同一商品的计数器合并请求的问题，数据量会增大一倍对更新请求没有办法缓存，只能减少查询请求的压力
基于Java的存储方式
由于目前采用Nginx模块的方法开发，每次修改要重新编译Nginx服务器，所以想采用基于Java的方式，使得维护要容易一些。
选用Ehcache作为数据存储服务器，Ehcache也是基于内存存储，支持定时持久化功能，非常适合存储像计数器这种小数据类型。
处理Http请求使用Tomcat容器，结构图如下：
处理逻辑采用一个servlet实现，并且在这个servlet中通过一致性Hash从Ehcache中获取计数器值。
在实际的部署结构中，可以将Tomcat和Ehcache部署在同一台机器上。
基于这种模式的测试结果如下：
Qps能达到1.3w左右，性能瓶颈是在Tomcat处理Http连接的请求上，Tomcat较Apache和Nginx处理请求性能较差。
优点：业务逻辑和存储服务器都采用Java开发，利于维护，也能能解决数据合并的问题。
缺点：Java服务器在处理Http短连接请求时要比Nginx等服务器性能稍差，与目前的2W的qps有些差距
基于Nginx+Redis
上次参加Velocity大会了解到新浪、百度这些公司，内部的计数器都是采用Redis作为存储服务器，性能非常好，官方给出的测试结果是，回来后测试了Redis的性能，性能果然不错，单台redis机器能支持将近6w的QPS
测试结果如下：
写：
读：
读写性能基本能达到6w（8G,5核的虚拟机）左右，5核cpu只会把一个cpu用满。
如下图所示：
全内存操作情况下要好于tair的5w（24G,8核的实体机）。
Redis目前支持多种客户端连接，我分别测试了基于Apache的PHP客户端，和直接基于Nginx的c客户端
基于Nginx的C客户端测试
和叔度了解到一个ab压不倒Nginx的性能瓶颈，所以采用两个ab压Nginx，结果如下：
两个加起来能达到1.7w左右的QPS，如果采用线上的8核CPU的话，达到2W以上的QPS肯定是没有问题的。
基于Apache的PHP客户端测试结果如下：
两个ab压测apache能达到1.1w左右的QPS，要比基于Nginx的c客户端差。
上面这两种情况，他们的结构图都是如下
Nginx可以直接采用一致性Hash的方式将相同的商品ID或者用户ID映射到同一台Redis服务器上，在Nginx上开发一个C的模块来简单的出来对计数器的操作。
优点：性能非常好，前端处理请求采用Nginx服务器，处理短连接性能非常好，后端采用Redis存储，性能也要好于tair，而且支持将数据分组，可以做到基于商品ID和用户ID数据合并。
缺点：同样要开发基于一个c模块的Nginx模块，以后维护也要麻烦一点。
Tair ldb和redis的对别测试
1.做了下Tair的ldb版本和Redis的vm形式的持久化对比测试，感谢宗岱给配置了tair的ldb
版本的配置了参数
2.测试机器是相同配置的64位5核CPU, E5620 @ 2.40GHz，内存8G的
虚拟机
3.测试数据：造了1亿（0~100000000整数）条不同key的数据
4.测试方式：分别测试tair和redis的两个方法：incr和get的写读接口
5.数据读写范围是：在0~1亿条数据中，随机读写。
6.测试结果如下：
1.CPU资源对比
Tair：
Redis：
∙Tair的5个核基本都使用了，load的得到4左右
∙Redis只使用了一个核，其他4个核基本没有，而且load维持在1以下，所以在多核情况下可以部署多个Redis实例，性能会更好
1.写情况的TPS对比：
∙Tair的写平均TPS在1.2w左右
∙Redis的写平均TPS在5.4w左右
1.读情况对比：
∙Tair的读平均TPS在2.5w左右∙Redis的写平均TPS在5.5w左右。