分布式理论(1)·分布式开始的地方

前言

笔者第一次听说“分布式”时是在大二的时候，当时觉得这个概念听上去很高大上，涉足其中的人肯定都是大神吧。对于分布式，笔者一方面对它的“声名”抱着“敬”的态度，另一方面又对实践它抱着“远之”的态度，原因很简单：畏惧未知。

但凡是有技术追求的程序猿，都应该有不甘于日夜CRUD的心，于是某天笔者开始涉足分布式，辗转数轮的学习后蓦然回首，决定以分布式理论为题，分享一波学习心得。

若非急于投入使用，笔者对每一项技术的学习都要从WWH（What(是啥)、Why(为啥)、How(咋搞)）三方面去入手，了解概念及由来，学习技术理论知识才不枯燥，再了解用途，就能运用到工作中。

本系列文章并未打算从学术、专业的角度来解读分布式这个大家伙，这个系列的写作初衷首先是作为自己的学习记录（因此欢迎读者批评指正、相互交流），然后才是分享笔者的分布式学习心得，且力图在不误人子弟的基础上将复杂的知识简单化，降低后来学习者的学习门槛。

这是系列文章的第一篇，阐述笔者对分布式系统的概念以及为什么要用分布式系统的理解。

分布式系统是什么

分布式系统是一个硬件或软件组件分布在不同的计算机网络上，彼此之间只通过消息传递进行通信和协作的系统。这是分布式系统的学术定义。再者《分布式系统原理与范型》中对分布式系统的定义是：分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统。

如此学术的定义对我们提升学习兴趣可没有帮助，所以我有以下大白话式理解：
所谓的分布式系统，可以理解为一个业务拆分为多个子业务，子业务被分布到不同的服务器节点上，它们共同构成一个完整的系统，这就是分布式系统，与分布式系统相对的是集中式系统。

至此，我相信我的大白话解释对看官们的理解帮助不大，别急，看我娓娓道来。

为什么会有分布式系统

因为以前算得慢

回忆Java IO的学习，写一个读取文件的demo是梦的开始：

创建输入流->读取数据->处理数据->可能还要输出流写出数据

一切顺理成章，非常简单，直到工作后也是这么干的：来一个文件、读一个文件、处理一个文件。

突然有一天，业务要求你要处理几百几千个文件，文件的数量和内容都挺多，你先继续用之前那招，发现逐个处理好慢啊。你就想：一个线程太慢了那我开多个线程呗，于是开始用上了多线程。

开心不过两天，你又发现多线程也不好使啊，还是很慢，于是你说干脆用多进程吧。

再然后很自然地你就发现进程切换成本太高了，高到影响了系统性能，也就是我们痛恨的I/O-Bound问题（关于I/O-Bound可以看看计算的边缘这篇文章，描述得通俗易懂），这时你说那我用多协程总行了吧。

将问题抽象出来看，无论是多线程、多进程还是多协程，本质上做的都是将运算任务并行化的操作，解决的是运算慢的问题。

那么从这个角度来说我们可以得出一个结论：只要任务量足够大，大到一台机器怎么并行化运算都搞不定，那么系统就会崩溃。即一个人无论多能干，分配的任务多到累死他都做不完，那任务就是无法完成。

我们怎么解决这个问题呢？一台机器算不完、算得慢的任务，我多搞几台机器不就好了吗？于是我们用来干活的机器从一台变成了多台，计算并行化升级至计算分布式化。

因为以前存不下

除了解决算得慢的问题，分布式系统还解决了另一个问题。

用户提交了一个数据处理请求，数据总量有1T，我们的集中式系统要处理数据，总得先把数据暂存一份吧，可是我们的系统容量只有500G，怎么办？

OK我们的确可以这么做。

再一次，用户提交了2T的数据处理请求，我们故技重施，解决了当时的问题。

诶？这不是治标不治本吗，数据理论上是无限的，但一台机器再怎么扩容都是有极限的。

所以在一棵树上吊死的思路不通，这是其一。

其二，当我们因为“算得慢”而将计算分布式化后，如果数据只存储在同一台机器，所有机器要访问数据就都要去访问存储着数据的那台机器，可想而知，存储着数据的机器承受着它本不应该承受的压力。

怎么解决呢？当然是把数据也分开存储啦。

这就是存储分布式化了。

总结

1. 因为一台机器运算得慢，所以要将计算任务分开到多台机器运算；
2. 因为一台机器存储不下那么多数据，所以要将数据分开到多台机器存储；

分布式系统的存在就是为了摆脱单机资源的束缚。

引出问题

分布式系统要解决的两大主要问题就是算得慢和存不下，它通过将计算任务和存储内容分散开来解决这两个问题，但具体如何操作？下一篇文章聊一下怎么将待存储的内容分散开来存储。