springboot利用jdbc实现分布式session,集成spring-security

18 篇文章 0 订阅
纯过程记录文,偏理论,不贴代码,因为费时。

应用复杂了或者负荷太高了,就得考虑集群或者分布式。
然后就得考虑由此带来的问题–session共享、资源的并发访问、服务的划分。
由于,目前我司各类小项目之间差异太大,无法或者说不值得强行将其整合为一个大的应用。因此,在项目规模没上来之前,不值得上分布式或者集群。但是,相关技术储备还是要做一些的。主要是考虑,可能会有一些项目慢慢壮大,到了瓶颈的时候,就可以单独为这些架设小集群之类。
我还是偏工程思维,立足实际,技术一切为产品服务,毕竟不是家家都是华为。要在其位谋其政,不盲目追求技能的牛B,但也鄙视联想那种本该承担起更大责任的公司,却畏缩不前,都到了那个位置了,还不花大力气寻求技术上的突破。这个就扯远了。

1,对于资源的并发访问。服务内部可用信号量,服务之间的并发往往是针对数据库中的数据的。考察了悲观锁和乐观锁,综合考虑业务场景,还是决定采用悲观锁。因为,悲观锁非常好理解。类似于mutex互斥一样,我锁了,你就不能改了,不管从哪你都不能改了,直接加在数据库层面。而乐观锁,说是比对version,可问题是,对version的并发如何实现呢。线程1在写入时通过对version的比对来发现数据是否被改变了,可version本身也会有并发问题的。看了很多文章都没有纠结于此点的,我的理解是,乐观锁底层的实现还得基于数据库层面的锁机制,不知道是否是锁住单个字段,这个就不得而知了。重点的是,事务的规律摆在那,既然存在并发的问题,那顶多将这个并发的粒度做的很细,但不可能消灭并发。因为,没查到乐观锁我想要的具体的实现原理,也没那功夫那纠结了,就直接悲观锁吧,简单,好懂。至于说,什么基于redis的分布式锁啥的,暂时看不到有这方面需求。
2,session的共享。可以基于redis,也可以是jdbc,或者还有别的服务间共享session机制,或者是网关转发时做些这样那样的处理的别的机制。但是,我们的业务,访问频率高的用不到session,用到session的都是低频访问,那就基于jdbc最简单。然后,springboot的配置是真的简单。
官方文档
参考1
参考2
3,集成spring-security后。如何集成不说了,网上很多。只要实现了分布式session,security也自然而然就可以支持分布式了,因为,它本身也是基于session的。

此致。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值