• 中断(Interrupt)
  • interrupt()

中断(Interrupt)

interrupt()

interrupt() 用于中断线程。调用该方法的线程的状态为将被置为”中断”状态,并不会立即执行中断操作.

具体而言，这个方法只会给线程设置一个为true的中断标志（中断标志只是一个布尔类型的变量），而设置之后，则根据线程当前的状态进行不同的后续操作。

如果，线程的当前状态处于非阻塞状态，那么仅仅是线程的中断标志被修改为true而已；

• LockSupport

LockSupport

LockSupport是用来创建锁和其他同步类的基本线程阻塞原语。 LockSupport中的park() 和 unpark() 的作用分别是阻塞线程和解除阻塞线程，而且park()和unpark()不会遇到“Thread.suspend 和 Thread.resume所可能引发的死锁”问题。 因为park() 和 unpark()有许可的存在；调用 park() 的线程和另一个试图将其 unpark() 的线程之间的竞争将保持活性。

• 理论
  • ACID

理论

ACID

传统数据库常用的设计理念，追求强一致性模型

1. 原子性（Atomicity）

   所有的系统都受惠于原子性操作。当我们考虑可用性的时候，没有理由去改变分区两侧操作的原子性。而且满足ACID定义的、高抽象层次的原子操作，实际上会简化分区恢复。

• 理论
  • ACID

理论

ACID

传统数据库常用的设计理念，追求强一致性模型

1. 原子性（Atomicity）

   所有的系统都受惠于原子性操作。当我们考虑可用性的时候，没有理由去改变分区两侧操作的原子性。而且满足ACID定义的、高抽象层次的原子操作，实际上会简化分区恢复。

2. 一致性（Consistency）

   ACID的C指的是事务不能破坏任何数据库规则，如键的唯一性。与之相比，CAP的C仅指单一副本这个意义上的一致性，因此只是ACID一致性约束的一个严格的子集。ACID一致性不可能在分区过程中保持，因此分区恢复时需要重建ACID一致性。推而广之，分区期间也许不可能维持某些不变性约束，所以有必要仔细考虑哪些操作应该禁止，分区后又如何恢复这些不变性约束。

• 环境

环境

• jdk 1.8
• 数据库(使用默认h2)
• redis
• rabbitmq
• maven
• spring cloud dataflow

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-dataflow-dependencies</artifactId>
    <version>1.2.3.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-task-dependencies</artifactId>
    <version>1.2.1.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

• 刷新机制

刷新机制

1. application id
   • 类ContextIdApplicationContextInitializer定义了具体的id格式
   • 默认为<spring.application.name>.<active profiles>.<server.port>
   • 该id将作为刷新时的destination使用(eg. /bus/refresh?destination=customers:dev:9000).
   • 事件origin id为实例application id, destination id支持匹配模式,也是与application id 匹配

• 绑定器

绑定器

通过定义绑定器作为中间层，实现了应用程序与消息中间件细节之间的隔离。通过向应用程序暴露统一的Channel通过，是的应用程序不需要再考虑各种不同的消息中间件的实现。当需要升级消息中间件，或者是更换其他消息中间件产品时，我们需要做的就是更换对应的Binder绑定器而不需要修改任何应用逻辑 。

目前只提供了RabbitMQ和Kafka的Binder实现

• 路由(Exchange)
  • Direct
  • Headers
  • Fanout

路由(Exchange)

Direct

Direct类型exchange的路由算法是很简单的：要想一个消息能到达这个队列，需要binding key和routing key正好能匹配得上。

Headers

通过添加属性key-value匹配

Fanout

将消息分发到所有的绑定队列，无routingkey的概念

• 消费者组

消费者组

消息模型可以分为两种， 队列和发布-订阅式。

• 队列方式: 一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。
• 发布-订阅 消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。

Kafka为这两种模型提供了单一的消费者抽象模型： 消费者组 （consumer group）。

一个发布在Topic上消息被分发给此消费者组中的一个消费者。 假如所有的消费者都在一个组中，那么这就变成了队列模型。 假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。 更通用的， 我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者， 一个组内多个消费者可以用来扩展性能和容错。