分布式架构基本思想汇总（思惟方式）

在互联网大行其道的今天，各类分布式系统已经司空见惯。搜索引擎、电商网站、微博、微信、O2O平台。。凡是涉及到大规模用户、高并发访问的，无一不是分布式。

关于分布式系统，并无一个标准答案，说某某架构必定是最好的。不一样的业务形态所面对的挑战不同，使用的架构设计也不同，一般都须要具体业务具体分析。

但无论那种业务，无论何种分布式系统，有一些基本的思想仍是相通的。本文将对这些基本思想进行一个梳理汇总。

分拆

系统分拆

微信的架构师说过一句话：“大系统小作“。对于一个大的复杂系统，首先想到的就是对其分拆，拆成多个子系统。每一个子系统本身的存储/Service/接口层，各个子系统独立开发、测试、部署、运维。

从团队管理角度讲，也能够不一样团队用本身熟悉的语言体系，团队之间基于接口进行协做，职责清晰，各司其职。

子系统分拆

拆成子系统以后，子系统内部又能够分层，分模块。固然，这里“系统“，“子系统“，“层“，“模块“ 都只是一个相对概念。在一个系统里面，某个模块复杂到必定程度，会把它抽出来，单独作成一个系统；而在初期，很大简单模块，可能不回拆分，集中在一个系统里面。

这就像一个生物组织，自身是在不断成长、演化、有分有合，不断变化发展的。

存储分拆

Nosql：对于Nosql数据库，好比MongoDB，其天生就是分布式的，很容易实现数据的分片。

Mysql: 对于Mysql，或者其它关系型数据库，就会设计到分库分表。而分库分表，就会涉及到几个关键性的问题：切分维度，join的处理，分布式事务

计算分拆

计算的分拆有2种思路：

数据分拆：一个大的数据集，拆分红多个小的数据集，并行计算。

好比大规模数据归并排序

任务分拆：把一个长的任务，拆分红几个环节，各个环节并行计算。

Java中多线程的Fork/Join框架，Hadoop中的Map/Reduce，都是计算分拆的典型框架。其思路都是类似的，先分拆计算，再合并结果。

再好比分布式的搜索引擎中，数据分拆，分别建索引，查询结果再合并。

并发

最多见的就是多线程，尽量提升程序的并发度。

好比屡次rpc顺序调用，经过异步rpc转化为并发调用；

好比数据分片，你的一个Job要扫描全表，跑几个小时，数据分片，用多线程，性能会加快好几倍。

缓存

缓存你们都不陌生，遇到性能问题，你们首先想到的就是缓存。关于缓存，一个关键点就是：缓存的粒度问题。

好比Tweet的架构，缓存的粒度从小到大，有Row Cache, Vector Cache, Fragment Cache, Page Cache。

粒度越小，重用性越好，但查询须要屡次，须要数据拼装；

粒度越大，越容易会失效，任何一个小的地方改动，均可能形成缓存的失效。

在线计算 vs. 离线计算 / 同步 vs. 异步

在实际的业务需求中，并非全部须要都须要彻底实时的：

好比内部针对产品、运营开发的各类报表查询、分析系统；

好比微博的传播，我发了一个微博，个人粉丝延迟几秒才看到，这是能够接受的，由于他并不会注意到晚了几秒；

好比搜索引擎的索引，我发了一篇博客，可能几分钟以后，才会被搜索引擎索引到；

好比支付宝转账、提现，也并不是这边转出以后，对方当即收到；

。。。

这类例子不少。这种“非实时也能够接受“的场景，就为架构的设计赢得了充分的回旋余地。

由于非实时，咱们就能够作异步，好比使用消息队列，好比使用后台的Job，周期性处理某类任务；

也由于非实时，咱们能够作读写分离，读和写不是彻底同步，好比Mysql的Master-Slave。

全量 ＋ 增量

全量/增量其实也是在线/离线的思路：

好比搜索引擎的全量索引 ＋ 增量索引，前者是为了吞吐，后者为了实时；

好比OceanBase数据库，每次更新存在一个小表里面，按期merge；

Push vs. Pull

在全部分布式系统中，都涉及到一个基本问题：节点之间（或者2个子系统之间）的状态通知。好比一个节点状态变动了，要通知另一个节点，都有2种策略：

Push: 节点A状态变了， push给节点B

Pull: 也就是轮询。节点B周期性的去询问节点A的状态。

这个问题不光出如今分布式系统中，能够说是编写代码的一个基本问题。对应到面向对象的编程中，也就是常说的“双向关联”这种耦合问题。

A调用B，B再回调A，这种情形，在系统开发中常常出现。再复杂一点，多个模块之间，彼此调用，调用关系跟蜘蛛网同样。

这个问题的出现，就和Push/Pull的策略密切相关：

A调用B，那逻辑就会写在B这边；B调用A，逻辑就会写在A这边。因此是采用主动调用的pull方式，仍是回调的push方式，会严重影响职责在各个模块或者子系统里面的分配。

批量

批量其实也是在线/离线的一种思想，把实时问题，转化为一个批量处理的问题，从而下降对系统吞吐量的压力

好比Kafka中的批量发消息；

好比广告扣费系统中，把屡次点击累积在一块儿扣费；

。。

重写轻读 vs 重读轻写

重写轻读，本质就是“空间换时间“。你不是计算起来耗时，延迟高吗，那我能够提早计算，而后存储起来。取的时候，直接去取。

咱们一般对Mysql的用法，都是重读轻写，写的时候，简单；查的时候，作复杂的join计算，返回结果。这样作的好处是容易作到数据的强一致性，不会由于字段冗余，形成数据的不一致。可是性能可能就是问题。

而微博的Feeds架构，就是典型的重写轻读。我要去看Feeds，按一般的mysql的作法，我要先去查我关注的全部的人，而后把全部人的消息排序，分页返回。很显然，在大数据量下，这个会很耗时。

而若是采用重写轻读，怎么作呢？你不是要看Feeds吗，那就为每一个人准备一个Feeds，或者说收件箱。某我的发了微博以后，把他的微博扩散到全部人的收件箱，这个扩散是异步的，在后台扩散。这样每一个人看本身的Feeds的时候，直接去本身的收件箱取就能够了。

读写分离

一样，对传统的单机Mysql数据库，读和写是彻底同步的。写进去的内容，立马就能够读到。

但在不少业务场景下，读和写并不须要彻底同步。这个时候，就能够分开存储，写到一个地方，再异步的同步到另外一个地方。这样就能够实现读写分离。

好比Mysql的Master/Slave就是个典型，Slave上面的数据并非和Master实时同步的；

再好比各类报表分析，OLTP/OLAP，线上/线下数据分离，线上数据按期同步到Hive集群，再作分析。

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加Java进阶群：582505643，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

动静分离

动静分离的典型例子就是网站的前端，动态的页面，放在web服务器上；静态的css/jss/img，直接放到CDN上，这样既提升性能，也极大的下降服务器压力。

按照这个思路，不少大型网站都致力于动态内容的静态化，静态化以后，就能够很容易的缓存。

冷热分离

好比按期把mysql中的历史数据，同步到hive

限流

如今不少电商都会有秒杀活动，秒杀的一个特色就是商品不多，但短期内流量暴增，服务器彻底处理不了这么多请求。

应对这类问题的一个基本思路就是限流，既然处理不了那么多请求，既然很大人进去了，也是抢不到的。那索性不要放那么多人进去。

这个和咱们平常生活中，节假日，某个景点人数过多，限制人流量是一样的道理。

服务熔断与降级

服务降级是系统的最后一道保险。在一个复杂系统内部，一个系统每每会调用其它很大系统的服务。在大流量的状况下，咱们可能会在保证主流程能正常工做的状况下，对其它服务作降级。

所谓降级，也就是当某个服务不可用时，干脆就别让其提供服务了，直接返回一个缺省的结果。虽然这个服务不可用，但它不至于让整个主流程瘫痪，这就能够最大限度的保证核心系统可用。

CAP理论

上面讲的各类思想，用一个更大的思想来归纳的话，就是CAP。

Consistency：数据一致性，这个很容易理解，就是没有脏数据。咱们知道，在Mysql中有一致性的概念，好比参照完整性约束、事务等。但这里的C主要特指同1份数据的多个备份之间的一致性。

Availability：可用性有2重意思，一个是说稳定性，服务可用，不会挂；另一个是性能，也就是要快，若是延迟很高，常常超时，那和挂了也就区别不大了。

Partition tolerance(分区容错性)：分区，其实指网络分区。当你把数据从1个物理设备，分到多个物理设备以后，设备之间必然是经过网络进行通讯。这就会遇到网络分区，也就是典型的“2将军问题“，网络超时时间不定。学术上有个词，叫“异步通讯环境“。

之前说CAP理论，说对于一个分布式系统，上面3个，只能同时知足2个。但这个其实不许确，P其实必定存在，是你避免不了的。能作的，其实主要是在C和A之间权衡。

好比拿Mysql来讲，它的C最强，A次之，P最弱。若是你为了A，给数据作冗余，好比重写轻读，那C就很难保证；为了P，给数据作分库分表，那就作不了事务；

好比Nosql，P最强，能够很好的作数据拆分，但C就不够，作不了事务；

好比微博系统，对C的要求下降，就能够加不少缓存，提升A；数据分片，提升P；

而支付，交易转账，对C的要求很高，就不能简单的用Cache来提升性能

最终一致性

前面提到，在分布式系统中，由于数据的分拆，服务的分拆，强一致性就很难保证。这个时候，用的最多的就是“最终一致性“。

强一致性，弱一致性，最终一致性，是一致性的几个不一样的等级。在传统的关系型数据库中，经过事务来保证强一致性。

但在分布式系统中，一般都会把强一致性折中成最终一致性，从而变相的解决分布式事务问题。

典型的转账的例子，A给B转账1万块钱，A的帐号扣1万，B的帐号加1万。但这2步未必须要同时发生, A的扣完以后，B的帐号上面未必立马就有，但只要保证B最终能够收到就能够了。

最终一致性的实现，一般都须要一个高可靠的消息队列。关于这个，网上有各类分享文章，后续也会对这个问题单独阐述。

分享一下新一波资料，都是本身在各个平台上找到而后集合到一块儿的。