定時任務在系統中并不少見，主要目的是用于需要定時處理數據或者執行某個操作的情況下，如定時關閉訂單，或者定時備份。而常見的定時任務分為2種，第一種：固定時間執行，如：每分鐘執行一次，每天執行一次。第二種：延時多久執行，就是當發生一件事情后，根據這件時間發生的時間定時多久后執行任務，如：15分鐘后關閉訂單付款狀態，24小時候后關閉訂單并且釋放庫存，而由于第二種一般都是單一數據的處理（主要是指數據量不大，一般情況下只有一個主體處理對象，如：一個訂單以及訂單中的N個商品），所以一般情況下第二種出現性能問題的幾率不大（不代表沒有），所以本文主要是針對第一種定時任務來進行優化，而且主要是針對數據同步或者傳遞數據來進行優化，而優化的方式也是根據實際項目中的情況在不同階段進行優化的

第一階段屬于原始階段，邏輯也最為簡單，由于同步分為數據同步和傳遞數據，而且2種的需求各不一致（主要是在于是否允許丟失），所以分開分析

由于傳遞數據可以允許丟失，常見的場景如調用憑證推送（常見于接口需要暴露給第三方，為了安全性，可以定時推送調用憑證來保證接口安全性），消息推送（訂單消費成功后推送消息，由于可能推送失敗，所以需要進入定時任務進行重試，但是因為消息實時性，所以重試到一定次數后放棄重試）

傳遞數據在第一階段設計非常簡單，定時推送，有限的錯誤次數，同步成功后修改狀態，同步失敗后對失敗次數+1，一旦超過錯誤次數，就不在繼續嘗試

同步數據跟傳遞數據不同點在于同步數據一定需要保證數據能投遞成功，否則就要一直進行重試，比如2個系統間的訂單同步，會員信息同步等

同步數據再第一階段也非常簡單，定時同步數據，失敗就設置同步狀態為同步失敗，每次同步就只查詢狀態為未同步和同步失敗記錄

一開始需要傳遞或者同步的系統很少，數據也少，所以沒有什么問題，但是第二階段不一樣了，數據量稍微有所新增，但是增量不大，主要是需要同步的系統多了，打個比方，連鎖商店，總部需要把數據下傳到所有門店去，這樣門店就不用每次去總部獲取數據，這樣太耗費時間了，當然門店每次從總部獲取到數據可以緩存到本地，不過跟本文內容關系不大，所以這里不再討論。由于需要同步的系統太多，所以延伸出另外一個問題，一旦一個系統的網絡環境不好，會影響其他系統數據同步，所以在第二階段，引入了黑名單機制，由于黑名單機制對于傳遞數據和同步數據大致相同，所以這里就不分開描述，有差異性的地方也會指出

黑名單分二級：

第一級用于控制本次定時任務，當本次運行定時任務時，不同的接受數據服務器可能有0-N條數據需要同步，所以一旦進入第一級黑名單后，本次后面都不會向接受數據服務器發起請求，而是直接失敗；

第二級用于控制多長時間內不進入重試，是控制整個的，從查詢需要同步的數據時候就直接過濾并且設置為同步失敗狀態（傳遞消息需要對失敗次數加1）

首先第一級，當請求不到接受數據的服務器的時候（鏈接失敗，或者鏈接超時），會再重試2次（傳遞數據由于及時性要求，所以不會重試，并且超時時間也會合理的減少），如果2次都同步失敗，這判斷本條數據同步失敗，并且進入第一級黑名單，并且判斷一定時間內進入了幾次第一級黑名單，具體使用redis控制，首先是否進入第一級黑名單直接程序中存儲就好，一定時間段內進入了幾次黑名單，就使用有序集合保存，排序的分值就存儲當前時間戳

進入第一級黑名單后，使用一定時間內進入幾次的限制條件，來判斷是否進入第二級黑名單，比如5分鐘進入3次第一級黑名單，就進入第二級黑名單，那么就查詢分值大于5分鐘前時間戳的數據集合，如果集合結果有3條或以上數據了，那么就進入第二級黑名單，同時清理掉redis中關于第一級黑名單存儲的數據，如果沒有3條數據，那么就刪除分值小于5分鐘前的時間戳的數據，避免垃圾數據過多

使用黑名單機制，可以有效避免一些因為服務本來不可訪問導致一直還重試的問題，并且由于有二級黑名單，所以也一定程度上避免了因為暫時網絡波動，導致數據長久無法同步的問題

由于需要傳遞的數據和需要同步數據的服務越來越多，并且由于各種問題導致很多數據不能一次性同步成功，所以每次定時任務都需要同步大量數據，這樣就導致及時性很差了，比如幾千條數據同步下來，就算一條只需要幾十毫秒，從開始到最后一條數據同步成功也是幾十秒之后了，所以需要再次對定時任務進行優化，數據量大而導致同步慢原因很簡單，是由于單個線程串行同步的，也就是說必須要上一條數據處理了才能處理下一條數據，所以可以使用多線程來優化，提高硬件使用率

當然肯定不可能給每條數據創建一個線程，先不說得創建多少條線程，僅僅是創建線程的消耗就已經很大了，而且線程數量太多，頻繁切換線程上下文也會導致性能損耗，所以最合適的就是將數據分配到機器CPU核心數量的線程，或者核心數量*2的線程上去處理更合適，當然具體情況具體分析，最好還是具體測試得出合適的線程數量，同時由于肯定是會存在多個定時任務，所以可以多個定時任務使用同一個線程池，但是每個任務只使用合適線程數量來處理

線程數據分配原則

同一個被接受調用的數據的服務器的數據肯定是分配到一個線程中去處理，比如要分配8個線程來處理，那么可以創建8個集合，先保存查詢出來需要被同步的數據，同時查詢出來的數據根據被接受數據的服務器標識排序，用接受數據的服務器標識的hash值來%8來確定放入哪個集合，或者使用輪詢的方式放入指定集合，分配好之后則創建8個runable放入線程池中去執行

防止定時任務疊加

開啟多線程處理后，由于主線程在把任務放入線程池中運行的時候就會返回了，所以一定需要防止定時任務疊加，比如任務是10秒執行一次的，每次定時任務本身的線程只執行了1秒，下次定時任務的時候會發現定時任務已經處理完成，但是實際上真正同步數據的8個線程都沒有執行完成，就會出現一條數據重復同步，或者把數據累加到上次任務的集合中去（看具體的處理方式導致不同的結果），最后就跟滾雪球一樣，整個服務就算不崩潰，也會出現各種問題，或者就是浪費大量資源去做重復同步，所以為了防止任務疊加，需要使用閉鎖來防止定時任務本身返回的情況，同時使用閉鎖也要注意處理異常的情況，防止發生異常后，閉鎖沒有執行操作，導致定時任務一直不能返回

閉鎖

使用閉鎖防止定時任務返回，8個線程的情況下創建閉鎖

CountDownLatch latch = new CountDownLatch(8);

每個線程執行完數據后需要countDown方法來通知，或者叫關閉一個柵欄吧，創建閉鎖的傳入的8我們可以看成創建了8個柵欄

latch.countDown();

同時在定時任務的線程中，需要等待所有柵欄關閉才能繼續執行，所以需要調用方法

latch.await();

這樣只有所有線程執行完成后，定時任務的線程才會繼續執行，防止任務疊加

使用多線程了，一定要注意多線程的一些線程安全以及其他的一些問題，如果對閉鎖和多線程本身不夠了解的話，可以自行去查閱一些相關資料

數據量非常大，接受數據的服務也非常多

一臺服務器的硬件資源始終有限，尤其是網絡資源，由于接受數據的服務不一定是內網服務，加上各種問題導致鏈接失敗，所以數據量大的情況下，就算使用了多線程，還是會造成數據延遲很久才同步成功（主要延遲原因是網絡問題），這時候就需要使用多臺服務器了，而使用多臺服務器定時執行就存在一個問題，數據分片，簡單來說怎么保證一條數據只能被一臺服務器處理，數據分片有2種方式，第一種：不同服務器處理不同的表的數據。第二種：數據本身主鍵或者某種標志分配處理

2種處理方式有各自的優缺點

優點：簡單，只需要簡單拆分或者配置即可

缺點：無法擴展更多，最多只能可能擴展到數據表數量臺服務器，并且對于熱點數據無法更優處理，比如訂單這些熱點數據，始終都在一臺服務器

優點：理論上可無限擴展，可以針對熱點數據專門擴展

缺點：配置麻煩，每次新增服務器需要重新配置

由于第一種配置簡單，而且擴展性不強，所以本文主要講述第二種方式的實現；

如果所有數據有生成都有自增型主鍵id，那么最簡單也最公平的就是給每臺服務器配置一個從0開始連續的服務器id，每臺服務器查詢數據的時候加一個條件id%服務器臺數=當前服務器id，注意這樣會導致id列的索引可能無法命中（根據數據庫不同，是否命中情況不一致），這樣配置的好處就是絕對公平，每臺服務器分配到的數據量是平等的，壞處就是一臺服務器可能會給所有接受數據服務發起請求，無法更好的利用鏈接復用，另外也無法針對服務器配置來增加或者降低權重（當然可以一個服務器配置2個id的方式來實現，但是這樣也不友好）

如果為了更好的利用鏈接復用，可以使用先計算出接受數據服務標志的hashcode值，然后跟進hashcode值%服務器臺數=當前服務器id的形式，這樣就可以將接受數據服務分組式的配置到某個服務器上去處理，當然如果接受數據服務本身存在很大的數據量差異，就不推薦這種方式了，畢竟這樣容易把大量數據堆積到某臺服務器上去處理

當然還有其他多種分片的配置方式，比如采用表配置的方式來配置哪臺服務器處理哪些數據，也可以使用上面種方式的結合體，可以根據具體情況分析到底怎么樣才能更適合的進行數據分片處理，當然常規情況下，采用id%服務器的臺數是能滿足大部分需求的

當系統針對性能優化到一定程度的時候，就可以考慮從業務或者其他方面進行優化了，比如一旦有系統進入二級黑名單了，就發出警告通知，或者沒有進入二級黑名單，但是卻經常進入一級黑名單，也提出一個報警，這樣可以讓人去排查原因，確認是程序問題還是網絡本身的問題。另外也可以設置一個閾值，某個接受數據的服務一直響應很慢，或者經常響應時間超過某個閾值的時候，可以考慮進行降權處理，或者排查程序已經網絡相關的原因

以上就是java 定時同步數據的任務優化的詳細內容，更多關于Java 定時任務的資料請關注好吧啦網其它相關文章！