《异步处理在分布式系统中的优化作用》学习笔记

原文地址：http://www.infoq.com/cn/presentations/optimization-of-asynchronous-processing-in-distributed-systems

视频地址：http://v.qq.com/boke/page/l/0/6/l0196plsvp6.html

主讲人：赵海平 Facebook hiphop HHVM 阿里巴巴技术保障部

问题1.进入大数据时代，

用户增多，数据增多带来挑战，上亿的用户，不能一台机器存所以数据，一个计算机更强大，针对一个用户要做的事情也比以前更多，造成数据量的膨胀。

多到再不可能访问一个数据库就可以展示网页，需要访问多个库。



不好的做法，访问数据库1的结果是访问2需要的依赖，只能先访问1再拿1的结果去访问2，最后汇总结果显示出来。



问题：同步等待。

发现有时候1和2其实没有依赖性，这样就无意义的等待。

并行的发送2个数据库去查询比较好，facebook早年就是有这样的代码，几个mysql同时查询，专门的查询函数查询多个查询，只要这些查询之间没有依赖。



这样让代码复杂性，不过不要紧。问题在于人脑思维有局限性，在真实场景有小组，每个小组负责自己的业务，负责查询自己所在的数据库，所有每个组在函数上是一个同步的写法，同步的等待过程，从数据库抓数据，只要调用其函数就需要同步等待，让并行处理变难。

第三方需要调用多个函数都各自做各自的事情，都同步的抓数据，只能先后调用。让并行处理很复杂。facebook就遇到这样的现实问题。

如何把并行在代码层面写的很直观，又在机器层面执行的非常好就是一个艺术。



新的写法-异步写法

我知道需要访问数据库，先不马上访问，把访问数据库的所有条件记录先下来，记录下来的目的是稍微等待看有没有其他地方也需要访问这个或者其他数据库，如果有可以两个一起处理。所有异步写法就不是一个同步的等待。



异步返回的是Future这样一个object而不是结果result。Future可能不同语言叫法不一样，但是目的都是一样就是将所有将来需要访问数据库的信息记录下来，先不去访问它，有不同的Future的object就可以汇总在一起，再执行。

要判断什么样的Future的object可以并行处理，什么样的不能并行处理。可以做调整。



异步写法不再担心函数把异步写法合并，有函数也没事，getresult到最后把Future的object返回给调用者，这个函数可以暂时认为已经结束执行，下一次就无需访问我了，因为我已经告诉你怎么去访问数据库，然后调用者可以去调用其他函数，再调用函数的过程中没有任何的等待过程。调用的人有一个总的调度过程。不同的团队可以写自己的函数，这些函数可以合作。

要求同一个公司都这样写，不然其他调用者对于一个是Future，而另一个是同步进行，调用者就会不知所措，因为返回不同。调用者希望所有的函数给他的都是Future的object。

但是这样阻碍很多的代码转变，fb就经历过这样痛苦的转变，不过异步确实让代码更有效的执行，就开始渐渐在代码中加入异步的调用函数，发现所有调用都要改为Future。



代码第一天开始就用正确的写法以后就不会有这样的问题，facebook局部的把代码变为异步的方法。一旦异步遇到同步就马上去执行异步的数据，把结果再和同步汇总，最后facebook还是把整个网站改为异步写法。每一个函数只要有一个调用远程服务的网络IO的过程就要将其改为异步的。到一个数据库查询先发一个seng请求然后yield，还有另一个操作就是接受Response，把一个同步的等待分为一半一半，一个seng请求和接受Response。

最后发现一个网页形成一棵树，右边最下面2个叶子可以没有任何依赖性都可以到远端调用数据，调用数据都回来了后执行其共同的父节点。然后左边2个叶子没有任何依赖性的执行，每一个节点都是一个Future的object，每个节点2个状态：一个是正在等待执行，还有一个是已经执行了。只有所有的叶子节点执行后才可以开始自己的执行，逐级往上依赖的执行。

一个网页不是马上从后端服务器调用数据，而是组成一个distributed（分布式的）查询，每一个分布式查询可以组成一个依赖性树。



第一个face阶段：总调用者拿到一颗很大的树，这颗树描述数据调用的依赖性。树的每一个node都记录下来怎么调用数据。

第二个face：执行整个树，执行的过程就是所有的底层的叶子可以并行执行，再上面一层，要看执行的速度，有时候某些点快就可以上去的更早，有的点上的稍微晚点执行。无论怎么样，最后的目的是一直往上，顶点也被执行完，这个顶点就是网页的html就被完全准备好了。

发现把PHP变为这样一种语言，不像原来那样一上来就执行，而是一上来先Lazy一下，组成一个query，然后等看清楚完整的query之后再开始执行第二个face。

实例：找出所有朋友中在淘宝买过东西的人。

不能马上得到friends列表会得到一个Future的object，这个Future的object将来会告诉我有哪些朋友。

再yield return getTaoBaoBuyers(friends);需要执行第二个数据调用，是对friends有依赖性的，要知道有哪些friends，然后查这个friend有没有在淘宝购物。



如果是另一个不恰当的例子，在淘宝买保时捷的人可能不会很多就2个人。

第一个例子在淘宝上买过东西的人实际上是狠多的。

在淘宝上买保时捷少的情况下这个查询就出现这样一种问题，是找朋友还是倒过来先查那2个人在淘宝上买过保时捷，再看看这2个人那个是我的朋友？

同一个问题2个方向去解决：可以先查我的朋友，也可以先查这2个人。这2个方向是怎么决定的？

如果第二个问题沿用第一行代码就错了。



应该先查买过保时捷的人！因为第二件事情做得人比较少。

这种情况在传统数据库早就存在，因为存在表连接。在数据库优化上在join的时候会自动做这种优化，看那个表返回的少。innno join从小表这边走。表join方向的问题，传统数据库这样的问题已经被优化，但是写程序就没有做到这一点。

但是fb把网页改为异步，但是fb还没有能够在2个face之间去分析优化查询。

这个问题不仅仅是php中有。任何语言都会遇到要访问多个库的情形，是并行串行？同步异步？的问题。

用同步处理CPU的利用率上不去，用线程去处理并行方案不是最佳方案。线程设的最高300以上以及到了环境的极限。

这个时候需要用很多小小的协程等一些方案做一些小的task.

写代码必须一行行写，但是其实机器可以并行执行代码，这是人脑思维和机器执行的差异。

其实这些并行的优化就是以前数据库做的内部优化的放大。

写第一行代码就已经把表join的方向给静态固化，把哪一个class放memcached里给固化下来。这些都不是一个真正的优化过程。

要的是不要告诉我们表join从哪个方向，也不要告诉我把哪一个class放memcached里给固化，因为写这个的研发人员不知道从系统资源的角度上来说哪个class更值得放入缓存。或者以后业务有整体大的变化，有哪些新的class应该放入缓存，老的class应该从缓存搬走。

所有的这些优化应该是中间的face介于这两者之间组成查询，然后看这个查询在哪儿可以执行，最后经过这样一个优化过程当中再去执行，所有的这些是中间的调度过程中去执行优化过程。

Java和php都没有给我们这样的便利。在fb加了yield return这样的语法实际上非常类似于python的yield return，虽然有yield，但是只是把程序变成2个face。

我们没有办法把这个查询优化为一个更值得优化的一棵树再去执行。

.

只要是分布式系统就要思考怎么用异步来优化。





希望大家把计算机当成科学来看待，以后语言层面已经把异步优化给处理好。