shell

解决方法 Session Sticky 让负载均衡器能够根据每次的请求的会话标识来进行请求的转发，这样就能保证每次都能落到同一台服务器上面。 Session Replication 即 session 复制，一般应用容器都支持 Session Replication 的方式。这种方式开销大，只适合几台机器的场景。 Session数据集中存储 是对方案 2 的优化，Session数据不保存到本机而且存放到一个集中存储的地方，如 redis。 Cookie Based 所有 session 数据放在 cookie 中。 每种方式的具体原理及优缺点，可以查看附录1. 可以发现， 大多数情况下，方法 3 最优。 session基于redis共享有两种基本的方案 基于容器自身的扩展，比如tomcat的session-manage，以及 https://github.com/jcoleman/tomcat-redis-session-manager.  基于spring-session的方案. spring-session的好处不仅仅是session共享，它还可以与容器解耦，应用于多终端session共享，websocket，restful api等场景。 环境 jdk 8 意味着老的 jar 包不能用 tomcat 8.5 spring 5 spring boot 2 maven 依赖管理。建立公司内部的私服。 技术选型要有一定的前瞻性，带来的好处大于学习成本。 参考资料 分布式集群Session共享 http://blog.csdn.net/jerome_s/article/details/52658946 单点登录实现（spring session+redis完成session共享） https://www.cnblogs.com/hujunzheng/p/6395966.html 使用nexus3搭建私有仓库 https://www.jianshu.com/p/dbeae430f29d

在上一篇文章中, 我写了基于 svn 的将变动按 war 包目录提取的文章 https://www.jianshu.com/p/a2ec55f0da0a , 这篇文章我做了一些优化, 使得脚本能处理 C R U D 等大部分情况, 不能处理的部分也会有合理的输出. 下面假设你的项目是标准的 eclipse java web 项目. 下面两个脚本配合, 可以将变动很方便的同步到测试环境部署,值得一提的是 rsync 非常非常快. get_changes.sh #!/bin/bash # 这个脚本分析 svn diff -r commit1:commit2 --summarize 的输出, 找到两个 commit 间变动的文件, # 按文件原有的目录结构 和 war 包的目录结构, 放到放在一个目录中. # 然后, 可以直接将该目录中的内容拖到 war 包中以实现快速准备 war 包; 或上传到测试服务器以实现部署 # 支持 新增, 修改; 删除不支持, 需手动删除. if [[ $# != 2 ]]; then echo "get changes from between < oldCommit > and < newCommit> , for example:" echo "....