2019獨角獸企業重金招聘Python工程師標準>>>

概述

本文是Spring Cloud Task系列的第五篇文章，如果你尚未使用過Spring Cloud Task，請 移步spring cloud task1 簡介與示例。 本文主要講述的是Spring的另一個核心子項目 Spring Batch 批處理應用的一些設計技巧和原則。這些技巧分別涉及

原則與技巧

應用數據庫設計原則

多分區批處理應用通常會用到數據庫表分表。分表的設計是選取某個索引列作為分表的關鍵字，將有不同關鍵字的數據分別存儲在不同物理數據庫（表）。數據分表架構應有一個中心數據倉庫（表），存儲表分區參數等元數據。中心數據倉庫（表）一般由單個表（非分區）組成，記錄所有表分區的信息。有了中心數據倉庫（表），數據分表架構才具有靈活性和可維護性。

中心數據倉庫（表）的分區信息表所存儲的數據通常是靜態的，且只有DBA才有維護的權限。分區信息表的每行都包含一個表分區的信息（或者批處理應用實例的信息），分區信息表應該有代表應用編號的列(program_id )，分區邏輯編號( logical _id)以及要處理的數據分區主鍵最大值和分區主鍵最小值等信息。

在應用啟動時，控制程序會把應用編號和分區編號傳遞給應用。如果使用關鍵列分表的方法，控制程序則會將要處理的數據范圍傳遞給應用。另外下面兩種處理還會用到分區編號：

需要將多個數據處理應用的結果合并并輸出到文件或數據庫中。

將分區應用的正常工作日志上報到控制器或將分區發生的錯誤上報到錯誤處理器。

極小死鎖原則

在并行或分片批處理應用中，數據庫資源可能會發生競爭或死鎖。在設計數據庫時請謹記下面這句話，減少數據競爭條件與完成業務需求同樣重要。

死鎖或訪問熱點常常發生在控制表或架構核心表中，如日志表，控制表，鎖標識表。系統的瓶頸往往發生在這里，故而在架構設計時應該著重考慮這些表的性能需求。

為降低數據訪問沖突所造成的影響，架構中應該設計類似 等待-重試 的周期服務，當訪問數據庫或發生死鎖時，等待-重試 服務能減少數據沖突所造成的影響。這種機制對數據庫的錯誤碼并不立即響應，而是在經過預定時間和重試后，如果還發生錯誤，再向上層拋出錯誤。

參數解析與驗證

分區應用架構應對開發人員相對透明，分區架構應確保下列3個與應用分區相關的任務能夠執行：

在應用啟動前檢索分區參數

在應用啟動前驗證分區參數

在應用啟動時解析參數

驗證任務確保參數能滿足以下兩點：

確保應用有足夠的分區示例覆蓋到整個數據集區間

分區與分區之間沒有遺漏的數據

如果應用數據庫也采用分表分庫的方式來設計，那么還應該有一個表分區檢測任務，確保一個應用分區不會跨越多個數據庫分區。

分區架構還應該考慮分區的一致性問題，如：

在進行下一步操作之前確認當前操作完全完成

如何處理任務分區失敗

關于

示例源碼

Spring Cloud Task learning 的 task-demo-with-datasource 子項目

后記

Spring Cloud Task是一個優秀的項目，但是我找遍網絡，也難以找出系統的、準確的中文相關文檔。本系列文章以保證對Spring Cloud Task相關概念和設計理解的正確性為標準，盡量采用通俗易懂的語言，希望能給各位帶來一些便捷。

本文內容主要是對 Spring Cloud Task 1.2.2-RELEASE 官方文檔的翻譯，不過作者水平有限，有不盡然的地方敬請指出。本項目和文檔中所用的內容僅供學習和研究之用，轉載或引用時請指明出處。如果你對文檔有疑問或問題，請在項目中給我留言或發email到 weiwei02@vip.qq.com 我的github: https://github.com/weiwei02/ 我相信技術能夠改變世界 。

鏈接

• 上篇文章Spring Cloud Task 5 Spring Batch數據分片探究
• 下篇文章正在準備中

轉載于:https://my.oschina.net/weiwei02/blog/1825632

總結

以上是生活随笔為你收集整理的[Spring Cloud Task]6 Spring Batch批处理应用设计原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。