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

纯过程记录文，偏理论，不贴代码，因为费时。

应用复杂了或者负荷太高了，就得考虑集群或者分布式。
然后就得考虑由此带来的问题–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的。

此致。