很多pc网站都有一个实时在线人数的统计功能,那么一般这种是采用什么方式来实现的呢? 这里我们介绍一个最基础的是实现方式,基于Session结合WebListener来实现在线人数统计
首页 | 归档 | SpringBoot | SpringCloud | SpringSecurity | 一灰灰Blog | 神奇百宝箱 | 关于 |
|
很多pc网站都有一个实时在线人数的统计功能,那么一般这种是采用什么方式来实现的呢? 这里我们介绍一个最基础的是实现方式,基于Session结合WebListener来实现在线人数统计
虽然我们现在基本上已经进入了分布式session的时代了,但是在切实去看最新的oauth, sso, jwt等各种登录方案之前,我们有必要学习一下最早的cookie/session方案,看一下它们是怎么协同工作的,又有什么局限性
上一篇介绍了Caffiene整合Spring的缓存注解@Cacheable,在这篇示例中,所有的缓存公用,但是实际的场景中,我们可能会更希望针对不同的场景,配置不同的缓存(比如我的关键数据,虽然访问频率可能没那么高,但是每次实际读取的成本很高,又不怎么变动,我希望可以更长久的缓存;不希望这些数据因为缓存的淘汰策略被其他的热点数据给淘汰掉),那么可以怎么处理呢?
接下来我们来看一下两种不同的方式,来实现上面的诉求
前面一片文章虽说介绍了Caffeine的使用方式,但是更多的是偏向于基础的Caffeine用法;接下来这边博文将给大家介绍一下Caffeine结合Spring的@Cacheable
注解,来实现内部缓存的使用姿势
前面介绍的两篇基于配置方式的数据库初始化方式,使用起来非常简单,但是有一个非常明显的问题,如何实现表结构存在时不再初始化,不存在时才执行? 如果数据库也不存在,也需要初始化时创建,可行么?
接下来介绍一下如何使用DataSourceInitializer来实现自主可控的数据初始化
上一篇博文介绍如何使用spring.datasource
来实现项目启动之后的数据库初始化,本文作为数据库初始化的第二篇,将主要介绍一下,如何使用spring.jpa
的配置方式来实现相同的效果
在我们的日常业务开发过程中,如果有db的相关操作,通常我们是直接建立好对应的库表结构,并初始化对应的数据,即更常见的情况下是我们在已有表结构基础之下,进行开发;
但是当我们是以项目形式工作时,更常见的做法是所有的库表结构变更、数据的初始、更新等都需要持有对应的sql变更,并保存在项目工程中,这也是使用liqubase的一个重要场景;
将上面的问题进行简单的翻译一下,就是如何实现在项目启动之后执行相应的sql,实现数据库表的初始化?
本文将作为初始化方式的第一篇:基于SpringBoot的配置方式实现的数据初始化
接着上一篇容器刷新前的扩展点,我们继续往下走;接下来来到的就是bean的定义扩展处,它是在Spring容器刷新之后,应用的bean定义加载完成、实例化之前提供的切入点,主要是通过实现BeanDefinitionRegistryPostProcessor
接口的两个方法,来实现自定义的bean定义,或者对已注册的bean进行修改or代理替换
本文将带来的知识点如下:
postProcessBeanDefinitionRegistry
方法 优先于 postProcessBeanFactory
方法执行本文将作为Spring系列教程中源码版块的第一篇,整个源码系列将分为两部分进行介绍;单纯的源码解析,大概率是个吃力没人看的事情,因此我们将结合源码解析,一个是学习下别人的优秀设计,一个是站在源码的角度看一下我们除了日常的CURD之外,还可以干些啥