最近经历了两件事,去医院药房取药和富阳驾照考试,出于职业习惯,引起了我对队列和排队系统的重新思考。
一、取药
image.png
去药房取药的流程大致是:
- 拿处方单去取号机器扫码取号
- 拿着取药号等待
- 看到窗口LED屏显示自己的名字后,在窗口排队
- 排到自己被叫号后去窗口取药
取药.drawio.png
二、驾照考试
image.png
科二考试流程如下:
- 候考大厅签到
- 候考大厅等待
- LED屏考试区看到自己的名字后进入考场考试
image.png
三、排队系统
不管是取药还是考试,我们都可以看做是对用户的一个端到端的服务过程,把用户看做是C(Consumer)端,把药房或考场看做是B(Business)。
image.png
把以上取药和考试对比和抽象,我们可以提取出来一些共性。
用户身份
除了用户基本信息之外,还包含一些其他特性,用来为用户提供更合适更高效的服务,比如考试报考是手动挡捷达,那么肯定不能分到自动挡宝来吧;同样有些医院药房会有特殊人群优先窗口或者特种药窗口,这些都是根据用户身份信息以及诉求信息来定义的。
资格
有资格之后,才能享受响应的服务,比如医生开了药单并且交了费才有资格去取药,科目二报名并且交了钱才有资格去考试,而这里所说的资格包含另外一层意思,比如说拿着药单没有取号、或者由于其他什么原因离开,那么药房不会备药,也没有资格去排队取药;考试报了名交了钱,但是没有签到或者根本没来,那么考场就不会安排对应资源或者服务。
资格可以定义为,用户提供响应资料或费用,并且到现场提交了服务申请。
分流与规则
用户拿到取药号之后,他的取药诉求会进到一个大池子,在等待的过程中,取药系统会根据各个窗口的忙碌情况以及根据用户身份和诉求提取到的规则,将其号码分配到对应窗口排队;考试也一样,考生签到之后,会根据包括车型、手自动挡类型,将其分配到对应的考试区进行等待。
分流是一个动态过程,拿到用户身份和提交的诉求,然后与提前定义好的规则去匹配,然后将其与规则指定的服务线路进行绑定。
资源准备
C端的动作其实很简单,只需要签到或者取号、等待、排队,享受服务或者执行某项动作,而B端则要将整个流程协调串联起来,并且要调动相关资源为C端触达到的每个环节做准备。
对于药房,用户取号的时候,取药系统接到请求,在生成取药号的同时,也会给药房发指令备药,然后在取药号被分配绑定到某个窗口的时候,将备好的要与窗口绑定;或者取药系统将用户取药号分配到某个窗口的时候,发指令给药房去备药,然后直接绑定到某个窗口和用户。
对于考试,考生签到进入候考大厅的时候,考试系统识别到考生所报档位类型、车型,在考生等待的同时,将考试车和路线准备好,然后和考试区以及考生进行绑定。
那么就取药排队系统流转核心节点如下图:
取药.drawio (1).png
- 用户取号,那么取药系统引擎为其生成号牌,并将号码与用户绑定放入公共池(FIFO队列)
- 取药号码进入公共池的时候,触发分流事件,引擎捞取分配规则、窗口排队忙碌程度,将用户取药号分流到某个窗口
- 如果分流成功,用户取药号与窗口绑定,进入取药窗等待队列(FIFO队列),引擎将会给药房发指令备药,并将备药单与窗口、取药号以及用户信息绑定;如果分流失败,则终止流程,等待下一次分流事件
- 用户在窗口排队等待,轮到自己取药后,窗口给引擎上报取药成功事件,这时引擎会收集各个窗口忙碌情况,然后将公共池的取药号进行分流
考试排队系统和药房基本类似,不再重复举例。
四、举一反三
前边所描述的场景和流程相对比较粗糙,在真实场景中肯定会遇到更复杂的问题,我们简单举几个场景做一下分析。
1.如果用户取完号走了怎么办？
会存在这样极端场景,用户取完号正好有急事走了,没有去排队取药,那么如果不做异常情况兜底,窗口轮到他取药的时候,会一直占用窗口队列的第一个位置,对其他排队人员以及工作人员造成干扰。
简单的处理方式是设置超时时间,如果超过5分钟一直没有来取药,工作人员可以手动将其放入异常队列,用来在下班之前突然用户来取药以及盘库操作。
2.如果高峰期窗口爆满了怎么办？
根据人的生活作息规律,早上刚上班时一般不会有太多人,所以一般开两三个窗口就够用了,到高峰期的时候,取药系统可以监控到公共池的数量,如果超过设定阈值,可以适当增加开放窗口数量,但是窗口数量也是有限的,如果窗口全部开放,还是无法满足诉求,如果都进公共池,只能等待,那么这种情况可以采取暂时关闭取号能力。
3.如果低峰期窗口没有排队怎么办?
低峰期进入公共池的频率和数量都会大幅降低,各个窗口的排队数量也会减少,系统监控到这些指标后可以向某些窗口发送指令关闭窗口,前提是窗口关闭之前要处理完排队中的号。
4.特殊取药窗口如何实现？
在一些大医院应该会有特殊人群取药窗口,比如军人、烈属等优先窗口,以及我理解还会有一些特种药取药窗口,比如紧急药物或者贵重药物等,那么如何实现特殊窗口和正常窗口呢？
如果进公共池子的时候都在同一个FIFO队列,那么虽然通过取药号关联的身份属性能够做一些个性化分流,但是正常窗口的取药号和特殊窗口的取药号会相互影响,比如99个普通取药,1个特殊取药,那么万一特殊取药号排在了队列最后,那么需要等正常取药号全部分配了才能将其分配,那如果正常窗口爆满了呢,特殊取药号一直无法分流,并且特殊取药窗口长时间会闲置,那么就失去了其存在的本质意义。
我们可以根据需要,在公共池中区分普通号和特殊号,设置普通号队列和特殊号队列,甚至更多的细化渠道队列,系统在进行分流的时候,普通号只能分流到普通窗口,特殊号分流到特殊窗口,从而实现物理隔离。
5.窗口排队优先？还是药房备药优先？
取药窗口之所以长时间排队,是因为流程设计问题,而不是单纯的备药人力不足的问题,我相信应该有一部分取药系统在设计的时候,是在排到队列头部位置的时候才开始发指令备药,那么这个过程是很慢的,从公共池分流到窗口再到排到队首位置这么长一段时间是浪费的,当然可能是其设计的时候考虑的侧重点是规避不来取药造成的资源耗损问题。
更合理的方式是在系统将公共池的取药号分配到对应窗口的时候,给药房发送指令同时进行备药,那么用户在窗口排队就是排到之后拿到药就走,就大大降低了排到号等待备药的时间。
五、再思考
回过头来重新思考一下类似取药和驾考的排队系统,我们可以从技术和设计维度抽象出几个重要的角色。
1.请求与身份
所有的请求出发点都是用户,用户想要被服务,首先你要发出诉求,比如取药要先取号、考试要先签到、银行办业务要先取号排队等等。并且被服务的质量与身份也有关系,比如VIP直接小房间一对一办理业务。
2.规则
规则是根据用户请求与身份匹配相对应服务的参照物,比如特殊人群分配特殊窗口接待、银行VIP或者大额用户单独或者大堂经理接待。
3.队列
队列是用户接受服务之前的缓冲区,前边所说的公共池是队列,窗口排队也是队列,队列的存在是解决当前无法立即提供服务时设置的缓冲区间,等可以提供服务了会从队列移出。
4.引擎
引擎是整个排队系统的大脑,C端请求的接收,各个环节的衔接,事件的处理,规则的执行,队列的分流,资源的调配等等都由其完成。
网友评论