一、分布式一致性协议

参考链接：https://www.jianshu.com/p/71b2729d3004

两类一致性(操作原子性与副本一致性)

2PC，3PC协议：强调事务，用于保证属于多个数据分片上的操作的原子性。这些数据分片可能分布在不同的服务器上，2PC协议保证多台服务器上的操作要么全部成功，要么全部失败。
Paxos，Raft协议：强调同一条数据的复制，用于保证同一个数据分片的多个副本之间的数据一致性。当这些副本分布到不同的数据中心时，这个需求尤其强烈。

下面讲的是多个副本之间的数据一致性。

分布式系统	分布式一致性协议	选择理由	协议核心功能	备注
TiDB	raft协议（强一致性）	raft协议实现简单	保证数据一致性，完整复制日志到其它节点 leader选举同一时刻只能保证有一个Leader，只有leader可以复制日志	由于raft协议是2013年发布，而TiDB发布于2016年，时间刚好赶上了
ElasticSearch	Gossip			最终一致性消息
Kafka
ZooKeeper	Zab协议
HDFS
HBase	通过HDFS进行数据备份。WAL(Write-ahead logging)			WAL的实现是HLog，HLog也是存储在HDFS上的，所以HRegionServer崩溃了也不会导致HLog的丢失，它也有备份。需要注意的是，HBase Replication 是以 Column Family 为单位，每个CF都可以设置是否进行 Replication。注意：HBase是强一致性的

注意：

1.为什么raft协议是强一致性协议？因为超过半数成功后，认为是提交成功，然后只有这些提交成功的节点才会对外服务，这样就保证了app查到的数据是正确的数据（没有反馈确认的其它节点，即使成功了，也不会对外服务，只有反馈给leader成功，才会对外服务）

2.HBase中的Replication也是基于WAL的，其在主集群的每个RegionServer进程内部起了一个叫做ReplicationSource的线程来负责Replication，同时在备集群的每个RegionServer内部起了一个ReplicationSink的线程来负责接收Replication数据。ReplicationSource记录需要同步的WAL队列，然后不断读取WAL中的内容，同时可以根据Replication的配置做一些过滤，比如是否要复制这个表的数据等，然后通过replicateWALEntry这个Rpc调用来发送给备集群的RegionServer，备集群的ReplicationSink线程则负责将收到的数据转换为put/delete操作，以batch的形式写入到备集群中。

3、提一下Mysql：Mysql是通过异步的方式读取binlog然后存储到slave集群，肯定会导致数据一致性的延时，有时候写入量大可能会延时几小时。

二、分布式系统需要考虑的几个基本问题

分片要尽量均匀的散落在不同的节点，均匀的目的：

负载均衡，避免形成热点；
很重要的隐藏意义，即增加或减少节点，数据会重新进行均衡分配，动态的根据节点分片情况迁移数据（增加的节点刚开始是没有数据的，这样导致各个增加节点数据不均匀，就会触发分片重新分配；其实减少节点也会，因为减少后，可能导致某些主分片或副本丢失，所以要重新拷贝副本，这个过程就会导致数据不均匀，所以也会重新分配）

必须多副本，至少一个，且数据的主分片和副本必须不能在同一个节点上：如果只有一个副本，且主分片和副本在一台机器上，那么这台机器挂掉后，这块数据就会丢失，这违背了分布式系统的设计初衷；
数据的散落方案：一种是按照 Key 做 Hash，根据 Hash 值选择对应的存储节点（ElasticSearch）；另一种是分 Range，某一段连续的 Key 都保存在一个存储节点上（HBase，TiDB）。
节点迁移需要控制速度，避免影响线上服务

三、数据存储原理

分布式系统	概念	备注	其它说明
TiDB		Region
ElasticSearch			分布式存储原理：ElasticSearch - 巍巍的个人页面 - OSCHINA - 中文开源技术交流社区
Kafka	Broker，Partition	Broker：Kafka集群中的一台或多台服务器统称broker. Partition：Topic物理上的分组，一个topic可以分为多个partion,每个partion是一个有序的队列。partion中每条消息都会被分配一个有序的Id(offset)，同一 topic 下的不同分区包含的消息是不同的。
ZooKeeper
HDFS
HBase		Region

四、分布式系统的集群管理工具

分布式系统	集群管理	备注	其它说明
TiDB	PD
ElasticSearch
Kafka	ZooKeeper
ZooKeeper
HDFS
HBase	ZooKeeper	1、管理机器是否可用 2、存储region信息 3、

五、权衡CA之Quorum机制

参考链接：

https://blog.csdn.net/tb3039450/article/details/80249664

https://blog.csdn.net/tb3039450/article/details/80185436

六、MVCC与事务

MVCC即乐观锁的一种实现方式。

乐观锁(MVCC)
何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

几个分布式系统事务的实现机制：

分布式系统	事务	选择理由	协议核心功能	备注
TiDB	TiKV 的事务采用的是 Percolator 模型，总体来说就是一个经过优化的二阶段提交（2PC）的实现
ElasticSearch
Kafka
ZooKeeper
HDFS
HBase

七、分片或region的调度

要设计很好的调度系统，就需要手机足够多的信息，如每个节点的状态；每个分片的状态；节点或分片访问的QPS、吞吐量信息；节点的配置信息，如硬盘，内存等；

总结：几个分布式系统架构设计原理相关推荐

分布式事务架构设计原理
随着业务需求的复杂化,企业应用规模不断扩大,在后端开发中经常会遇到以下问题: 业务的并发要求非常高,对应的业务需要通过微服务拆分,甚至分库分表等架构设计才能满足并发需求,此时业务操作无法在同一个数据库 ...
分布式系统架构设计三十六式之服务治理 - 第一式 - 隔板模式
导读日拱一卒,功不唐捐,分享是最好的学习,一个知识领域里的 "道法术器" 这四个境界需要从微观.中观以及宏观三个角度来把握.微观是实践,中观讲套路,宏观靠领悟.本系列文 ...
分布式系统架构设计36式 – 第0式 - 设计总决
动机在"不易.简易.变易"这三个范畴里,技术是属于"变易"范畴的,其千变万化:"方法论"是属于"简易"范畴的,其具有领 ...
【大型分布式网站】抗住千万流量的大型分布式系统架构设计
一.大型分布式网站架构技术 1.1 大型网站的特点用户多,分布广泛大流量,高并发海量数据,服务高可用安全环境恶劣,易受网络攻击功能多,变更快,频繁发布从小到大,渐进发展以用户为中心免费 ...
美团即时物流的分布式系统架构设计
背景美团外卖已经发展了五年,即时物流探索也经历了3年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设经验.最主要的收获包括两点: 即时物流业务对故障和高延迟的容忍度极低 ...
从Elasticsearch来看分布式系统架构设计，真是666~
欢迎关注方志朋的博客,回复"666"获面试宝典分布式系统类型多,涉及面非常广,不同类型的系统有不同的特点,批量计算和实时计算就差别非常大.这篇文章中,重点会讨论下分布式数据系统的 ...
千万级流量的大型分布式系统架构设计
本文是学习大型分布式网站架构的技术总结.对架构一个高性能.高可用.可伸缩及可扩展的分布式网站进行了概要性描述,并给出一个架构参考.文中一部分为读书笔记,一部分是个人经验总结,对大型分布式网站架构有较好 ...
美团外卖分布式系统架构设计
背景美团外卖已经发展了五年,即时物流探索也经历了3年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设经验.最主要的收获包括两点: 即时物流业务对故障和高延迟的容忍度极低 ...
照抄不翻车：抗住千万流量的大型分布式系统架构设计
作者介绍烂猪皮,十余年工作经验,曾在 Google 等外企工作过几年,精通 Java.分布式架构.微服务架构以及数据库,最近正在研究大数据以及区块链,希望能突破到更高的境界. 本文是学习大型分布式网 ...
深入解读 MySQL 架构设计原理，剖析存储架构选型核心
孙玄,江湖人称"玄姐",前58集团技术委员会主席,前转转二手交易平台首席架构师.今天想跟你聊点儿企业里那些年薪百万的架构师,他们的架构设计思维是如何升级的,以及他们是如何玩转 My ...

总结：几个分布式系统架构设计原理