如何学习分布式

最近总有一些网友问起这个。首先说这是个很大的问题，大到没人能做到简单的回答。或者说即便回答了也不一定是你想要的。因此讨论组里基本上不会有人理的：）。提问的同学请自行搜索“如何有效提问“等关键字。

另外这个问题又是个已经被答烂的问题，很容易找到各种回答，比如：

• What are some good resources for learning about distributed
  computing? Why?
• 想从事分布式系统，计算，hadoop等方面，需要哪些基础，推荐哪些书籍？
• 分布式系统(Distributed System)资料
• ……

只要能翻墙肯搜＋会一点英文，你能找到无数的文章／资料／系统。

本文不会纠结这些分布式的知识和技能，而是要讨论一下分布式学习本身的问题。

如果你碰巧进入了如Stanford这种级别大学的一个做分布式技术的小组，那么不用纠结了。把你大牛老师和周边同学的知识技能的都搞清楚，并在巨人肩膀上再进那么一小步。当然，你也不用往下看了。

如果你只是个程序员出身，想解决工程问题的普通人，当看到像高山，又像迷雾般的“分布式“，感觉心里痒痒，但又无从下手。只是平时听着各位大牛在微博和微信圈里谈笑风声便心向往之。其实并不奇怪，你和这些大牛们看到的问题完全不同。

比如在一家饭店里，有些人满脑子的问题是“如何做好一道菜？几点钟可以下班？“；而另一些人关心的问题是“现在吃饭的都喜欢吃啥？我有没有厨师能做？如果不能去哪能招到？给多少薪水才划算？“关心第一类问题的人如果没有一个特定机遇或者条件（比如突然自掏腰包变成老板）是很难转换到第二种角色，遇到后一类问题。这样一点错的没有，大多数人是不会没事去操心自己不需要操心的事情。

开发也是如此。一般情况下，一个程序员第一次找到的工作十之八九是解决业务问题，既编写大量类似于“如果XXXXXXX，则XXXXXXX“这样的代码。如果没有某个条件或者自己碰巧喜欢注意这类问题，干个几年都如此也不奇怪。不要说分布式，就连编程语言中稍微高级一点的特性都碰不到。入行3年不需要new一个Thread，不需要定义一个interface的大有人在。没有问题，自然也就不用了解。

想了解分布式，首先要问自己“我什么地方能用到分布式？“或者“分布式能给我带来什么好处？“ 比如：

• 问题1：你的代码太多太杂了，既有前端模版，又有业务逻辑，还有定时业务，还有基础服务；小伙伴经常在系统里引入新的bug，而你总是被各种block？
• 问题2： 系统的流量／数据太大了，已经撑爆了CPU、内存或者带宽

对于问题1，也许你觉得可以将系统拆开，拆成一小份一小份。然后互相调用一下。一般被称为远程过程调用（RPC）或者面向服务架构（SOA）。然而拆是拆开了，带了一坨的后续问题，比如： 调用用什么协议？确定好某个协议后，开发者怎么才能最有效率的利用这个协议？（这里的“效率“既包括开发上的效率，有包括系统本身传输／执行的运行时效率），这就又引发了：

• 因为建立一次连接是有开销的，如何减少连接次数？用连接池？参数怎么配？
• 如何减少跨系统带宽占用？压缩，好吧；如果压缩了CPU又80％则又不压缩？
• 怎么认证？系统之间不能随便乱调用吧。
• 如何隔离？部门A和部门B都想调用部门C的API。部门A说我是公司明星项目，最赚钱，你要保证部门B那边无论出什么问题都不能干扰我……
• 如何监控？单机系统里如果是Java，用ssh登上去直接sar、jstate……。跨系统怎么办？
• 如何调试？一次调用可能会跨n个系统。如果出错了，我怎么知道是谁的错？错误是系统层面上的还是业务逻辑问题？
• ……

再说问题2，再一次将系统拆开。比如把数据库拆开。然后：

• 怎么拆？随便拆？按照某种Hash拆？按照Range拆？让系统自己去想办法拆？wait，确认傻乎乎的系统会“想“办法？
• 拆了之后数据不一致怎么办？
• 拆了之后一部分活着，另一部分死了怎么办？
• 死了一台怎么快速顶上另外一台？
• 拆了之后应用怎么访问这些拆开的数据库？是走透明路线（在客户端看来还是一个数据库）；还是走暴露路线（在客户端看来是多个数据库）？如果是后者客户端怎么访问？
• 如果是SQL数据库，拆了后怎么join？
• 如果用了KV数据库或者块数据库，怎么查询？
• ……

好吧，为了解决一两个问题，就带来了多出一个数量级的问题。很爽，不是吗？老板也许直接就发飙了“我就想让界面上出个东西你怎么搞出这么多事情？？！！“

所以，如果一个系统能够单机搞定，那还是尽量单机搞定，不要招惹“怎么拆“的问题。但如果万不得已必须拆，不拆你的系统就要三天两头挂掉，客户就要用刀砍你。那再多的问题也得拆。但如果招惹的问题太多了，不用客户发飙，自己先累死了。

总结下来就是，要做“分布式“，先搞清楚：

• 为甚么要拆
• 要拆什么那个系统
• 拆了之后会遇到哪些问题
• 这些问题哪些必须不能忍，得有个方案堵上；哪些可以忍？
• 是否有以已经存在的技术，可以帮你？
• 如果用了第三方的技术，它无法满足你的特定需求或者根本就有 bug怎么办？
• …

当你有了明确的答案，就已经学会“分布式“了。

没有绝对意义上的“分布式“的概念。每个用到这个词的人仅仅是借用一下这个词来表示他／她在特定上下文下遇到的特定的问题罢了。想学习“分布式“还是先务实的考虑自己面临的具体问题再有的放矢。一上来就追求大布头经典教材，辩论个“这个属于分布式“，“那个不属于分布式“纯属浪费精力。

另外“分布式“也不是要膜拜的东西，就像有人喜欢《聂隐娘》，有人喜欢《变形金刚》。只能做业务并不值得鄙视，反而业务一直都是推动技术的巨大力量。说到底，技术归根到底要为业务服务。快快的解决问题，省出时间多去和妹子吃吃饭聊聊天才是王道啊。