目录
分布式通信主要研究分布式系统中不同构件（子系统或者进程）之间的信息交换机制：
- 远程过程调用（RPC）
- 消息队列
- 多播通信
一、远程过程调用（RPC）
概念
许多分布式系统是在进程间显式地进行消息交换，RPC即可简化这一通信过程。
RPC允许调用位于网络中其他机器上的进程。
机器A上进程调用机器B上进程时，A上进程被挂起，B上被调用进程开始执行，调用方可以通过参数将信息传递给被调用方，然后通过B上的进程返回的结果得到所需的信息。
RPC就是要像调用本地的函数一样去调用远程函数。
RPC过程中存在哪些新问题？
- 客户端怎么告诉远程机器要调用哪个函数？ 函数指针—>函数ID
- 客户端怎么把参数值传给远程的函数？ 序列化、反序列化
- 数据如何传输？ 网络传输协议
函数 Call ID
在RPC中，所有函数都必须有自己的一个ID。在所有进程中唯一确定。
在客户端和服务端分别维护一个对应表（函数/Call ID）。两个表不用完全相同，但是函数和Call ID对应关系必须相同。
Call ID映射可以时函数字符串，也可以使用整数ID。映射表一般是一个哈希表。
也称为服务寻址，通过服务注册中心实现。调用服务时也通过服务注册中心查询对方服务有哪些实例。
序列化与反序列化
实现高效的数据存取与通信。
属于通讯协议的一部分。
序列化：将数据结构或对象转换成二进制串的过程；
反序列化：将序列化生成的二进制串转换成数据结构或者对象的过程。
Protocol Buffer：一种支持多平台、多语言、可扩展的数据序列化机制。
网络传输协议
网络传输层 需要把Call ID和序列化后的参数字节流传给服务端，再把序列化后的调用结果传回客户端。
可以使用TCP、UDP、HTTP等。
Netty：利用Java的高级网络的能力，隐藏其背后的复杂性而提供一个易于使用的API的网络编程（客户端/服务端）框架；能编程自定义各种协议；能通过codec来编码/解码字节流；基于NIO开发的网络通信框架。
阻塞式IO、非阻塞IO：
RPC框架
RPC框架隐藏下层的具体通信过程，大大简化并透明化了网络间进程调用过程。
RPC框架的核心功能：
- 客户端
- 客户端存根
- 服务端
- 服务端存根
- Network Service
著名的RPC框架：
- gRPC：Google
- Thrift：Facebook
- Dubbo：阿里
二、消息队列
1. 概念
- 分布式系统构建之间通过传递消息可以解除相互之间的功能耦合，减轻子系统之间的依赖。
- 消息队列 是传输消息时保存消息的容器或中间件，主要目的是提供消息路由并保障消息可靠传递。
- 消息中间件常用模式：PTP和Pub-Sub模式
- 常用产品：ActiveMQ、ZeroMQ、RabbitMQ、Kafka。
2. PTP VS Pub-Sub
PTP基于队列，消息生产者将消息送入消息队列，消息消费者从消息队列中读取消息。先进先消费。
Pub-Sub定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题（Topic）。主题是消息的传输中介，发布者发布消息到主题，订阅者从主题订阅消息。
3. 消息队列中间件——RabbitMQ
实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。
RabbitMQ是一个分布式系统，其架构如下：
- broker：每个节点运行的服务程序，功能为维护该节点队列的增删以及转发队列操作请求。
- master queque：每个队列都分为一个主队列和若干个镜像队列。
- mirror queque：镜像队列，作为主队列的备份。在主队列所在节点挂掉之后，系统把镜队列提升为主队列，负责处理客户端队列操作请求。镜队列只做镜像，设计目的不是为了承担客户端读写压力。
4. 队列消息中间件——Kafka
Pub-Sub模式。
具有极高的消息吞吐量，较强的可扩展性和高可用性，低延迟，消息队列可以持久化保存。
支持消息传递的“至少传达一次”语义。
架构：包括消息生产者，代理服务器（Broker），消息消费者。
消息生产者产生指定Topic的消息传到代理服务器集群，Broker集群在磁盘上存储并维护各种Topic的消息队列，订阅了某个Topic的消息消费者从代理服务器集群中拉取（Pull）出i新产生的消息并对其进行处理。
Kafka内部支持对Topic进行数据分片（Partition），每个数据分片有序。
为什么Partition？
- 将日志内容分散到多个server上，避免文件尺寸达到单机磁盘的上限。
- 可以将一个topic切分任意个partitions，来提升消息保存/消费效率。
- 越多的partitions意味着可以容纳更多的consumer，有效提升并发消费的能力。
Kafka相较RabbitMQ，把一个队列的单一master变成多个master，且彼此之间数据没有交集。
每个master queue在Kafka中叫做Partition（分片），每个分片有多个副本。
Kafka通过消息副本机制提供了高可用的消息服务，其副本管理单位是Partition。（partition的副本个数可以在配置文件中指定）。
主副本（Leader），次级副本（Slave）。
所有针对这个Partition的消息读/写请求都由主副本来负责响应，次级副本只以主副本数据消费者的方式从主副本同步数据。
Kafka是一个基于文件系统的消息系统，对于基于此盘操作的消息系统如何保证系统性能？
原则：尽可能避免随机读写，尽可能利用顺序读写，即连续读写整块数据。
Kafka能够高效处理大批量消息的一个重要原因：将读写操作尽可能转换为顺序读写。
三、应用层多播通信
多播通信：将数据通知到网络中的多个接收方。
- 点对点 1 to 1
- 广播 1 to n
- 多播 1 to k
应用层多播通信：分布式应用系统内各个节点组织称一定的结构，在此结构上实现多接收方的通信。
GOSSIP协议
1. Gossip
- 用于实现分布式节点或者进程之间的信息交换。
- 同时满足应用层多播通信所要求的低负载，高可靠性和可扩展性的要求。
- 利用一种随机的方式将信息散播到整个网络。工作流程类似于绯闻、流行病的传播。
- 基本思想：一些节点周期性地随机选择N（扇出，fanout）个节点进行信息传递；接下来这些节点做同样的事。
2. Gossip执行过程
- 种子节点周期性的散播消息。
- 被感染节点随机选择N个邻接节点散播消息。
- 节点只接受消息不反馈结果。
- 每次散播都选择未发送过的节点进行散播。
- A->B，B->A不再发生。
3. Gossip通信方式
- Push：节点A将数据（key，value，version）推送给B，B更新A中比自己新的数据。
- Pull：A仅将数据（key，version）推送给B，B将比A新的数据（key，value，version）推送给A，A更新本地。
- Push/Pull：Pull的基础上，A再将本地比B新的数据推送给B，B更新本地。
4. Gossip消息类型
1. Anti-Entropy（反熵传播）：
- 以固定概率传播所有数据。
- 参与节点只有两种状态：Suspective（病原）、Infective（感染）。
- 这种节点状态又叫做simple epidemics（SI model）。
- 过程是种子节点会把所有的数据都跟其他节点共享，以便消除节点之间数据的任何不一致。
- 它可以保证最终、完全的一致。
- 缺点是消息数量非常庞大，且无限制。
- 通常只用于新加入节点的数据初始化
2. Rumor-Mongering（谣言传播）
- 以固定概率仅传播新到达的数据。
- 参与节点有三种状态：Suspective（病原）、Infective（感染），Removed（愈除）。
- 这种节点状态又叫做complex epidemics（SIR model）。
- 过程是消息只包含最新update，谣言消息在某个时间点之后会被标记为removed，并且不再被传播。
- 缺点是系统有一定的概率会不一致。
- 通常用于节点间数据增量同步。
5. Gossip协议的优势
- 扩展性：允许节点增删。传播过程中并不需要等待确认（ack）。
- 容错性：一种去中心化的对等结构。任何节点的重启或者宕机都不会影响。某条消息丢失不需要补偿措施。
- 最终一致性：在有限的时间内能够做到所有节点都拥有最新的数据。仅需要O(log(N))个回合。
481
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
