1.分布式的特性
- 分布式之间的协调动作是通过消息（异步消息）机制完成的；
- 分布式适合计算松散数据，非结构化或半结构化数据；
2. 分布式的构成
数据存储API(node . js)，
RDBMS(关系数据库管理系统)，
系统内部使用(PostgreSQL)以及操作系统和终端用户应用程序依赖于的键/值系统。
3. 分布式的物理因素
分布式系统由两个物理因素的限制：
节点的数量（能够增加所需的存储和计算能力）
节点之间的距离（信息的传送距离，最好以光速）
这两个约束导致下面值得挑战的情况发生：
独立节点随着数目的增加发生故障的概率增加（减少可用的和管理成本增加）
独立节点随着数目增加可能会增加节点之间的通信的消耗（随着规模的增大性能降低）
地理距离的增加提高遥远的节点之间的通信延迟（减少某些操作的性能）
4. 分布式的模型
构建面向服务架构的第一步是确定每个函数功能如何构成整体业务目标，将这些业务映射到离散的服务，且具有独立的断层边界、扩展性和数据负载量。确定为每个服务时，您必须考虑下列事项：
地理. 系统是全球还是地区单独运行？
数据隔离. 这个系统提供一个单个或多租户模型？
SLAs. 可用性 延迟 吞吐量 一致性和冗余性都必须定义。
安全. IAAA (身份identity, 验证authentication, 授权authorization, 和 审核audit), 数据的保密性和隐私性都必须考虑
可用性跟踪. 了解系统的使用是每天系统的日常运作，如容量规划。也可能用于执行计费系统的使用和/或治理(配额/速度限制)。
部署和配置管理. 系统是如何部署更新?
5. 分布式系统遵循CAP定律
几类分布式任务分发的模式
- hash方式： 应用hash运算，映射到不同的机器节点。
缺点： 分布不均匀、拓展困难。 - 按数据范围分布： 根据ID，平均分配任务到各个节点上。
缺点：单个节点可能会导致性能瓶颈。 - 按照数据量分布： 将数据视为一个顺序增长的文件，并且讲文件按照较为固定的大小划分为若干数据块，不同的数据块分不到不同的服务器上。
缺点：需要记录数据块的分布情况。 - 一致性hash：构建hash闭环。
缺点：构建复杂、增加服务器会变动附近节点。
- 构建映射元数据，建立映射表。
缺点：需要维护映射表。 - 副本与数据分布，把一个数据副本分散到多台服务器上。
几个说法
1.心跳检测默认是不可靠。
机器A ------- 机器Q
机器Q发起请求，机器A收到请求，但是A发送响应的时候发生网络阻塞。
机器Q认为机器A宕机。
- 异步网络默认是不可靠的。
FLP原理：在一个异步系统中我们不可能确切的知道任何一台主机是否死机了，因为我们无法分清楚主机或网络的性能减慢与主机死机的区别，也就是说我们无法可靠地侦测到失败错误。
两种系统范式
master-slave
pub-subHadoop可安装模式
独立模式：
伪分布模式：
分布式模式：
（守护进程nameNode， jobTracker，secondaryNameNode）
（其他守护dateNode，taskTracker）
Celery 的模块架构较为简洁，但是提供了较为完整的功能：
任务生产者 (task producer)
任务生产者 (task producer) 负责产生计算任务，交给任务队列去处理。在 Celery 里，一段独立的 Python 代码、一段嵌入在 Django Web 服务里的一段请求处理逻辑，只要是调用了 Celery 提供的 API，产生任务并交给任务队列处理的，我们都可以称之为任务生产者。
任务调度器 (celery beat)
Celery beat 是一个任务调度器，它以独立进程的形式存在。Celery beat 进程会读取配置文件的内容，周期性地将执行任务的请求发送给任务队列。Celery beat 是 Celery 系统自带的任务生产者。系统管理员可以选择关闭或者开启 Celery beat。同时在一个 Celery 系统中，只能存在一个 Celery beat 调度器。
任务代理 (broker)
任务代理方负责接受任务生产者发送过来的任务处理消息，存进队列之后再进行调度，分发给任务消费方 (celery worker)。因为任务处理是基于 message(消息) 的，所以我们一般选择 RabbitMQ、Redis 等消息队列或者数据库作为 Celery 的 message broker。
任务消费方 (celery worker)
Celery worker 就是执行任务的一方，它负责接收任务处理中间方发来的任务处理请求，完成这些任务，并且返回任务处理的结果。Celery worker 对应的就是操作系统中的一个进程。Celery 支持分布式部署和横向扩展，我们可以在多个节点增加 Celery worker 的数量来增加系统的高可用性。在分布式系统中，我们也可以在不同节点上分配执行不同任务的 Celery worker 来达到模块化的目的。
结果保存
Celery 支持任务处理完后将状态信息和结果的保存，以供查询。Celery 内置支持 rpc, Django ORM，Redis，RabbitMQ 等方式来保存任务处理后的状态信息。
通俗的讲rpc是什么？
rpc 一般俗称，远程过程调用，把本地的函数，放到远端去调用。
通常我们调用一个方法，譬如: sumadd(10, 20)，sumadd方法的具体实现要么是用户自己定义，要么存在于该语言的库函数中，也就说在sumadd方法的代码实现在本地，它是一个本地调用！
“远程调用”意思就是：被调用方法的具体实现不在程序运行本地，而是在别的某个地方（分布到各个服务器），但是用起来像是在本地。
rpc远程调用原理 :
比如 A调用B提供的remoteAdd方法：
首先A与B之间建立一个TCP连接；
然后A把需要调用的方法名（这里是remoteAdd）以及方法参数（10， 20）序列化成字节流发送出去；
B接受A发送过来的字节流，然后反序列化得到目标方法名，方法参数，接着执行相应的方法调用（可能是localAdd）并把结果30返回；
A接受远程调用结果,然后do()。
