用【快餐店】理解高并发分布式架构,秒懂!
小伙子開了一家快餐店叫開封菜,主營炸雞漢堡薯條,快餐店剛開始營業,小伙子一個人收銀、炸雞,所有活自己干。
?
假如有一天生病了,餐館關門停業幾天,什么活都干不了,所以這兩項工作要解耦(耦:古代指的是兩人并肩而耕地,一個不耕了,好家伙,這地就沒法耕了)。解耦就是你炸雞的工作不會影響到我收銀的工作,怎么做呢,再招一個員工當收銀員,原先那個員工專職做炸雞師傅,這樣就完成了系統解耦(即收銀和炸雞師傅那個工作互不干擾)。
?
?
快餐店業務解耦后,業務很快又開始展開了,現在的消費流程是,收銀員收款后告知后廚制作,但新問題又出現了,很多客人付款后在那里等,后面來的客人一看人多就走了,前面來的客人點了餐被后面的客人拿走,就很生氣,發現這些問題后店鋪引入了點餐排號器(這就是隊列思想),點餐后客人知道自己是多少號,前面還有多少人,后廚根據點餐的序號進行餐點烹制,既解決了客人點餐的焦慮又解決了出餐和取餐不按順序來做的困擾,這就是消息隊列的作用:提高系統響應速度,順序處理,削峰。
?
?
客人能夠有序的拿到自己點的餐,服務滿意度提高了,生意也火爆了起來,但后廚僅有一個廚師在炸雞,只能廢寢忘食、加班加點的干活,但還是忙不過來,顧客又開始抱怨了,這個時候店鋪一下子招了五個炸雞師傅,一下子緩解了工作壓力,組成了炸雞集群(集群:同一個業務部署在多臺機器上,提高系統可用性).
?
服務又能正常進行了,可是收銀的柜臺只有一個,隊伍總是排的很長,排在后面的顧客不停的抱怨,這個時候只能增加收銀柜臺,又增加了三個收銀員工,形成了收銀集群,服務質量得到了很好的保證,根據實際業務升級的兩套集群服務形成了一個集群體系。
?
?
?
隨著后廚人數眾多,一個廚師要炸雞,不僅要自己分割雞肉,還要進行原料的處理,在后廚不停的忙碌,但效率卻不高,時間都浪費在去做餐品不同環節的路上和更換原材料、變更廚具上,店鋪在請教其他專家后把后廚人員安排成專屬環節廚師,這樣就加快了餐品的輸出,分割雞肉,裹炸雞粉,炸雞分別由三個不同的廚師完成,這就是分布式的特點,加快了各個環節的輸出。
?
現在的生意越來越好,后廚效率也得到了提升,出餐速度非常快,可收銀下單的地方人又開始堆積起來,店鋪又開了五個收銀通道,為了確保每個收銀通道都能一起工作避免資源浪費,就在門口安排了一個引導員,將顧客按照順序引導到每一個收銀通道去排隊,按照第一個、第二個、第三個,直到第八個后又從第一個開始,這樣就確保了每個通道資源不浪費,這就是負載均衡輪詢方式的典型應用;
?
?
可問題又來了,新安排的收銀員由于業務剛上手對操作不熟練,導致分給她的客人遲遲下不了單,而幾個老收銀員由于業務熟練則能很快完成收銀操作,這個時候店鋪安排門口的引導員給熟悉業務的收銀員多分配一些客人,給業務不熟練的收銀員少分配幾個客人,這就確保客人能及時的下單,這就是負載均衡權重的方式。
?
整個店鋪目前的發展已經非常穩定,各個環節都能夠及時處理客人的需要,還有一個問題是店鋪無法避免的,那就是用餐高峰總集中在早中晚那幾個小時,其他四五個小時店里卻沒有什么客人,在客人密集的那段時間,后廚操作再快有時也無法滿足客人的需要,總有客人抱怨,這個時候店鋪就想辦法,引進了一個食品保溫箱,能夠將當天生產的炸雞漢堡放在里面保持溫度而品質又不變,對店里客人經常點的菜品在沒有客人的時候提前制作出來放在里面,當有客人下單后直接拿走,這就是熱數據緩存機制。
?
通過以上的服務解耦,引入消息隊列,進行集群化分布式改造,進行負載均衡,搭建緩存數據集,小小的快餐店已經從一個單一化服務的店鋪晉升為集群分布式服務的店鋪,下一步就是接入外賣和外部訂單系統進行云服務化。
總結
以上是生活随笔為你收集整理的用【快餐店】理解高并发分布式架构,秒懂!的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Scala _05集合_数组(一)
- 下一篇: 一文讲透大型网站架构模式核心原理与案例分