由于自己比较喜欢吃零食，也比较喜欢喝有味道的饮料，所以在办公室经常能听到我喊点奶茶不？那么好的日子点个奶茶庆祝下吧？我靠这坨代码谁写的，我改好了，请我喝奶茶吧。。。
但是有时候发现，大中午的奶茶店就是休息状态不接单了
节假日时间的话就比较喜欢自己去商城小吃摊吃东吃西，吃完买个奶茶什么的回来喝。不过今天在快乐柠檬买柠檬菠萝冻的时候，看着手上的号码前面也就2个人，却等了二十来分钟，期间外卖小哥们、不耐烦的客人呀都没好声地一直催呀催呀，那个好看的小姐姐（这不是重点）倒是依旧和气无奈的说还没好。。。
想想平时在地铁那头排队买一点点的时候，虽然人也很多，但是还没有听到过客人怎么抱怨
分析下两家店单子的处理方式的异同
两家的现场单子和外卖单子的序号是分开的，可能是由于外卖单号由外卖app产生导致的
快乐柠檬： 外卖单和现场客人的单子无区分，谁单子先到先处理谁的
一点点： 有不同的窗口，现场客人和外卖单子交由不同人处理，做好了由不同的窗口出
为什么产生抱怨？
快乐柠檬按照接单的顺序先到先得处理不是很公平嘛？看着是的，对于店家自己来说不管是外卖单还是现场客人，他都是按照单子上点的条目，一项项完成就好了，但是为什么两边的人都起火了呢？ 因为对于客户和外卖小哥来讲，心理体验是不一样的：
- 客人可谓是亲临现场，内心一般是“老子都亲自来了还那么慢，都叫外卖了肯定也不会差那么点时间，怎么不给我先做” ，而且实际喊号的时候并没有按照手头的号码顺序，肯定是会不爽的
- 一般像我叫奶茶也不会只叫一杯（外送费都半杯的钱了，肯定会忽悠好多人一起）所以一般都是好几杯一起的，而且啊，有时候产品经理自己范驴，在上线前一天调整东西，怎么办？为了讨好单纯的我们，就是一下子十几二十杯啦；而外卖app一般为了体验都是有超时时限的，也会着急
周五了、放假了，大家都想吃吃喝喝，这个时候奶茶也迎来高峰期。按照这家快乐柠檬的做法，如下图 其中 w-1 表示一个十杯的外卖单子，你说如果你是 2号客人你揪不揪心？明明1号完了就应该是2号啊
image.png
怎么办？
-
增加小能手？
确实可以一定程度的缓解这个压力，但是毕竟店铺空间有限，加不了太多；而且，即使产能加快了，2号同学还是有点绝望，因为总归还是要被不相关的人影响 -
让外卖单号和现场打单顺序一致
现场客人眼睛不瞎。。。 还是算了 -
学一点点那样分专人处理
在高峰段现场客人虽然等待，但是目睹到的是按序号一步步出还是可以接受的；就是加人手可能需要点成本，还有一个就是现场客人比外卖单子高很多的时候（或者反过来），外卖单子小能手可能一边玩着手机一边眼睁睁的看着 现场小能手忙的出汗了，不过这个简单，老板一声令下，你很闲啊？过来帮忙，完美解决~~
image.png
软件开发中的队列分配
之前做系统对接的时候，遇到过很类似的场景： 我们需要其他多家公司做商品对接，涉及到的有全量商品导入、增量商品更新、下架这几个；我们提供接口供外部调用，对方提供回调通知接口，初步的方案是将外部数据存入同一个消息队列再异步慢慢处理，结束后回调通知对方。咋一看没什么问题，所有商户都可以用一套逻辑，但在设计评审的时候发现，不同商户公司自身的更新机制不一样，对接的商品类目和数量也不一样，这就会导致上面奶茶店的问题，可能A商户只更新10条商品，B商户在其前1毫秒更新1000条商品，A商户在我们公司的商品数据就要脏蛮久的。 调整后的就是根据商户id入不同的队列，同一套商品处理逻辑部署多个消费者处理不同商户的队列。
这样既可以在高峰时动态增加消费者来提高产能，又可以针对不同场景做特殊化处理，也可以在闲时做 “工作窃取”，在都不会影响其他人的体验
唠叨点别的
类似的还有什么呢？
- 单线程架构的redis，慢查询导致其他命令的阻塞
- all-in-one架构里，别人改了基础类库导致你的应用奔溃了。。。 无奈吧
- 提交代码前pull下来莫名其妙的冲突
或者这些也就是为什么，写代码写着写着就越来越喜欢把一些东西隔开来，把不同变化频率的东西隔开来才能各自跑的快嘛
最重要的：
生活处处有架构的影子，所以，多去吃好吃的。
网友评论