Background对于服务消费，响应时间（RT）的长短是衡量一个系统高效处理业务的重要指标，缓存就是必不可少的优化工具，在一个高并发的场景中往往占有着非常重要的角色，所以开发人员需要根据不同的应用场景来选择不同的缓存框架，比如分布式缓存redis，或者内存缓存GuavaCache。 我们团队有一个调用比较频繁的服务，之前是和别的团队共用的Redis缓存服务，前不久突然得到消息，维护该redis团队要收回使用权，而我们服务使用也比较简单，只是用来做一个接口调用鉴权，从redis中拿出所有授权方的appKey，然后校验调用方的appKey是否合法。所以我第一想法是采用jvm本地缓存，因为这个调用方不会很多，而且数据是比较静态的，变化不会很频繁，放在jvm本地内存中，也不会占用很大空间，而且也不用担心多个部署实例缓存不一致的问题，经过调用有很多比较优秀的本地缓存比如GuavaCache，Caffeine等。我最后采用了Caffeine。

背景相信很多公司发展到一定规模，数据量达到千万级甚至亿级别的时候，开始考虑分库分表，最近我们团队一个同事接到别的团队交接过来的一个应用服务，每天的数据增量在1千万，由于时间紧迫，存储数据在Mysql中，经过短暂调研我们采用了分库分表的中间件Apache ShardingSphere的分库分表组件ShardingSphere-JDBC,这不是本文的重点，重点是我们做分库分表时，需要一次性创建几十甚至上百张分表，如果Ctrl+C和Ctrl+V也是极其累的，同事问我有木有简单的方法，减少重复劳动，我第一个想法就是用Mysql的存储过程或者函数批量创建表，解放生产力。

事件背景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集群压力比较大，需要接入监控，而运维给搭建kafka集群的时候没有开启JMX监控,于是我调用了3种开启方式，并本地进行了开启验证，方便后续接入kafka eagle监控平台。