58速運訂單調度架構演進（一）

58速運訂單調度架構演進（一）

今天很榮幸給大家介紹58速運從艱苦創業到成為同城貨運行業領頭人的整個系統演進過程。58速運業務簡單說就是同城貨運，比如去買一個大型傢具，自己的家用車肯定是裝不下的，這時可能需要找路邊的小型麵包車或者金杯車來幫你搬運。一般來講，很容易遇到黑車，而且價格不標準，我們做的這個行業就是將這種傳統的黑車行業進行線上化，在產品形態上可理解為滴滴打車的計程車版

1

背景

58速運在2014年是作為58集團下20多個孵化業務中的其中之一，平均三個星期一個業務孵化上線，當時有20多個業務孵化同時進行，這個時間我們不斷的試錯，不斷去尋找58同城新的增長點

從上圖中的大家可以看出所有的服務都基於在一個資料庫來運行，這個系統之間只需要通過一些簡單的tag標記就可以區分開業務，系統迭代非常快。新孵化的業務，增加一些簡單的業務邏輯就能實現這個產品的快速上線

2

痛點

系統不穩定，一個慢SQL，全業務受影響。所有業務都集中在一個資料庫中，一個慢SQL就會把資料庫的所有連接佔滿，導致所有的服務不可用

多業務並存，訂單表索引多，性能下降。 多業務並存，每一個業務都會根據它自己的業務需求去在訂單表中建立索引，結果索引越來越多，整體性能越來越差

訂單欄位冗餘，新增和修改欄位非常痛苦。 每個業務都有特殊的業務欄位，單標數據量已經到達了千萬級，每增加一個欄位和修改一個欄位，都需要耗費很長的時間，而且會造成鎖庫導致系統異常

業務增長迅猛，資料庫已成瓶頸。 58速運整體的訂單增長非常迅速，在成立三個月以後，每天的單已達到了1萬+，系統性能已成為瓶頸

3

技術演進方案

工程解耦，工程代碼模塊從歷史模塊中拆離，比較簡單，不再詳細描述

資料庫遷移，從整體大庫中獨立出來。下面詳細描述一下資料庫的遷移方案

??最簡單的方案就是停服，把所有的服務停掉，然後把資料庫抽離出來，相對來講這是成本最簡單的

停服會產生的影響：

1）凌晨時間業務仍然有訂單，會影響到用戶訪問

2）需要給用戶發公告

3）停服遷移如果失敗，無法向業務方解釋，會喪失信任

我們的遷移方案：

將訂單表放在新的資料庫里，兩個資料庫之間使用雙向同步

雙向同步需要解決時問題：

主鍵衝突：速運的訂單會標記一個比較特殊的標記ID（如80開頭標記為速運，其他業務都是10開頭的），與其它的業務線區分開，這樣就可以保證它在雙向同步時不會出現主鍵衝突的問題

更新覆蓋：update的操作在同步的過程中因為時間差的問題可能存在寫覆蓋的情況，採用訂單日誌的記錄，遷庫完成後做數據的校驗

舉個例子詳細說明一下：我們有1個集群，他部署了4台機器

遷移步驟：

因為要進行遷庫，資料庫的IP改變了，所以服務需要修改資料庫連接的配置文件

當上線的時候。先重啟機器A，然後A的insert和update就寫到新的資料庫了，但是機器B、C、D還寫到老庫上面

因為新庫和舊庫是開啟著數據同步的，所以兩個庫的數據會完全一致，所以業務側完全不會受到影響

當集群全部完成上線後，斷開資料庫之間的雙向同步

4

演進成果

如上圖所示：經過多次的遷移，將原有的資料庫按照業務劃分成了訂單庫、結算庫、配置庫和軌跡庫等，每個資料庫會根據業務量容量的大小來配置資料庫物理機的內核、內存，減少成本

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！