zookeeper中myid有用嗎？myid的值是文件里定義方法的server.A項A的值，Zookeeper正常啟動時會加載這個文件，拿回里面的數(shù)據(jù)與里面的配置信息比較比較使判斷不知道是那個serv

zookeeper中myid有用嗎？

myid的值是文件里定義方法的server.A項A的值，Zookeeper正常啟動時會加載這個文件，拿回里面的數(shù)據(jù)與里面的配置信息比較比較使判斷不知道是那個server，能起一個標識作用。

在系統(tǒng)中增加quartz定時任務集群，tomcat集群會多次執(zhí)行，怎么解決呢？

做過的的的功能，不一定會也得用分布式定時任務，應該要特點項目實際來選擇類型具體的解決方案；從最簡單說起來，給大家介紹幾個（不要先選高端大氣上檔次的方案，比較適合最重要）。

諸如數(shù)據(jù)庫中每天晚上都會有一百萬條數(shù)據(jù)待處理，一個定時任務（記為A）要如何處理完這一百萬條數(shù)據(jù)，要10個小時；如果想減緩這個處理速度，我們首先能想到的是多部署一個批處理程序（記為B），這時候理論上要10/25個小時，也可以把任務都一次性處理完。

方案一：待一次性處理任務表增加一個去處理標志的字段，比如0待如何處理，1一次性處理中，2全面處理結束；當A任務取到待一次性處理數(shù)據(jù)的時候，將此字段更新完成1，處理完之后更新成2；當字段1/2的時候，B任務應該不會取到這條數(shù)據(jù)；不過這種方法的問題極大，而且非常容易發(fā)生了什么一條待如何處理任務在被A可以查詢到，但未更新全面處理狀態(tài)前，就被B任務取到，這樣的可能會造成重復一遍處理的問題。

方案二：把處理任務通過人所的劃分，A去處理一批數(shù)據(jù)，B處理一批數(shù)據(jù)。是可以從純數(shù)據(jù)角度劃分，諸如id的A處理，id!的B全面處理，也可以從業(yè)務角度劃分，諸如某個字段across(A,B,C)的A處理，某個字段across(X,Y,Z)的A如何處理；這樣的話做絕對不會導致數(shù)據(jù)反復重復一次性處理，但是也有一些問題：

數(shù)據(jù)不當然能平均分配，例如字段into(A,B,C)的數(shù)據(jù)有90萬條，字段of(X,Y,Z)的有10萬條。

未必能擴展，畢竟條件是寫死的，所以才如果要增加下降機器的話比較麻煩您；

假如其中一臺機器直接掛掉，那就這部分數(shù)據(jù)就不可能一次性處理。

方案三：方案一改進看看，提升分布式鎖（也可以是數(shù)據(jù)庫、Redis、ZK），誰能搶完鎖，誰才能分離提取待全面處理任務，并更新完去處理狀態(tài)，比如說三次提取一萬行數(shù)據(jù)，并把這些數(shù)據(jù)的待如何處理狀態(tài)可以更新成【一次性處理中】，接著把鎖釋放者掉，再由其他的節(jié)點搶鎖。這種方案是需要確定的東西也許多：

要考慮到鎖超期的問題：假如A搶鎖，還沒施放鎖之前A就直接掛掉了，這樣所有任務都會被卡主。

如果鎖未交被施放掉，A一次性處理到一半的任務還必須被其他任務如何處理（突然失效轉移到）。

也可以和方案二加強，做任務分片，批處理程序搶到鎖后，如何領取一個任務分片接受處理。

方案四：再按結構分布式任務處理框架，我十分了解的那是Elastic-Job了，它的功能極為極為強大，不過主要注意的功能嘛，你能再理解前三個方案的話，這個方案也就淺顯易懂了（基本是上面那些東西）。

我將減弱分享分享Java開發(fā)、架構設計、程序員職業(yè)發(fā)展等方面的見解，我希望能換取你的關注。