微服务实战系列之J2Cache

前言

经过近几天陆续发布Cache系列博文,博主已对业界主流的缓存工具进行了基本介绍,当然也提到了一些基本技巧。相信各位盆友看见这么多Cache工具后,在选型上一定存在某些偏爱:

A同学说:不管业务千变万化,我对Redis的爱永不变。

B同学说:不管集中式还是分布式,单体还是集群,我只相信Redis。

C同学说:无论穿透击穿还是雪崩,只要把key定义好,任尔东西南北风。

好了,看完这篇文章,希望以上同学有所启发。



一、J2Cache介绍

1. 背景

当我们为业务系统引入缓存时,会考虑哪些方面?

比如为了追求体验好,(业务量不大时)单点集成 redisehcache,似乎都没有太大问题;进一步为了追求缓存的一致性,部署一套redis集群,也是可行的。

但redis毕竟是"消耗品",内存有多珍贵,价格有多昂贵。为了追求缓存共享,我们可能投入比较高的成本才能如愿。该怎么办?好比数据库的"护卫"是缓存,那么redis的"护卫"又是谁可以胜任呢?答案是ehcache(推荐)。

此刻,其实我们已做了两级缓存的设计,如一级缓存没有hit,继续找二级缓存,实在不行才去敲数据库的"门"

叙述到此,J2Cache应运而生,它为两级缓存的设计和实现提供了解决方案。

J2Cache 是 OSChina 目前正在使用的两级缓存框架(要求至少 Java 8)。第一级缓存使用内存(同时支持 Ehcache 2.x、Ehcache 3.x 和 Caffeine),第二级缓存使用 Redis(推荐)/Memcached 。 由于大量的缓存读取会导致 L2 的网络成为整个系统的瓶颈,因此 L1 的目标是降低对 L2 的读取次数。 该缓存框架主要用于集群环境中。单机也可使用,用于避免应用重启导致的缓存冷启动后对后端业务的冲击。

通过两级缓存机制,对缓存进行错峰控制,降低对Redis的消耗,同时提高一级缓存的使用率,从而实现业务系统的性能整体提升。

那么,两级缓存是如何协作呢?请把目光聚焦下图:

2. 入门

如何入门,可参考该博主进行学习:手把手入门

如果能够亲自尝试一把,一定能够体会它的美,博主不再赘述。

二、J2Cache组播

1. 工作原理

学会J2Cache的基本使用之后,应该要关注如何完成缓存同步了。

J2Cache提供了两种方案:基于Redis Pub/Sub(发布/订阅,不推荐)或基于JGroups广播(推荐TCP模式)。无论选择哪种模式,最终做到缓存保持同步。

鉴于Redis发布/订阅的一些"槽点",博主推荐使用JGroups广播机制。

通过上图我们可以看到,当数据更新时,一级二级缓存是如何协同并保持一致的过程。

2. 使用方式
  • (1)j2cache.properties
powershell 复制代码
//指定广播方式
j2cache.broadcast = jgroups  
jgroups.channel.name = j2cache
//指定Jgroup为TCP广播并配置
jgroups.configXml = /j2cache/network-tcp.xml 
//指定一级缓存
j2cache.L1.provider_class = ehcache
//指定二级缓存
j2cache.L2.provider_class = redis
//ehcache配置
ehcache.configXml=/j2cache/ehcache.xml
  • (2)network-tcp.xml
powershell 复制代码
<config xmlns="urn:org:jgroups"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
    <TCP bind_port="7800" />
    <TCPPING timeout="3000"
             initial_hosts="192.168.1.11[7800],192.168.1.12[7800]"
             port_range="1"
             num_initial_members="2"/>
    <MERGE2  min_interval="10000" max_interval="30000"/>
    <FD_SOCK/>
    <FD timeout="3000" max_tries="3" />
    <VERIFY_SUSPECT timeout="1500"  />
    <BARRIER />
    <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
    <UNICAST3 />
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="4M"/>
    <pbcast.GMS print_local_addr="true" join_timeout="3000" view_bundling="true"/>
    <MFC max_credits="2M" min_threshold="0.4"/>
    <FRAG2 frag_size="60K"  />
    <pbcast.STATE_TRANSFER/>
</config>

结语

J2Cache为我们合理使用缓存,有效利用缓存资源,提供了很好的方案。

这个时代,合作才是前进的保障和希望。在微服务界也是如此,有"种菜"的自然就有"洗菜"的,有"洗菜"的自然就有"配菜"的。

今日至此,博主的Cache系列也要告一段落了,希望各位盆友有所收获!

最后,博主送给大家一句话:无论是哪种"菜",一定要先尝为快,切忌囫囵吞枣。

相关推荐
三坛海会大神5551 小时前
k8s(十)Helm详解
云原生·容器·kubernetes
尘世中一位迷途小书童1 小时前
版本管理实战:Changeset 工作流完全指南(含中英文对照)
前端·面试·架构
尘世中一位迷途小书童2 小时前
VitePress 文档站点:打造专业级组件文档(含交互式示例)
前端·架构·前端框架
K_i1342 小时前
Kubernetes流量管理:从Ingress到GatewayAPI演进
云原生·容器·kubernetes
m0_651593912 小时前
Netty网络架构与Reactor模式深度解析
网络·架构
xrkhy5 小时前
微服务之SpringCloud Alibaba(注册中心Nacos)
spring cloud·微服务·架构
会开花的二叉树5 小时前
C++微服务 UserServer 设计与实现
开发语言·c++·微服务
虫小宝6 小时前
Java分布式架构下的电商返利APP技术选型与架构设计实践
java·分布式·架构
007php0076 小时前
百度面试题解析:Zookeeper、ArrayList、生产者消费者模型及多线程(二)
java·分布式·zookeeper·云原生·职场和发展·eureka·java-zookeeper
唐僧洗头爱飘柔95276 小时前
【SpringCloud(6)】Gateway路由网关;zuul路由;gateway实现原理和架构概念;gateway工作流程;静态转发配置
spring·spring cloud·架构·gateway·请求转发·服务降级·服务雪崩