公司楼下有个餐厅，算是附近比较大的，能坐差不多40-50个人，尤其是中午的时候非常火爆。每到这个时候，IT男最淳朴的想法：开饭馆 就会油然而生。

但是我去了几次，发现体验都不大好，因为我每次去的时候都是点现钞的菜，去了几次都很尴尬，平均一个菜要等待30分钟，下午一点也是这个节奏，着实让人有些抓狂。

这一次我竟然没有生气，因为我旁边都站满了人，很多人和我有一样的境遇，有一个哥们刚开始比较低调，站在我旁边，对服务员说，你们太忙了，我都不忍心打扰你们，慢慢做吧，结果他等了差不多20分钟，也耐不住性子了，反应比我们还强烈。我站在旁边，发火发牢骚似乎也解决不了问题，我陷入了沉思。

为什么上菜这么慢？

然后我做了一个粗略的估算：

炒菜是3分钟，半个小时能炒10道菜，除去菜品的差异，压缩一下，半个小时算是8道菜。

如果是10个厨师，那么应该半个小时能出至少80道菜

但是从我的感觉，实际上也就能出差不多40个菜。

我觉得问题出在这几个地方：

1. 每个人点餐的时候信息都是孤立的，即你不知道其他人点了那些菜，所以你没法判断点哪道菜快点，哪道慢点

2. 点餐之后，服务员会给后厨报一下，比如1个青椒鸡蛋，一个鱼香肉丝。炒菜的过程都是一道菜一道菜的出。

3. 服务员旁边摆了一排小票，这些都是属于超时时间较长的，顾客受不了了到前台来催单，然后服务员会在已有的基础上不断催单，尽管如此，还是平均需要30分钟。

4. 后厨有10个厨师，看起来已经是满负荷运转了，但是吞吐量还是有限。

5. 服务员会在这些延迟较大的菜单里面人工识别一些重复的单子，把两个合成一个

想了想，这个问题确实还蛮有意思。如何提高效率，在并发的调度上还是得下一些功夫。

我们来做一个具体的问题分析：

如果明确告诉我等这个菜需要半个小时，我是肯定不选的，而如果告诉我选择某一个菜要3分钟，我肯定优先选择。

这就是一个需求的转变，可能会随着优先级变化，优先级的衡量标准其中之一就是时间，当然还有价格。

所以机器是死板的，人是活的，需求可以整合，况且IT男都相对比较好说话，差不多就行。

当然如果在点菜的时候做好归类和建议，是比做的过程中变更需求体验要好得多得多。

假设我是饭店的老板，看着后厨的10个厨子，我该怎么提高他们的效率呢。

如果在高峰时间，有50道菜要炒，那么10个人来炒，每个人可能是分担5道菜。

有几种分类方法

1. 每个厨子都分类轮询，比如10道菜，一个挨一个，分配给每个人。

2. 指定几个菜式给指定的几个人，比如厨师1-3负责5类菜品，厨师4-8负责另外几类菜品，依次类推。

3. 如果需求量大，就水平拆分，比如菜品1的需求大，我们可以由几个厨师专门负责这方面的。

这个算是调度策略。

如果有5个厨子，50道菜，如果是同一道菜，一个人炒50份，一来没那么大锅，二来炒出来的味道也差，所以不是一个好办法，三来，剩下的9个厨子都闲下来了。

一种改进方法就是每个人炒10道菜，那样的话味道也不好。大锅饭的味道大家都尝过。所以可以定量，就是最多一个人炒几道菜，比如说可控的范围内是5道菜，再多味道的影响就大了，那样就是5个厨子，每人先炒5道菜，出了这50个，然后再来后面的50道菜，平均下来等待的时间也会大打折扣。

而这个问题不是绝对，如果在相对比较闲的情况下，如果5个厨子，有10道菜，那么每个人炒2道菜是最好的办法。而如果是5个厨子，5道菜，一种方式是每人一道菜，要么就是2+2+1的方式，剩下两人闲着。

所以这个过程就会把事务做切分，比如一次炒菜可以最少是2份起，最多5份。

这个算是事务粒度的切分。

而如何提高效率，其实我们可以反向来推。

比如顾客能够忍受的时间是10分钟，那么我们可以对每一道菜都开始倒计时，2道菜拼单，一道菜差不多3分钟，所以我们最多可以错开两个轮询。即等待6分钟，这6分钟内可以完全拼单，这样每道菜的轮询频率在1到3之间。

这个拼单的过程，目前是人工来处理，其实人多手杂，服务员人工很难做到统筹和时间的可控，所以我们可以设计一个程序，通过一个通用的算法来调度这个，让厨师知道目前应该优先做哪一道菜。而不是完全按照点菜的顺序来。

这么一想，核心的思想就是，异步和批量。如此一来我就没有时间发火了，而且越是关注他们的处理。改天要不要写个程序找他们老板聊一聊。

如果你有想法，已经写好了。欢迎骚扰。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2152358/，如需转载，请注明出处，否则将追究法律责任。