​ 这篇文章会通过在开发中遇到的不同场景来分析缓存的使用方式。

1. TCC事务简介

• TCC事务 即：Try-Confirm-Cancel 。它是基于业务层面的事务定义，把事务运行过程分成 Try、Confirm / Cancel 两个阶段。在每个阶段的逻辑由业务代码控制。每一个初步操作，最终都会被确认或取消。因此，针对一个具体的业务服务，TCC事务机制需要业务系统提供三段业务逻辑：初步操作Try、确认操作Confirm、取消操作Cancel。

• Try 从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑。TCC机制将传统事务机制中的业务逻辑一分为二，拆分后保留的部分即为初步操作（Try）；而分离出的部yfyf分即为确认操作（Confirm），被延迟到事务提交阶段执行。

  • 完成所有业务检查( 一致性 )
  • 预留必须业务资源( 准隔离性 )

• Confirm 是对 Try 操作的一个补充。当TCC事务管理器决定commit全局事务时，就会逐个执行Try操作指定的Confirm操作，将Try未完成的事项最终完成。

• Cancel 是对Try操作的一个回撤。当TCC事务管理器决定rollback全局事务时，就会逐个执行Try操作指定的Cancel操作，将Try操作已完成的事项全部撤回。

一、基础概念

基于生产消费者模式

外部需要传入查询条件和执行方法

现在项目使用了Spring Cloud Config配置中心，下面简单将学习到的记录一下。

为什么要用Spring Cloud Config？

1. 由于在分布式系统中，服务数量巨多，可以方便服务配置文件统一管理
2. 可以实时更新配置
3. 可以与Spring项目无缝集成

Tomcat类加载机制的比较

Tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类(Object,String等)，各个web应用自己的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托。

对于JVM来说：

因此，按照这个过程可以想到，如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class，会优先加载CLASSPATH目录中的文件。

上手前建议先看上一篇blog，了解RabbitMQ基础知识。

具体内容可以查询官网：http://www.rabbitmq.com/

RabbitMQ基础知识详解

新工作又是新的消息队列，和之前用的消息队列又有些区别，之前使用的消息中间件基于JMS，而RabbitMQ基于AMQP。因此需要学习对比下。

一、RabbitMQ的基本概念

1. 队列、生产者、消费者

   队列是RabbitMQ的内部对象，用于存储消息。生产者（下图中的P）生产消息并投递到队列中，消费者（下图中的C）可以从队列中获取消息并消费。

​ 因为接下去工作中RPC框架是使用Dubbo，所以试着用了一下，写了简单的provider和comsumer测试。之前所在公司用的是自研的RPC通信框架，大体上感觉差不多，唯一的区别应该就是服务发现和治理上的，Dubbo使用了zookeeper，等之后的文章再具体分析。