趣谈分布式与集群

单体架构：

家里生小宝宝啦，由于自己没有照顾小宝宝的经验，所以请了位经验丰富的月嫂。
这位月嫂从买菜，到做饭，洗衣，拖地，喂奶，哄睡，洗澡，换纸尿裤，擦屁股，做排气操，夜间陪护，给奶妈做月子餐等等，全部都做。 这种叫做单体架构。

集群：

什么都做，一个月嫂怎么够呢，肯定忙不过来呀，那就请两个月嫂吧，这叫做集群。
高可用：
有一个月嫂过生日，想请假回去和亲戚打一天麻将。如果只有一个月嫂，她走了，就叫做服务中断了。 但是因为做了集群，有两个月嫂，走了一个，另一个还是能用，虽然相比较吃力一些，但是毕竟还是能用的，这个现象叫做高可用。

分布式：

一个月嫂，一个月的费用基本上都要1万多，还有房贷，还有车贷，生活费用还高，实在是请不起两位啊，那就还是请一位吧。 可是事情那么多，她实在忙不过来，怎么办呢？ 那就把爷爷请过来买菜，把奶奶请过来做饭。 这样服务本来仅仅是由月嫂一人提供的，变成了和宝宝相关的由月嫂负责，采购由爷爷负责，餐饮由奶奶负责。 这就叫做分布式了。

低耦合：

做宝宝服务的月嫂去打麻将了，不影响做饭的奶奶。 做采购的爷爷去喝酒了，也不影响月嫂的宝宝服务，这叫做低耦合。
高内聚：
和宝宝相关的事情都是月嫂在做，月嫂兑奶方式快慢，只会影响自己，对爷爷和奶奶的服务没影响. 这叫做高内聚。

集群+分布式：

奶奶一个人做饭，做久了也烦啊，也累啊，也想打麻将呀。 那么就把姥姥也请过来吧。 这样做饭这个服务，就由奶奶和姥姥这个集群来承担啦。她们俩，谁想去汗蒸了，都有另一位继续提供做饭服务。 这就叫做集群+分布式。

分布式和集群都是为了解决两个问题：

• 高吞吐量（throughput）
• 高可用（availability）

那既然他们俩都能解决这两个问题，那择其一为我所用就好啦，可为什么我们的架构通常既是分布式，又是集群呢？这不矛盾了吗？

慢慢看下去一切自然就明了

首先咱们聊聊集群

什么是集群，举个列子就是我开饭店，雇了好多个水平一模一样的厨师，既可以同时帮我做菜（高吞吐量），而且万一有一个厨师回家娶媳妇了，我饭店里还有别的厨师（他们可能会比平时忙），不至于要关门停业（高可用）我们常用的缓存服务器，比如Memcached和Redis，都是集群架构，以Memcached为例，一开始我们只有一个Memcached节点：

Client把一些数据放到Memcached中，省的每次都是数据库查，如果只有一个Memcached，那一旦请求压力大了，Memcached很快就忙不过来（虽然Memcached是多线程），而且一旦Memcached挂了，那就没有缓存可以用了，全部请求都会走数据库，数据库的压力会骤然增加！所以我们加多了两个Memcached节点，形成Memcached集群：

Memcached集群实现了开头提到的两个特性：

高吞吐量：通过负载均衡算法（通常是借助一致性Hash和虚拟节点），我们把Client的请求均匀分配到三台Memcached服务器上，不至于只让一台Memcached疲于处理全部请求。

高可用：一旦一台Memcached节点挂了，比如说Memcached1，那借助一致性Hash算法和它的虚拟节点机制，我们可以将原本发给Client的Memcached1的请求均匀分配到Memcached2和3上，缓存功能依旧可用。

有人说，请求会被分布到各个Memcached节点，这不就是分布式吗？

严格来说，这只能算是“分布的”（distributed），正如Memcached官网的介绍说的：

memcached is a high-performance, distributed memory object caching system

那什么才算是分布式呢？（承上启下，自然而然的引出下面对分布式的介绍，加5分 —— 语文老师评）

还是我开饭店的例子，饭店不能只有厨师啊，总不能让客人来了直接跑到后厨跟厨师说他要吃什么吧？所以还要前台负责接待，要服务员负责送菜，还要收银员负责结账… 这样一个各司其职，最后共同完成一件大事的系统，就形成了分布式。

还是上面那张图，换个角度去看，就是分布式了，之前我们只看到了三台Memcached节点，上面说了，这只是集群，那要怎么看才是分布式呢？把眼睛睁大！看整张图！

为什么说整张图就是分布式了？因为这些节点各司其职，有专门负责数据持久化存储的（Database），有对外提供业务访问的（Client，姑且认为是一个商品查询服务吧），也有负责数据缓存的（Memcached）什么？你说这样还不够分布式？那就这样吧（画的有点ugly…）：

够分布式了吧 (￣▽￣)~*

分布式同样实现了开头提到的两个特性：

高吞吐量：我们把不同业务拆分到不同的机器上，比如用户信息查询和订单信息查询都是非常频繁的业务操作，现在我们拆成了UserService和OrderService，放在不同的机子上运行，自然比都放在一台机器上，吞吐量要高得多。
高可用：我改了一行UserService的代码，部署过去，编译失败，节点挂掉了，最多就影响需要依赖UserService的业务，不会影响其他的，整个系统整体上还是可用的，而如果所有业务都放在一起，那就危险多了！一行代码编译失败，整个系统垮掉，整段垮掉！

可能有同学觉得这样的分布式，和之前提到的Memcached将请求分散给各个节点进行处理，不都一样吗？Memcached集群也是每个节点各司其职，每个节点负责一小部分请求，共同实现缓存这个功能，这不也是分布式吗？

再啰嗦一句你们就清楚了。

我们常说的分布式，或者说分布式（Distribution）这个术语，指的是各个异构的节点形成的系统，所谓异构，就是结构不同、功能不同的节点。

而Memcached集群的各个节点呢？他们是同构的，一个缓存的请求过来，比如说Set xxKey xxValue，那这个请求最终只会被一个Memcached节点处理，不会需要多个节点来共同完成这个请求。

而分布式呢，假设我有一个下单的请求，请求发给了OrderService，OrderService需要根据请求里头的userId补充用户信息，那就需要调用UserService提供的接口，然后我还要查询这比订单里头的商品信息，所以又得去调用GoodService接口，最后，才能完成下单这个操作。

OrderService、UserService和GoodService共同完成了下单这件事，这才是分布式（Distribution），而Memcached集群最多只能算是“分布的”（Distributed）。