分布式部署的常见问题解决方案汇总 - wtdig/study GitHub Wiki

分布式部署问题集锦

一、模块之间的调用

二、会话的统一管理

三、单点登录

1、描述

“伪”在何处
跟EAI中的SSO相比，这里所说的单点登录是很简单的，算不上是“真正”的SSO
1：本身就是一个系统，只有一套用户和权限系统
2：对用户的验证方式是统一的
3：都是内部系统，相互信任，所以也就不用验证是否可访问系统了

2、解决方案

1：简单的：使用Shiro的统一会话管理，实现单点登录
2：稍麻烦些的：使用Shiro+CAS来实现
3：更麻烦的：使用专业的SSO框架或产品

四、数据更新的一致性

1、描述

分布式的一致性介绍
对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来
看，一致性指的是并发访问时更新过的数据如何获取的问题；从服务端来看，则
是更新的数据如何复制分布到整个系统，以保证数据最终一致。
一致性是有并发读写才有的问题，因此在理解一致性的问题时，一定要注
意结合考虑并发读写的场景。

CAP的最终一致性
从客户端角度，并发访问时，更新过的数据在不同进程如何获取的不同策
略，决定了不同的一致性。
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强
一致性；如果能容忍后续的部分或者全部访问不到，则是弱一致性；如果经过一
段时间后要求能访问到更新后的数据，则是最终一致性。

2、常见的解决方案

1）、有一个公共数据库

1-1）、单点部署，整个系统只有一个地方可以修改数据；

1-2）、采用版本控制；设置一个版本号，当进行更新的时候，先去对比该版本号是否有变化，如果不一致，说明有人修改了，此时要查询最新的数据，然后更新版本号；

2）、分散到多个数据库

1-1）、采用预分配的方案，将数据事先固定住；比如，2个库存A\B,A库存分配100、B库存分配100、这样每个库的数量修改，不影响其它数据库；还可以设置一个调度中心，当库存的数量低于某个数值时，进行库存的调拨；

五、分布式事务

1、解决方案

1：同一个Web服务器，多个数据库，可以使用Atomikos
2：跨越多个Web服务器的事务，如果远程调用支持事务传播，那么使用JTA就可以；
如果不支持事务传播，就尽量转化为一个web服务器的情况
3：自行开发事务逻辑事务管理器
4：采用业务补偿回滚的方式
5：重新设计和规划

一般事务逻辑事务管理器，是2阶段提交，第一阶段询问是否能提交，第二阶段才是真的提交

业务补偿回滚的方式：比如：一个事物包含三个事物：1、库存修改；2、订单生成；3、写入价格；当写入价格出错后，将库存修改回去（比如先前是减20，现在就是加20）；将订单删除掉

Try{
• 1：库存+20=== w1
• 2：写入订单 === w2
• 3：改写价格 === w3
• }catch(){
• //判断出是第3步失败了
//回滚1 继续调w1 ，库存-20
//回滚2 调w2 , 删除订单
• }