每台主机都需要安装jdk 本文版本jdk-1.8.0_231

需要搭建好的zookeeper集群

本文zookeeper环境：192.168.2.112:2181,192.168.2.113:2181,192.168.2.114:2181

本文将Kafka搭建在部署zookeeper集群的三台主机上，当然也可以另外准备三台主机。

在每台主机上执行下面步骤：

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

#将安装包移到/usr/local目录下
mv kafka_2.11-2.0.0 .tgz /usr/local
#解压文件
tar -zxvf kafka_2.11-2.0.0 .tgz
#重命名文件夹为kafka
mv kafka_2.11-2.0.0 kafka
#配置kafka环境变量，首先打开profile文件
vim /etc/profile
#进入编辑模式，在文件末尾添加kafka环境变量
export KAFKA_HOME=/usr/local/apache/kafka
PATH=${KAFKA_HOME}/bin:$PATH
#保存文件后，让该环境变量生效
source /etc/profile

1. 消息队列通信的模式

通过上面的例子我们引出了消息中间件，并且介绍了消息队列出现后的好处，这里就需要介绍消息队列通信的两种模式了：

1.1 点对点模式

如图所示

点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动的去拉取消息进行消费。点对点模型的的优点是消费者拉取消息的频率可以由自己控制。但是消息队列是否有消息需要消费，在消费者端无法感知，所以在消费者端需要额外的线程去监控。

1.2 发布订阅模式

如图所示

nio过程：

channel注册到selector的时候会指定该通道需要selector监听的事件类型

发送程序使用channel向fd中写入数据，完成之后fd会产生一个写就绪的事件，

selector轮询的时候会发现到该事件，并将该事件对应的通道取出来进行处理（将fd中的数据通过socket进行发送）

接收程序将channel注册到selector时会指定监听读就绪事件，

Zookeeper的每一个节点，都是一个天然的顺序发号器。

在一个节点下面创建子节点时，只要选择的创建类型是有序（EPHEMERAL_SEQUENTIAL 临时有序或者PERSISTENT_SEQUENTIAL 永久有序）类型，那新的子节点后面，会加上一个次序编号，这个次序编号，是上一个生成的次序编号加1
。

其次，Zookeeper节点的递增性，可以规定节点编号最小的那个获得锁。

一个zookeeper分布式锁，首先需要创建一个父节点，尽量是持久节点（PERSISTENT类型），然后每个要获得锁的线程都会在这个节点下创建个临时顺序节点，由于序号的递增性，可以规定排号最小的那个获得锁。所以，每个线程在尝试占用锁之前，首先判断自己是排号是不是当前最小，如果是，则获取锁。

第三，Zookeeper的节点监听机制，可以保障占有锁的方式有序而且高效。

同步、异步，阻塞、非阻塞，这四种状态常分不清，主要是这四种状态的定义本身也不是很明确，所以各种解答的方式都有。常见的分类有以下:

• 同步阻塞IO — BIO (java.io）
• 同步非阻塞IO —NIO（java.nio）
• 异步非阻塞IO —AIO (java.nio)

1、基本流程

AT就是把每个数据库当做一个 Resource，在本地事务提交时会去注册一个分支事务。

那么对应到 TCC 模式里，也是一样的，Seata 框架把每组 TCC 接口当做一个 Resource，称为 TCC Resource。这套 TCC 接口可以是 RPC，也以是服务内 JVM 调用。在业务启动时，Seata 框架会自动扫描识别到 TCC 接口的调用方和发布方。如果是 RPC 的话，就是 sofa:reference、sofa:service、dubbo:reference、dubbo:service 等。

扫描到 TCC 接口的调用方和发布方之后，如果是发布方，会在业务启动时向 TC 注册 TCC Resource，与 DataSource Resource 一样，每个资源也会带有一个资源 ID。

如果是调用方，Seata 框架会给调用方加上切面，与 AT 模式一样，在运行时，该切面会拦截所有对 TCC 接口的调用。每调用一次 Try 接口，切面会先向 TC 注册一个分支事务，然后才去执行原来的 RPC 调用。当请求链路调用完成后，TC 通过分支事务的资源 ID 回调到正确的参与者去执行对应 TCC 资源的 Confirm 或 Cancel 方法。

原理图如下：

1. 配置开机自启

把zookeeper做成服务

1、进入到/etc/rc.d/init.d目录下，新建一个zookeeper脚本

1
2
3
4

[root@node1 ~]# cd /etc/rc.d/init.d/ 
[root@node1 init.d]# pwd 
/etc/rc.d/init.d 
[root@node1 init.d]# touch zookeeper

2、给脚本添加执行权限

1

[root@node1 init.d]# chmod +x zookeeper

分布式一致性问题：

1. 什么是 ZooKeeper

1.1 ZooKeeper 的由来

下面这段内容摘自《从Paxos到Zookeeper 》第四章第一节的某段内容，推荐大家阅读：

Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。

关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家RaghuRamakrishnan开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好要用来进行分布式环境的协调一一于是，Zookeeper的名字也就由此诞生了。

Dubbo是以URL驱动的框架，因此本片将跟踪URL的传递以及处理来分析整个服务订阅的流程

消费者在createProxy()方法中，创建了第一个url

URL-1

1

registry://localhost:9090/org.apache.dubbo.registry.RegistryService?application=consumer-test&dubbo=2.0.2&pid=10181&qos.enable=false&registry=spring-cloud&release=2.7.6&timestamp=1610009175272

接着，在上面url上接了一个refer属性：

1、设计思想

要实现服务消费，需要考虑以下问题：

• 生成远程服务的代理
• 获得目标服务的url地址
• 实现远程通信