【分布式】目录大纲

分布式架构

分布式系统产生的原因：

• 高可用：防止单点故障引起系统的不可用。
• 高性能：通过负载均衡，提升整体系统的性能和负载能力

分布式一致性问题：
分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致的情况。通俗一句话，就是主从一致。

如何保证一致性（解决方案思路）
弱一致性，强一致性，最终一致性。具体可以参考这里

分布式架构的知识点
分布式系统的特点：可以不同机柜，不同机房，不同城市。
但是必须满足如下特点：

• 分布性
  分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。
• 对等性
  没有主从之分，没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有节点都是对等的。副本是分布式系统最常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。
• 并发性
  并发共享资源，如何高效协调分布式并发操作是最大的挑战
• 缺乏全局时钟
• 故障总会发生

分布式环境的各种问题

• 通信异常：受制因素有网络光纤，路由器，DNS硬件设备或是系统不可用，网络延时，网络抖动。
  单机内存访问延时纳米数量级通常10ns,网络通信的延迟在0.1 ~ 1ms。相当于内存访问延时的105 ~106倍。
  导致的结果：消息丢失和消息延迟。
• 网络分区
  当网络异常，可能分布式系统中只有部分节点能正常通信，而另一些节点则不能，我们称这个现象为网络分区，俗称“脑裂”。
• 三态
  成功、失败与超时。
  超时通常由如下两种情况：

• 网络原因、该请求并没有被成功的发送到接收方，而是在发送过程就发生了消息丢失现象。
• 该请求成功的被接收放接收后，并进行了处理，但是在响应反馈给发送方的过程中，发生了丢失现象。

• 节点故障
  服务器节点发生宕机或者僵死现象。而且每个节点都有可能会出现故障，每天都在发生。

从ACID->CAP/BASE，具体参考这里

Paxos的工程实践

Google Chubby
提供分布式锁服务，底层实现以Paxos算法为基础。
GFS（Google File System ）谷歌文件系统使用Chubby锁服务来实现对GFS Master服务器选举。
为什么设计为分布式锁服务而不是算法库？

• 对上层应用程序的侵入性更小
• 便于提供数据的发布与订阅
• 开发人员对基于锁的接口更为熟悉
• 更便捷的构建更为可靠的服务

Chubby的设计需求：

• 提供一个完整的、独立的分布式锁服务，而非仅仅是一个一致性协议的客户端库
• 提供粗粒度的锁服务
• 提供锁服务的同时提供对小文件的读写功能
• 高可用、高可靠
• 提供事件通知机制
  具体深入研究内容，面试以后再补充

Hypertable
C++语言开发的开源高性能，可伸缩的数据库，以Google的BigTable相关论文为基础指导，采取Hbase类似的分布式模型，目的是构建一个针对分布式海量数据的高并发数据库。支持CRUD操作但是事务和关联查询不支持。其他与habse类似。

Zookeeper与Paxos

一致性协议

2PC与3PC

分布式一致性算法

paxos算法、raft算法、zab算法、nwr算法、Gossip，一致性哈希

• paxos算法
• Raft 算法
• zab算法
• NWR算法
• Gossip算法
• 一致性Hash
  raft协议和zab协议区别
  

分布式缓存

最后

以上就是俭朴超短裙为你收集整理的【分布式】目录大纲的全部内容，希望文章能够帮你解决【分布式】目录大纲所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。