精品三级黄色在线观看,我的小后妈韩国免费观看-百度,午夜三级黄片国产,欧美一级激情精品久久久

2019年11月29日，在滴滴拼車上線4周年之際，滴滴發(fā)布全新的拼車產品，同時宣布2019年12月3日在北京、上海、廣州、成都等26個城市推出拼成一折的活動，打造首個“全民拼車日”。面對類似雙11的一折促銷活動，如何應對瞬間的流量峰值，以及平滑、高效的實現司乘撮合，本文就滴滴的派單引擎來闡述這些問題的解決思路。

　0.

目錄

　　1. 背景

　　2. 滴滴分單架構概述

　　   ○ 分單模式

　　   ○ 滴滴分單架構

　　3. 拼車日帶來的挑戰(zhàn)

　　   ○ 拼車原生屬性

　　   ○ 拼成出發(fā)預約模式

　　   ○ 服務化架構

　　4. 穩(wěn)定性保障之路

　　   ○ 架構優(yōu)化

　　   ○ 拼成出發(fā)預約模式 - 臨近指派

　　   ○ 過濾邏輯優(yōu)化 - 架構與性能的折衷

　　   ○ 超時重試配置化

　　   ○ 預案建設

　　   ○ 全鏈路壓測

　　   ○ 監(jiān)控告警

　　   ○ 告警

　　   ○ 監(jiān)控

　　   ○ 集中值班

　　   ○ 通報機制

　　   ○ 快速決策方案擬定

　　5. 展望

　　   ① 背景

　　   11月29日，在滴滴拼車上線4周年之際，滴滴發(fā)布全新的拼車產品。同時宣布12月3日將在北京、上海、廣州、成都等26個城市推出拼成打一折的活動，打造首個“全民拼車日”。

　　   拼車推出新模式“拼成出發(fā)”和拼成打一折的活動給分單引擎帶來成倍的壓力增長，本文介紹其中的挑戰(zhàn)。

　　   ②滴滴分單架構概述

　　   滴滴分單引擎主要做的是司機和訂單的匹配，也就是來決策如何更好的將用戶的訂單分配給司機。

　　   ▍分單模式

　　   從分單模式上，主要抽象為獨乘分單和合乘分單(拼車分單):

　　   獨乘分單解決的是單個訂單和司機的最優(yōu)決策分單，分為多種場景模式，目前承載了滴滴快車、專車、出租車、豪華車的獨乘分單業(yè)務。

　　   對于拼車單，會將順路的訂單進行打成一個“包”，在獨乘分單的基礎上，拼車分單還要解決“包”和司機的最優(yōu)決策分單，承載了目前快車拼車、出租車拼車、跨城拼車的合乘分單業(yè)務。

　　   ▍滴滴分單架構

　　   分單整體流程如漏斗，訂單司機對會從頂層，層層向下篩選，最終形成一個個可匹配的訂單司機對。

　　  假設參與計算的訂單有1000，司機有4000，那么進入第一層的訂單司機對數是400萬，計算壓力與訂單數和司機數的乘積成正比。

　　  ③拼車日帶來的挑戰(zhàn)

　　  滴滴分單引擎主要做的就是司機和訂單的匹配，所以司機訂單匹配計算量基本上表征了整個系統(tǒng)的壓力。

　　  活動當天：司機訂單匹配計算量峰值相比日常峰值增長2.24倍，其中拼車計算量相比日常峰值增長6.6倍。

　　  總結下來主要是以下幾方面的原因:

　　  ▍拼車原生屬性

　　  對于一個普通的快車單來說，分給一個司機之后，在這個司機快到達目的地之前，這個司機可以認為不參與分單了，對于系統(tǒng)壓力變小。

　　  但是對于一個拼車單來說，分給一個司機之后，這個司機會繼續(xù)進到分單系統(tǒng)里面來，和別的拼車單執(zhí)行“拼”的邏輯，所以相比于快車單，司機的匹配周期更長，計算也更復雜，除了考慮司機和乘客的匹配外、還需要考慮乘客和乘客的順路度。

　　  ▍拼成出發(fā)預約模式

　　  在正常情況下，一個快車單的生命周期只有有限幾分鐘，生命周期內沒應答，就會自動取消，那么系統(tǒng)就沒有壓力了。

　　  拼成出發(fā)，分為隨時可走和預約模式，預約模式最長生命周期1天，雖然初期預約單占比不高，但隨著時間推移，預約單越堆積越多，系統(tǒng)壓力越來越大。

　　  拼成出發(fā)只能分配載人車，或者作為一個包分給司機，本身條件就更苛刻，在訂單池里面的存活時間也更長一些。

　　  總結來說，拼成出發(fā)模式使得訂單的生命周期更長。

　　  ▍服務化架構

　　  目前的司機訂單過濾架構簡化圖如下:

　　  整體分單流程是一種漏斗形式，輸入是需要匹配的司機和訂單，輸出是匹配成功的匹配對。

　　  第一層漏斗是通用過濾層，對于通過了通用過濾模塊的司機訂單組合，才會漏到拼成過濾層進行過濾。

　　  無論是通用過濾模層還是拼車過濾層，都是先進行過濾，對于沒有被過濾的司機訂單組合，再進行訪問下游的工作。

　　  對于在2.1部分過濾的司機訂單組合來說，在1.2部分訪問的下游數據很多是無用的，也就是說給下游帶來的壓力是浪費的，這也是服務化架構引入的代價。

　　  拼成出發(fā)模式因為拼成了才能派車，而是否可以拼成的邏輯都在拼車過濾模塊中，隨著時間的積累，能通過1.1但是無法通過2.1的司機訂單組合越來越多，這也是下游壓力增長過大的一個原因。

　　  ④穩(wěn)定性保障之路

　　  我們的穩(wěn)定性保障工作主要分為架構優(yōu)化、容量評估、預案建設、監(jiān)控告警、全鏈路壓測幾個部分:

　　  ▍架構優(yōu)化

　　  我們對現有架構進行了審視：

　　  其中拼成出發(fā)預約模式和服務化架構引入的代價部分，給下游帶來的壓力過大，不能完全按照現有模式進行擴容，我們需要對現有架構進行優(yōu)化。

　　  拼成出發(fā)預約模式 - 臨近指派

　　  針對拼成出發(fā)預約模式，用戶發(fā)單之后，訂單會同時進入分單的訂單池和拼車的拼友池。拼友池：進入拼友池的訂單，拼車打包模塊會給當前用戶尋找拼友，也就是進行打包操作。

　　  訂單池：進入訂單池的訂單，就會進入分單引擎進行分單。但拼成出發(fā)預約模式，會在訂單出發(fā)時間的前k分鐘，才真正開始給用戶找車，在找車之前的計算都是無效的。

　　  針對這種情況，對拼成出發(fā)預約模式進行了優(yōu)化，將發(fā)單進入訂單池的操作改為臨近進入訂單池，有效降低訂單池規(guī)模。

　　  過濾邏輯優(yōu)化 - 架構與性能的折衷

　　  針對服務化架構引入的代價，拼車分單的同學將拼車過濾中過濾比例較高的策略，遷移到了通用過濾模塊中。這算是在現有架構下，為了性能的一種妥協(xié)。

　　  后續(xù)應該會探討出一種更合理的架構來解決這種問題。

　　  經過評估，上面2部分的業(yè)務架構優(yōu)化，在同樣用戶呼叫單量的前提下，對下游的訪問壓力可以下降50%以上。

　　  超時重試配置化

　　  為了更加靈活的控制下游的超時重試，整個分單主流程的調度周期，下游的超時時間，重試次數，都實現了配置化，修改秒級生效。

　　  為了防止流量突增時引發(fā)下游雪崩，在拼車日之前，我們將整個分單主流程的下游重試都調成了1，也就是不再重試。

　　  ▍預案建設

　　  因為活動中可能會有很多不可預知的事情發(fā)生，針對可能發(fā)生的異常，我們做了一系列的預案。

　　  預案的底線目標是：保障評估容量內無異常，超出評估容量不被打掛;包括五部分：

　　  提前降級功能：活動前操作，主要提前降級的功能

　　  入口預案：活動中操作，出現重大風險和異常時執(zhí)行

　　  最小核心鏈路預案：活動中操作，核心節(jié)點出現風險和異常時執(zhí)行

　　  業(yè)務指標異常預案：活動中，系統(tǒng)無異常，但是業(yè)務指標出現異常

　　  崩潰恢復預案：核心服務出現雪崩，如何快速恢復

　　  每項預案都需要提前演練，保證預案有效、且符合預期。

　　  ▍全鏈路壓測

　　  全鏈路壓測是評估系統(tǒng)容量最有效的手段，拼車日一共進行了8次演練，9次正式壓測，發(fā)現了45個有效問題。

　　  經過一輪又一輪的壓測，大家對自己的服務容量都有了更清晰的認識。

　　  在壓測過程中，到達系統(tǒng)容量之后，我們還會繼續(xù)加壓，觀察多個系統(tǒng)在系統(tǒng)超限情況下，是否會被打掛。

　　  在壓測過程中，我們也會演練提前制定好的預案，把壓測場景當成活動日看待。

　　  ▍監(jiān)控告警

　　  告警

　　  拼成日之前，我們重新梳理了各模塊告警。分以下幾大類：

　　  機器信息類：包括cpu、磁盤、句柄數、網卡錯誤、協(xié)議棧錯誤

　　  自身服務：包括存活性、服務容量水位線、服務總耗時最大值、服務各階段耗時最大值

　　  依賴服務：包括請求耗時、超時或者錯誤率、是否限流

　　  client端：請求耗時99分位、成功率

　　  同時對于各個告警都進行了報警升級，拼車日當天寧可誤報，不可錯過任何一個錯誤信息。

　　  針對每個告警，都有至少一個預案閾值對應，保證系統(tǒng)穩(wěn)定性。

　　  監(jiān)控

　　  除了完善系統(tǒng)各項指標監(jiān)控，我們還建立了多個監(jiān)控大盤。

　　  拼車業(yè)務指標大盤：各個指揮者需要實時關注該大盤。

　　  系統(tǒng)機器性能大盤：運維人員需要實時關注該大盤。

　　  各個服務監(jiān)控：為每個服務指定負責人，實時關注。

　　  ▍集中值班

　　  通報機制

　　  各個方向值班長需要在值班群里實時通報異常情況。

　　  每隔10分鐘，各個方向值班長需在值班群里通報系統(tǒng)是否正常。

　　  快速決策方案擬定

　　  拼車日之前，已經確定好。遇到何種問題需上報，何種問題需立即快速解決，何種問題需上下游配合解決。解決方案要盡可能得覆蓋異常情況。

　　  我們采用了扁平化的人員組織方式，以達到更高效率的問題處理。

　　  拼車相對于快車對系統(tǒng)在匹配復雜度、路徑規(guī)劃等方面的挑戰(zhàn)更大，難度更大，基于這次拼車日保障的積累，我們將不斷提升能力，提供穩(wěn)定可靠的技術保障。

　　  文章來源：滴滴技術