J2Cache

诱发问题:MQ是否设置了消息消费顺序？ 我发现在mq并发进入消费时并不能保证消息的消费顺序，此时如果同时一万线程对 一个 生产者 一个 消费者的 一个 队列业务互斥进行消费，此时的消费顺序是无序的，同一时刻会造成互斥数据同时存在多份，且发生率高达10%，而目前能想到的解决方案是，redis的消息是存取很快，且有顺序的，所以把mq消费的方法加了分布式锁，但是这效率能不能再次保证呢？不能的，因为你mq存在的意义就是异步消费，如果不是互斥线程，那锁起来反而影响了性能，此时，就要看此时的数据显示重不重要？如果数据重要就锁，如果不重要，最终数据一致就可以了。 那么当每秒4000万数据进行消费，且此时需要对数据进行过滤时如何设计？ L1缓存:Springcache+j2cache L2缓存:redis 由于大量的缓存读取会导致 L2 的网络成为整个系统的瓶颈，因此 L1 的目标是降低对 L2 的读取次数, 读取顺序 -> L1 -> L2 -> DB J2Cache 默认使用 Caffeine 作为一级缓存，使用 Redis 作为二级缓存 但是由于此类数据中是存在部分黑名单数据的，此时需要将数据过滤后才能缓存然后消费。 过滤大key数据 放入缓存key分片 队列+mq根据消息优先级去消费 二级缓存 过滤大key数据 由于瞬时数据将达到4000万,一开始的想法是能不能用bitmap去存放数据

J2Cache 是一个两级的缓存框架，第一级是基于内存的数据缓存，支持 caffeine、ehcache2 和 ehcache3 ，二级缓存只支持 redis。 在某些生产环境中你可能没有 redis，但是又希望多个应用节点间... 来源： oschina 链接： https://my.oschina.net/u/4415089/blog/4523317

问题描述 场景：我们的应用系统是分布式集群的，可横向扩展的。应用中某个接口操作满足以下一个或多个条件： 1. 接口运行复杂代价大， 2. 接口返回数据量大， 3. 接口的数据基本不会更改， 4. 接口数据一致性要求不高（只需满足最终一致）。 此时，我们会考虑将这个接口的返回值做缓存。考虑到上述条件，我们需要一套高可用分布式的缓存集群，并具备持久化功能，备选的有 ehcache集群 或 redis主备（sentinel） 。 ehcache集群因为节点之间数据同步通过组播的方式，可能带来的问题：节点间大量的数据复制带来额外的开销，在节点多的情况下此问题越发严重，N个节点会出现N-1次网络传输数据进行同步。（见下图，缓存集群中有三台机器，其中一台机器接收到数据，需要拷贝到其他机器，一次input后需要copy两次，两次copy是需要网络传输消耗的） redis主备由于作为中心节点提供缓存，其他节点都向redis中心节点取数据，所以，一次网络传输即可。（当然此处的一次网络代价跟组播的代价是不一样的）但是，随着访问量增大，大量的缓存数据访问使得应用服务器和缓存服务器之间的网络I/O消耗越大。（见下图，同样三台应用服务器，redis sentinel作为中心节点缓存。所谓中心，即所有应用服务器以redis为缓存中心，不再像ehcache集群，缓存是分散存放在应用服务器中，需要互相同步的

现在的系统是越来越复杂了，不仅仅是功能复杂，系统结构也非常复杂，而且经常在一个系统里包含几种不同语言编写的子系统。例如用 JavaScript 做前端开发、用 Java/PHP 等等做后端，C/C++/Go 等做一些底层模块等等（我只是举个栗子，不要挑起斗争哦）。 这些不同语言编写的子系统经常需要进行一些交互，多数方面的数据交互一般都有对应的技术或者中间件来解决，例如消息中间件、数据库、RESTful 接口、Redis 等等。 本文主要聚焦于缓存系统的交互。 在多语言开发的系统中，使用 Redis 这类服务实现缓存交付是非常适合的，但前提是缓存的数据必须是每一种语言都能识别。基于这个前提来考量，JSON、XML 是最合适的格式，因为它们是语言无关的规范，任何语言都能方便的解析这两种格式。而 JSON 相比 XML 又更优一些，因为同样数据用 JSON 表示体积更小。 所以 Redis + JSON 就成为了跨语言环境中的缓存首先解决方案。不过我之前一直在强调单独使用 Redis 做缓存的严重问题（ 详情 ）：巨大的缓存数据吞吐量会导致 Redis 的数据读取变得异常缓慢，而扩容 Redis 的成本又非常高。 因此我们有必要在跨语言环境中使用 J2Cache 。 那么问题来了，J2Cache 是一个 Java 开发的缓存桥梁，非 Java 语言的应用怎么用 J2Cache 呢

一直以来 J2Cache 都是使用 Jedis 连接 Redis 服务的。Jedis 是一个很老牌的 Redis 的 Java 开发包，使用很稳定，作者维护很勤勉，社区上能搜到的文章也非常非常多。算是使用范围最广的 Redis 开发包。但是 Jedis 比较推出时间比较早，整个设计思路比较传统，例如不支持异步操作，接口设计比较繁琐老套（相比其他开发包而已），使用连接池占用很多的物理连接资源。当然，这个是可以理解的，比较一个比较早期的开发包，相对其做大的结构调整是很难的，而且用户也不一定会接受。 自从 2.7.0 版本开始，J2Cache 就增加了 Lettuce 的支持。Lettuce是一个可伸缩线程安全的 Redis 客户端。多个线程可以共享同一个RedisConnection。它利用优秀 Netty NIO 框架来高效地管理多个连接。 相比较 Jedis ，我觉得 Lettuce 的优点有如下几个方面： 更加直观、结构更加良好的接口设计 基于 Netty NIO 可以高效管理 Redis 连接，不用连接池方式 支持异步操作（J2Cache 暂时没用到这个特性） 文档非常详尽 不过 Lettuce 需要至少 Java 8 的支持，好在 J2Cache 也要求至少 Java 8 ，就这么愉快的决定了。 在 J2Cache 2.7.0 版本以及以后的更新版本中，想使用 Lettuce

做 Java Web 开发的人多数都会需要使用到 session （会话），我们使用 session 来保存一些需要在两个不同的请求之间共享数据。一般 Java 的 Web 容器像 Tomcat、Resin、Jetty 等等，它们会在内存中保存 session 数据。这样做会有两个不足： 服务重启后 session 数据丢失 应用做集群部署的时候，不同的节点无法共享 session 数据 我们以使用比例最高的 Tomcat 为例，针对第二个问题 Tomcat 提供了集群 session 复制的解决方案，详情请看 官方文档 。看完文档你会发现 Tomcat 自带的方法配置非常复杂，而且它没有解决第一个问题 —— 服务重启导致 session 数据丢失的问题。 现在还有另外一种方案就是使用 memcached 或者是 redis 来存储 session 数据，于是就有了这么一些开源项目： https://www.oschina.net/p/tomcat-redis-session-manager https://www.oschina.net/p/redis-manager https://www.oschina.net/p/memcached-session-manager 这些开源项目使用和配置都比较简单，而且对应用完全透明，只需要在 server.xml 中配置好 Manager

从软件名称看还有点像呢？ 但这两者完全不是一回事！ JetCache 是阿里的一个基于 Java 的缓存系统封装，提供统一的 API 和注解来简化缓存的使用。也就是说这个项目主要的目的是为了让所有的缓存框架通过 JetCache 实现统一的接口调用，让你不需要关心底层缓存的 API 细节。 这是设计模式层面上的封装。 而 J2Cache 完全不同，J2Cache 是一种全新的缓存功能设计。它是一个两级的缓存框架！！！ 它主要要解决的问题是： 使用内存缓存时，一旦应用重启后，由于缓存数据丢失，缓存雪崩，给数据库造成巨大压力，导致应用堵塞 使用内存缓存时，多个应用节点无法共享缓存数据 使用集中式缓存，由于大量的数据通过缓存获取，导致缓存服务的数据吞吐量太大，带宽跑满。现象就是 Redis 服务负载不高，但是由于机器网卡带宽跑满，导致数据读取非常慢 更详细关于 J2Cache 的介绍请看 这里 。 所以呢，不要再搞混了哦！ 目前 J2Cache 还没有同类产品！ 来源： oschina 链接： https://my.oschina.net/u/12/blog/2988523

不少人看到 J2Cache 第一眼时，会认为这就是一个普普通通的缓存框架，和例如 Ehcache、Caffeine 、Spring Cache 之类的项目没什么区别，无非是造了一个新的轮子而已。事实上完全不是一回事！ 目前缓存的解决方案一般有两种： 内存缓存（如 Ehcache） —— 速度快，进程内可用 集中式缓存（如 Redis）—— 可同时为多节点提供服务 现有的缓存框架已经非常成熟而且优秀，J2Cache 无心造一个新的轮子，它要解决的几个问题如下： 使用内存缓存时，一旦应用重启后，由于缓存数据丢失，缓存雪崩，给数据库造成巨大压力，导致应用堵塞 使用内存缓存时，多个应用节点无法共享缓存数据 使用集中式缓存，由于大量的数据通过缓存获取，导致缓存服务的数据吞吐量太大，带宽跑满。现象就是 Redis 服务负载不高，但是由于机器网卡带宽跑满，导致数据读取非常慢 在遭遇问题1、2 时，很多人自然而然会想到使用 Redis 来缓存数据，因此就难以避免的导致了问题3的发生。 当发生问题 3 时，又有很多人想到 Redis 的集群，通过集群来降低缓存服务的压力，特别是带宽压力。 但其实，这个时候的 Redis 上的数据量并不一定大，仅仅是数据的吞吐量大而已。 咱们假设这样一个场景： 有这么一个网站，某个页面每天的访问量是 1000万，每个页面从缓存读取的数据是 50K。缓存数据存放在一个

最近看到红薯的J2Cache强大到不行，居然长期占据开源中国开源项目排行榜，偶就气不打一处来。 话说你是开源中国第一帅，这个咱们大家有共识，确实实力在那里，我们都认了。 话说你口才比@永和 好，这个只要永和没有意见，我们也同意。 但是，做个J2Cache居然还悬赏好多次，貌似要打造成开源中国第一开源项目，这就有点过分了。不对，不是过分，是相当过分。 所以今天，偶就狠狠的扒掉@红薯 的内裤，对J2Cache进行一下深入剖析。 前面写过一篇文章，标题是 吐槽一下J2Cache ，吐槽过后发现J2Cache的热度居然火速上升，貌似有成为开源中国第一开源项目的意思，偶这小心脏就有点受不了了，于是决定再写一篇文章，直接狠一点把 @红薯 的内裤扒掉，对J2Cache进行一下深入剖析。 Cache接口 /** * Implementors define a caching algorithm. All implementors * <b>must</b> be threadsafe. * @author liudong */ public interface Cache { /** * Get an item from the cache, nontransactionally * @param key cache key * @return the cached object or null

前提说明：目前开源中国社区在做改版，因此网站同时存在新旧两种不同的版面，例如个人空间就是新的系统。因此整个网站包含两套系统，改版前和改版后，我们把改版前叫老系统，把改版后叫新系统。 大概一周多的时间，经常会感觉网站，包括客户端使用过程中有卡顿的情况，没太在意。但是前天这个卡顿就变得比较严重，动弹里开始出现各种反应访问慢的信息。 检查所有的机器的 CPU 使用率都在一个正常的状态，Tomcat 无特别的异常日志，应用的数据库连接池的忙连接比平时要高好多倍，但是数据库操作一些正常。 检查数据库慢查询日志，比平时多了一些，基本上集中在近期改版新的 SQL 上，把这些慢查询通过索引调整、SQL 优化方式解决后，慢查询不再出现，但是系统响应速度仍旧没有提升。 我们一度怀疑是数据库响应慢，想重启一下社区的 MySQL 数据库，这个数据库已经运行超过 5 年没重启过了！！！但还是忍住了！再试试其他不行再说。 然后发现了一个非常非常慢的操作，就是在客户端上收藏某篇文章的时候，完全没有响应，或者是要十几秒才有反应。 于是在这个收藏功能对应的代码增加了数据监控点，在日志中记录该方法几个逻辑的执行时间。更新到线上进行测试发现，从在界面上点击收藏，到日志的输出中间隔了好几十秒，而真正功能的执行时间很短。看似有很多请求在排队等 Tomcat 处理导致的堵塞，但是 Tomcat