分布式事务与几种简单设计模式

TCC模式

在分布式事务中需要一连串操作同时成功，同时失败，譬如订单服务，客户下了订单，订单要调用库存服务扣库存，调用积分服务加积分，调用出单服务出单，调用金库服务加钱，这些都有服务都要同时成功，那怎么办呢？业界提出了tcc模式这种提交，也就是分try-comfirm-cancel三步走，那么具体到业务怎么设计呢？譬如库存服务的表除了库存数量这个字段还要冻结库存字段，把在try阶段扣的库存放在这，库存字段照样减库存，这里冻结的库存是为失败回滚准备的，而积分服务同样加一个冻结字段，而订单服务的状态这时是一个特殊状态，你可以设置为处理中，然后如果所有服务都调成功后，就进入了confirm阶段，这是就更新订单状态为成功，冻结字段的值置为零。假如有些服务没成功，就进入了cancel阶段，然后把冻结字段的值还给原来的库存数量就行，订单状态设为失败就行。这么处理需要依赖分布式框架，也就是所有涉及到分布式处理的服务都要引入分布式框架，针对一个接口有三种实现，分别是try/confirm/cancel。

 这种处理还是会遇到问题的，假如分布式事务事务某阶段某些服务挂掉了，无法进行下去该怎么办呢？这是日志就派上用场了，配置分布式事务日志的持久化策略，譬如通过Longstash输出到es中，也可以直接输出kafka中

设计模式

 装饰模式：

      装饰模式相对于继承有什么优势呢？优势在装饰可以装饰一个抽象类，为所有继承抽象类的类装上蜜糖，而继承只能单一继承

代理模式：

    假如A和B互相不认识，A想向B传达点东西，这是往往需要个代理P帮他完成这件事，A和P都实现同一接口同一个方法，P对象里面包含A对象的引用，通过启用P把B对象在内部传给A，在内部A给B转达消息

 简单工厂和工厂方法：

      简单工厂在工厂内部根据客户端转过来的类型去创建具体产品，然后用该产品获取结果，这种方式添加产品需要改造工厂的内部逻辑，不符合设计的对修改封闭，对扩展开放的原则

      工厂方法定义了抽象工厂，每个不同实现工厂实现特定的类，这种方式每添加一个产品同时需要添加一个工厂，虽然不需要修改原来的代码，但是代码量多

      这两种方法都不是最佳方案，优化方案有待继续看

微服务学习：

    docker-compose 这是一个服务编排的工具，需要下载，然后编写docker-compose.yml 文件 ，定义每个服务，定义容器的网络等，然后启动可以通过scale参数指定特定的服务启动的容器的个数