云风的 BLOG: 食堂排队系统

今天晚上 18:00 准点去一楼食堂吃饭，结果队伍排到了门口还打了个圈。花了 20 多分钟才领到口粮，回头一看，队伍并没有减短。看着前后都有同学抱着 PSP 狩猎 MHP3，我有点后悔没把 PSP 带下来了。

从这几天的经历来看，我们公司食堂的处理能力应该是够的。从 17:30 到 18:45 基本能处理完 600 号人的进食问题。也不能完全怪发放食物的带宽不够，经过一个月的观察，这部分可以优化的余地不大。而且我认为优化的意义也不大。

那么怎么才能减少这么多无谓的排队时间呢？粗看可能性不大，但仔细想想，如果把眼界放宽到整个系统办公楼运作系统，应该是有可能的。

在不提高食堂带宽的前提下，如果用户随机抵达，理论上队伍总会排到 200 开外。并不会在某个特定时间点减少（只有等到最后队伍才可能逐步缩短）。但我们其实可以把排队时间挪一部分到食堂外面的。行政部以前分发过通知，安排各个部门错开时间用餐也是这个想法。

今天一边排队，一边跟前后的同学讨论是否有可能利用软件来节约大家的时间。

既然排队无法避免，相同状态下，我们当然可以在办公桌前排，而不用站在食堂里。既然每个人从座位上走到食堂的时间几乎不变（取决于电梯的运转周期），每个人从打卡到拿到食物的时间也几乎是恒定的。那么不需要特别的监控系统，我们就可以直接估算出食堂处理的带宽，并不会有太大波动。

而且每个工作日，总的用餐需求也是稳定的。

只要用一个系统，每天随机给所有同事自动排队，并在时间点通知。当每个人都比较严格的遵守约定，在接到通知的一分钟内步行去食堂。那么当他们都赶上同一部电梯的话，这批人抵达食堂的时间都是已知的。那么，在食堂的队伍理论上可以减少到一部电梯可以承载的人数左右。

这样，每个人都可以在本来需要的排队时间内做一些别的事情了。

今天讨论的时候，有同学提出应该在食堂安装摄像头做一个自反馈，让系统可以更好的自我调节。我认为意义不大，这样加大了系统实现的难度。其实在我们的特定需求下，大部分数据都是可以较为精确的估算的。我们可以允许一定的队伍（实际上也一定有，因为公司的电梯很大，导致食堂瞬间的业务量很大，不可以立刻全部处理掉），这个系统只要能帮助大家把在食堂的排队时间减少到 5 分钟以下就非常完美了。

关于如何避免大家都不遵守系统通知时间的问题，或者是有人拖拖拉拉不在通知时间去吃饭。我们先设想了复杂的打卡机制。后来觉得都没有必要。毕竟才几百人，还是比较好协调的。而且现在的饭卡系统本来就有统计每个工号的实际进餐时间。只需要每个晚上做一个统计，把严重不按照系统通知时间去吃饭的同学名单排出来，估计大家都会很有兴趣的去网站上围观的。

至于通知的问题，用 popo 就好了。

btw. 有同学认为，每天花两次 20 分钟在食堂里排队，也是个聊天交流的好机会。嗯，也有一定道理。

Comments

最后一段话说得极是

Posted by: 标准资料网 | (34) January 10, 2012 12:29 PM

个人觉得，这个应该是食堂取餐流程没有优化。对于流水线的取餐，食堂应该对就餐人的口味和喜好进行统计，将大部分人都要的菜应该放在流水线的前面，这样就可以让这部分人提前退出流水线。米饭应该放在第一位的。

Posted by: Anonymous | (33) March 6, 2011 09:33 PM

如果食堂方面没有改进，任何措施都是变相的延长总的就餐时间。计算机排队是可以减少每个人的等待时间，难点是如何公平公正的确定先后顺序。相比传统的肉身排队，在软件中提交排队申请成本小的多（一次鼠标点击而已），大家自然都想靠前，自然就拥挤。

Posted by: liigo | (32) February 28, 2011 06:06 AM

最佳解决方案：食堂改造成自助餐，成本也不高。计算机排队？如何确定先后顺序呢？

Posted by: liigo | (31) February 28, 2011 05:34 AM

非人类就不能留言了么？这不仅仅是种族歧视了，要上升高度

Posted by: Christinena | (30) February 24, 2011 09:42 PM

额，连食堂打饭排队都能做成系统，我晕，真是太强大了。

Posted by: baby walker | (29) February 24, 2011 08:31 PM

太强悍了吧，这也可以啊，经典啊

Posted by: 风的博客 | (28) February 24, 2011 08:52 AM

你们公司什么时间吃午饭，什么时间吃晚饭？可不可以延长一点食堂时间？不喜欢排队的人可以较早或较晚去食堂。不在乎的随时去食堂就行。

Posted by: zhanxw | (27) February 19, 2011 09:46 PM

我等的时候都是玩 iphone4 玩愤怒的小鸟

Posted by: 风吟 | (26) February 18, 2011 11:17 PM

方案：叫号机器(类似银行那种)，用手机登陆这个系统叫号，每人叫一个号(想多叫几个也可以)，然后，系统显示前面有多少个人，给出预计等待时间，自己在办公室估计差不多就出发，点餐的时候，刷一下手机，系统得到反馈，时间估计趋于精准。

Posted by: changjixiong | (25) February 18, 2011 10:43 PM

云风: 在blog.163.com建个博客, 吧文章copy过去吧! 这看着别扭!

Posted by: zhiji | (24) February 18, 2011 06:10 PM

这个现象的本质的原因是人们都希望能够快点吃完饭，然后开始回到座位上开始干自己的事，该打游戏的打游戏，该聊天的聊天，该看电影的看电影。随机通知的弊端如下： 1，有人喜欢一起去吃饭，随机通知很容易拆散，并且让大家缺乏计划性，因为不知道几点可以吃饭，理论上讲，最多有超过1个小时的时间是无法合理安排的。 2，产生负面情绪，为什么别人可以早点吃，而我不行？个人认为最佳的解决方案是从食堂的饭菜方案出发，比如把从17:30到18:45分为三个时段提供不同的菜品： 17:30 - 17:55 提供本帮菜 17:55 - 18:20 提供口味偏辣的菜 18:20 - 18:45 提供面点并且每天的菜品安排都发放给每个人，让大家自己选择，自己计划自己的时间。并且可以通过不同口味的员工的习惯对菜品作出一定的调整，达到最终的平衡。这个实质上还是网游分流的问题，玩家太多，都上同一个服务器。目前的方案还是进行推荐的服务器，实际上很多喜欢人多的服务器的玩家不得不放弃自己的选择。比较合适的解决方案还是每个服务器作出自己的特色来，让玩家从玩法的选择上来做到真正的人性化的负载均衡。

Posted by: tarkey | (23) February 18, 2011 11:50 AM

其实吃饭时间是一天中难得的休闲时间 and 交流感情的机会这样做，效率上可能提升了，但是对人的心理诉求是一种伤害啊哈哈

Posted by: laiwei | (22) February 18, 2011 10:09 AM

随机是指同一时间段内提交的人之间随机排列，并且按前一天的次序调整保证公平。因为吃饭时间都是差不多的，大多数人都需要更早的吃饭（否则就饿到了，或者排到最后有些菜凉了）如果单靠网络请求到达的时间先后，怕是更不公平。摄像头的问题在于，这个最优解(比如保持队伍在 30 以下），需要所有人一起协调才能达到。不然，一旦队伍在 30+ 时，如果你不去排队，而别人去了，这个队伍就永远到不了 30 以下了。而最优解恰恰是每个人都遵守，队伍一到 30 就不下楼去排队，这一原则。所以靠整个系统（所有人）自动调节，是几乎不可能达到最优解的，甚至不能达到比较优的解。只会比最坏的好一点。换句话说，如果期望每个人在食堂排队时间是 5 分钟。那么观察到食堂的队伍达到 5 分钟长的时候，你依靠什么来决定要不要去排队？如果你决定要去排，那么食堂的队伍就一定超过了 5 分钟，并会越来越长。如果一超过 5 分钟的队伍，你就坚决不去排，可能今天你就是最后一个去吃饭的。那么明天，你就会自己把心理阀值调整到 6 分钟。（队伍长到 6 分钟就一定去排，避免最后一个吃到饭）

Posted by: Cloud | (21) February 18, 2011 12:57 AM

如果要食堂早点把今天有什么吃先告诉你们，你们自己决定，再要代表去领；这样不要五六个人一起去排了，或者，再都每个公司不同的进餐时间；

Posted by: Anonymous | (20) February 17, 2011 09:34 PM

摄像头的方案里，用户在预估排队等待时间时需要猜测现在有多少人在去食堂的路上，这个有经验之后会估计得越来越接近正确值。理论上如果把所有道路的人流信息综合起来用户就可以比较好地估计等待时间，但是我想没这个必要。 “如果有 100 人可以忍耐 100 长的队伍。那么即使有摄像头，队伍的长度也会在 100 以上。因为看到队伍短过 100 ，就会有人去排了。”他们吃亏了一次之后就会修正100这个阈值，这就是反馈口阿……

Posted by: sjinny | (19) February 17, 2011 08:41 PM

不如搞个定时自动取餐: 1.每天早上通过intranet 定好餐,选好就餐时间(12:00,12:30,6:00,6:30.....),就餐地点(canteen/办公室) 2.按时间直接送到就餐地点取饭,canteen 按层分类,办公室的就直接送到每层的pantry里.

Posted by: Kenny | (18) February 17, 2011 08:04 PM

@云风你原文是“只要用一个系统，每天随机给所有同事自动排队”，但这样我觉得过于理想化。所以才有了开会被打断一说。不过你后面给我的解释是“只需要把在网络上提交申请就假想为肉身站在食堂里就可以了”。我想云风你的意思应该是自动随机排也隐含了必须先提交的前提。不过这样是不是有点不公平，明明我先申请的，结果一随机给到后头去了。或许没必要那么复杂，你看银行里面的叫号系统，取一个号，然后等着被服务。过号得重新取号重排。食堂系统只需要接受大家的申请，然后按时间排序。每隔10分钟通知一批人下去取餐。有过号的只能重新申请重排。有会议的自然不会去申请。我理解这个排队系统其实并不改变排队需要的绝对时间（在食物带宽没有改进的前提下，在系统里排队和在食堂里排队没有本质区别），而是提高了每个人的时间利用率。装摄像头，恐怕有这个问题：大家一看队伍短，然后都冲出去排队，结果队伍又变长了。但既然出来了，总不能又回去吧，只好继续排着。不过摄像头能对下一拨人能有警示作用，但对当前这一拨，就不好说了。

Posted by: 红色警戒 | (17) February 17, 2011 06:15 PM

结合红色警戒和云风的解释，在随机通知同事去打饭的时候可以加上反馈机制，确认之后ta的这次调度才有效，否则等下一次（可以适当降低优先级）：）

Posted by: Junhao | (16) February 17, 2011 05:12 PM

Joel 在中谈过他们的进度估计机制.用每个人的实际完成时间和估计时间之比反馈到系统,使得系统的估计越来越精确. 感觉这种技术也能用到食堂排队中去. :)

Posted by: luckyted | (15) February 17, 2011 04:33 PM

@红色警戒我在文中已经说了，食堂带宽已经很难进一步优化。你说的一切优化，我们的食堂从第一天开始就是这样做的。每个人取走全部他的食物，不过几十秒而已，根本没有耽搁。这一点很容易计算出来，600 人在一个小时内拿走全部食物，平均一个人只有 10 秒可以分配。现在的问题不是优化带宽可以解决的。这个排队系统的本质是，把排队过程从肉身食堂站队转移到计算机里而已。只需要把在网络上提交申请就假想为肉身站在食堂里就可以了。跟是不是开会被打断等没有关系。其实你提交了而到你的时候通知你去而你没空。这跟肉身去排队到一半有事离开，本质上没有区别。 @sjinny 关于装摄像头的方案，我们昨天吃饭时就讨论过了。这个方案能够改良的程度有效。上面我已经分析过。在目前的流水线上，平均每个人的处理时间已经压缩到 10s ~ 20s 左右，没有太大优化空间。总的处理量是 600 ，总时间是 1 小时。所以排队是无可避免的。有摄像头的话，队伍的长度应该跟群体对队伍的长度忍耐度有关。如果有 100 人可以忍耐 100 长的队伍。那么即使有摄像头，队伍的长度也会在 100 以上。因为看到队伍短过 100 ，就会有人去排了。这是因为，摄像头并不会让食堂队伍之外变的有序。而肉身队伍长度的理论上可以减少到电梯的单次承载量。以 30 人计，那么肉身排队时间可以减少到 5 分钟左右。

Posted by: Cloud | (14) February 17, 2011 02:22 PM

等待吧...估计有一天会有这个玩意儿的。

Posted by: Maplews | (13) February 17, 2011 12:49 PM

食堂到每个办公室送饭不就可以了？

Posted by: haxixi | (12) February 17, 2011 11:59 AM

云风太理想化了，比如我正在主持会议，突然通知我要去楼下吃饭，这个恐怕很难做到了。不如把食堂的饭菜提前公示，一般也就几个组合，大家在前一天自由选择，食堂统计各组合数量，提前装入餐盒或者餐盘，来一个人就拿走一个（结帐可以在系统上提前刷卡）。这样即使是600多人，速度也会加快很多。

Posted by: 红色警戒 | (11) February 17, 2011 11:31 AM

直接把人群分成N的时间段就ok了，哪怕每个时间段中，有少数不遵守时间段的噪音。

Posted by: zbz | (10) February 17, 2011 10:55 AM

通知已经足够了，其他保证措施完全没有必要，人不是机器

Posted by: nothanks | (9) February 17, 2011 10:15 AM

和金山一样走自助餐吧