上午开会，错过了公司食堂的饭点， 中午就和公司的首席架构师一起去楼下的米线店去吃米线。我们到了一看，果然很多人在排队。
架构师马上发话了:曜，请求排队啊: 你看这位收银点菜的，像不像nginx的反向代理? 只收请求，不处理。把请求都发给后厨去处理。
我们交了钱，拿着号离开了点餐收银台，找了个座位坐下等餐。
架构师:你看，这就是异步处理，我们下了单就可以离开等待，米线做好了会通过小喇叭“回调”我们去取餐:如果同步处理，我们就得在收银台站着等餐，后面的请求无法处理，客户等不及肯定会离开了。
接下里架构师盯着手中的纸质号牌。
架构师:你看，这个纸质号牌在后厨“服务器”那里也有，这不就是表示会话的ID吗?有了它就可以把大家给区分开，就不会把我的排骨米线送给别人了。
过了一会，排队的人越来越多，已经有人表示不满了，可是收银员已经满头大汗，忙到极致了。
架构师，你看他这个系统缺乏弹性扩容， 现在这么多人，应该增加收银台，可以没有其他收银设备，老板再着急也没用。
老板看到在收银这里帮不了忙，后厨的订单也累积得越来越多， 赶紧跑到后厨亲自去做米线去了。
架构师又发话了:幸亏这个系统的后台有并行处理能力，可以随意地增加资源来处理请求(做米线)我说:他就这点儿资源了，除了老板没人再会做米线了。
不知不觉，我们等了20分钟， 但是米线还没上来。
架构师:你看，系统的处理能力达到极限，超时了吧。
这时候收银台前排队的人已经不多了，但是还有很多人在等米线。
老板跑过来让这个打扫卫生的去收银，让收银小妹也到后厨帮忙。打扫卫生的做收银也磕磕绊绊的，没有原来的小妹灵活。
架构师:这就叫服务降级。为了保证米线的服务，把别的服务都给关闭了。
又过了20分钟，后厨的厨师叫道: 237号，您点的排骨米线没有排骨了，能换成番茄的吗?架构师低声对我说:瞧瞧， 人太多， 系统异常了。然后他站了起来:不行，系统得进行补偿操作，退费。
说完，他拉着我，饿着肚子，头也不回地走了。
原文来自尚硅谷Redis7 167_redis高级篇之IO多路复用吃米线聊网络场景哔哩哔哩bilibili
555
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
