[發明專利]一種分布式任務調度的方法和系統

在審

• 申請號: 201910163677.X
• 申請日: 2019-03-05
• 公開（公告）號: CN111666134A
• 公開（公告）日: 2020-09-15
• 發明（設計）人: 廖耀華
• 申請（專利權）人: 北京京東尚科信息技術有限公司;北京京東世紀貿易有限公司
• 主分類號: G06F9/48
• 分類號: G06F9/48
• 代理公司: 中原信達知識產權代理有限責任公司 11219
• 代理人: 張一軍;張效榮

本發明公開了分布式任務調度方法和系統，涉及計算機技術領域。該方法的一具體實施方式包括：接收來自一個或多個服務器對任務的任務鎖定對象的一個或多個查詢請求；在數據庫中查詢所述任務鎖定對象；響應于查詢到所述任務鎖定對象，將記錄發送到所述一個或多個服務器，所述記錄包括任務鎖定狀態和特定版本號；接收第一服務器的對所述任務的第一更新數據，所述第一更新數據包括第一版本號；響應于確定所述第一版本號與所述特定版本號相同，對所述數據庫執行第一更新；以及當所述一個或多個服務器中的第二服務器發生錯誤事件時，使得所述一個或多個服務器中的其他服務器觸發監聽事件。該實施方式提高了分布式系統的可靠性并降低了方案部署復雜性。

技術領域

本發明涉及計算機技術領域，尤其涉及一種分布式任務調度的方法和系統。

背景技術

現有的分布式任務調度方案比較多，常用的是通過Redis方案或者Zookeeper方案獲取分布式鎖，來解決對多主機多任務處理的調度問題。分布式鎖具有排他性，在同一時間只會有一個進程能獲取到鎖并執行任務，其它進程無法同時獲取。當任務執行完畢后該進程釋放鎖，但是計算機不是100％可靠，因此會出現釋放鎖失敗的問題。

通過Redis方案獲取分布式鎖是目前使用最多的技術，基本原理就是多個線程通過Redis方案的原子操作獲取鎖，其中只有一個線程會拿到鎖。在這種方案下對釋放鎖失敗的問題一般的解決思路是設置Redis鍵的過期時間，這樣即使釋放鎖失敗，也可以到期釋放鎖，但對鍵的過期時間設置為多長不好界定。而通過Zookeeper方案獲取分布式鎖是通過使用它的臨時有序節點來實現的，這種方式部署相對麻煩，生產環境中使用的比較少。

在實現本發明過程中，發明人發現現有技術中至少存在如下問題：

(1)Redis方案中對鍵的過期時間設置不妥便會導致鎖失效的問題，但多長時間是合適的又不好界定。

(2)Zookeeper方案由于強依賴Zookeeper因而分布式系統的可靠性不能保證并且Zookeeper方案部署相對麻煩。

因此，現行的解決方案下分布式系統中鎖失效的問題沒有得到很好的解決，進而使得分布式系統的可靠性難以保證。

發明內容

有鑒于此，本發明實施例提供一種分布式任務調度的方法和系統，能夠通過使用數據庫樂觀鎖取代傳統的Redis方案，因此不需要設置過期時間，避免了對鍵的過期時間設置不妥便會導致鎖失效的問題，并且通過在使用樂觀鎖的基礎上采用Zookeeper作為輔助檢查方案，避免了直接采用Zookeeper方案帶來的部署困難問題，并且不會強依賴Zookeeper。而且能夠在避免了現有方案的問題的同時，還能很好地解決了分布式任務調度中的鎖失效問題。

為實現上述目的，根據本發明實施例的一個方面，提供了一種分布式任務調度的方法。

根據本發明實施例的分布式任務調度的方法，包括：

接收來自一個或多個服務器對任務的任務鎖定對象的一個或多個查詢請求；

在數據庫中查詢所述任務鎖定對象；

響應于查詢到所述任務鎖定對象，從所述數據庫讀取與所述任務鎖定對象相關的記錄并將所述記錄發送到所述一個或多個服務器，所述記錄包括任務鎖定狀態和特定版本號；

接收來自所述一個或多個服務器中的第一服務器的對所述任務的第一更新數據，所述第一更新數據包括第一版本號；

響應于確定所述第一版本號與所述特定版本號相同，使用所述第一更新數據對所述數據庫執行第一更新；以及

當所述一個或多個服務器中的第二服務器發生錯誤事件時，使得所述一個或多個服務器中的其他服務器觸發監聽事件，其中，所述第一服務器和所述第二服務器相同或不同。