1、应用场景

同时为发布和订阅提供高吞吐量、消息持久化、分布式功能、支持数据并行加载到Hadoop中

实际：
1、发布系统通知：如评论、点赞、关注这些事件发生后，可以把这些操作放入到kafka消息队列中，如果用户量一大直接操作数据库，服务器压力顶不住。所以把这些通知先存入kafka中，然后一个个消费掉。
2、一些项目数据同步问题也可以用到。
3、监测数据：分布式应用程序生成的统计数据集中聚合。
4、分布式：假设有系统B、C、D都需要系统A的数据
5、事件采集：其中状态的变化根据时间的顺序记录下来，kafka支持这种非常大的存储日志数据的场景。
如：日志收集、消息系统、活动追踪、运营指标、流式处理、热点点赞、评论、关注、发短信。

一、Seata 是什么

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
https://seata.io/zh-cn/docs/overview/what-is-seata.html

二、事务模式

1、什么是分布式锁？

	当多个进程在同一个系统中，用分布式锁控制多个进程对资源的访问。传统的单体应用单机部署情况下，可以使用java并发处理相关的API进行互斥控制。分布式系统后由于多线程，多进程分布在不同机器上，使单机部署情况下的并发控制锁策略失效，为了解决跨JVM互斥机制来控制共享资源的访问，这就是分布式锁的来源；分布式锁应用场景大都是高并发、大流量场景。

2、分布式锁实现

（1）、redis分布式锁的实现

1. 加锁机制：根据hash节点选择一个客户端执行lua脚本

2. 锁互斥机制：再来一个客户端执行同样的lua脚本会提示已经存在锁，然后进入循环一直尝试加锁

3. 可重入机制

4. watch dog自动延期机制

5. 释放锁机制

Disruptor中发布事件相关类

RingBuffer、EventFactory

EventFactory：提供给RingBuffer做事件预填充

Event事件：

1、从生产者到消费者过程中所处理的数据单元；

2、在Disruptor框架中没有类表示Event，因为它完全是由用户定义的，在Disruptor框架中是用泛型表示的；

Disruptor中的等待策略

WaitStrategy

等待策略的接口

BlockingWaitStrategy

disruptor

------高性能的线程间消息传递框架

介绍：

Disruptor类似于java的BlockingQueue。与队列一样，Disruptor的目的是在同一进程内的线程之间传递数据。

但是，Disruptor提供了与队列不同的关键功能：

1、同一个“事件”可以有多个消费者，消费者之间既可以并行处理，也可以相互依赖形成处理的先后次序(形成一个依赖图)

	2000年7月，加州大学伯克利分校的Eric Brewer教授ACM PODC会议上提出CAP猜想。两年后，麻省理工学院的seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认理论。(理论是有时间期限的，没有绝对意义上的公理，是相对于目前计算机科学水平)；

CAP原理概述

  一个分布式系统最多只能同时满足一致性(consistency)、可用性(Availability)、分区容错性(Partition tolerance)的两个

一、需求

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。

当需要将节点之间在不同时间的交互做唯一标识，数据日渐增长，

对数据库的分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求。

此时一个能够生成全局唯一ID的系统是非常必要的。

二、ID生成的原则：

1、全局唯一性：不能出现重复的ID（最基本的要求）

2、高性能，低延迟。（不要太繁杂的算法）

3、易于存储，（占用较低的空间）

三、相对应的算法：