JVM高性能本地缓存Caffeine使用案例
Background对于服务消费,响应时间(RT)的长短是衡量一个系统高效处理业务的重要指标,缓存就是必不可少的优化工具,在一个高并发的场景中往往占有着非常重要的角色,所以开发人员需要根据不同的应用场景来选择不同的缓存框架,比如分布式缓存redis,或者内存缓存GuavaCache。
我们团队有一个调用比较频繁的服务,之前是和别的团队共用的Redis缓存服务,前不久突然得到消息,维护该redis团队要收回使用权,而我们服务使用也比较简单,只是用来做一个接口调用鉴权,从redis中拿出所有授权方的appKey,然后校验调用方的appKey是否合法。所以我第一想法是采用jvm本地缓存,因为这个调用方不会很多,而且数据是比较静态的,变化不会很频繁,放在jvm本地内存中,也不会占用很大空间,而且也不用担心多个部署实例缓存不一致的问题,经过调用有很多比较优秀的本地缓存比如GuavaCache,Caffeine等。我最后采用了Caffeine。
减少重复劳动,使用Mysql存储过程批量创建表
背景相信很多公司发展到一定规模,数据量达到千万级甚至亿级别的时候,开始考虑分库分表,最近我们团队一个同事接到别的团队交接过来的一个应用服务,每天的数据增量在1千万,由于时间紧迫,存储数据在Mysql中,经过短暂调研我们采用了分库分表的中间件Apache ShardingSphere的分库分表组件ShardingSphere-JDBC,这不是本文的重点,重点是我们做分库分表时,需要一次性创建几十甚至上百张分表,如果Ctrl+C和Ctrl+V也是极其累的,同事问我有木有简单的方法,减少重复劳动,我第一个想法就是用Mysql的存储过程或者函数批量创建表,解放生产力。
Tomcat高危安全漏洞影响SpringBoot和SpringCloud多个版本及解决方案
事件背景2020是庚子年,是不平凡的一年,据2020年6月25日Apache官方安全团队通过邮件公开报告显示,Tomcat版本8.5.0 至 8.5.55,9.0.0.M1 至 9.0.35,10.0.0-M1 至10.0.0-M5爆出了一个高危漏洞, 主要涉及HTTP/2拒绝服务漏洞的细节及解决方案。
Kafka开启JMX监控操作实践
前段时间,我们团队使用的kafka集群压力比较大,需要接入监控,而运维给搭建kafka集群的时候没有开启JMX监控,于是我调用了3种开启方式,并本地进行了开启验证,方便后续接入kafka eagle监控平台。