浅谈dispatcher层------内附详图

       假设如下是一个写数据流程， 从用户那里过来的数据， 经接入层到了逻辑层， 然后到了存储层， 然后就往数据库中写数据了， 然后把写的结果逐步逆向返回给用户：

       大家可以看看， 这里可能有什么问题？ 这个写操作经常是一个比较重的操作， 用户必须苦苦等待最终结果， 那怎么优化？

 

 

       想想生活中的各种场景吧： 你去办身份证， 经历了大厅的接待人员， 来到窗口提交各种手续， 然后进行简单的核对， 然后工作人员告诉你， 你先回去， 等20天后再来取。 这里的办证就是一个写入的流程， 20天后来取证就是一个读的流程。

     工作人员没有让你当场等待20天哈其实， 这里涉及到一个dispatcher的模块， 如下（注意： 先进行1， 然后进行2）：

            

         酱紫， 就避免了苦苦等待的问题。 dispatcher层就是干这个的。

         如上仅仅是一个非常简化和粗糙的模型， 我们看到， 在存储层给dispatcher返回数据时（读数据）， 其实是可以继续进行优化的：

         a. 在写的时， 其实步骤1已经返回通知了， 所以没有必要让存储层再来通知dispatcher层

         b. 在读的时候， dispatcher就没有存在的必要了， 直接在存储层返回逻辑层。

 

         扯了不少， 不是非常严密， 但大致思路就是如此easy