q昨天到今天一直被quartz集群?jiǎn)栴}困擾
正常情況下集群下的多臺(tái)quartz服務(wù)只有一個(gè)在工作。但是我測(cè)試的情況是每個(gè)服務(wù)都已是集群上的一個(gè)節(jié)點(diǎn)，數(shù)據(jù)庫(kù)中也看了節(jié)點(diǎn)狀態(tài)的記錄。但是每臺(tái)服務(wù)都是各干各的沒(méi)有集群的效果。過(guò)程比較坎坷
網(wǎng)上資料都沒(méi)有找到這一項(xiàng)說(shuō)明
確定使用的數(shù)據(jù)庫(kù)后，
quartz.dataSource.myDS.provider? 配置數(shù)據(jù)庫(kù)提供者
quartz.dataSource.myDS.connectionString 配置數(shù)據(jù)庫(kù)連接字符串
quartz.jobStore.driverDelegateType 配置數(shù)據(jù)庫(kù)的委托類型，這個(gè)很重要，每個(gè)數(shù)據(jù)庫(kù)的語(yǔ)言都有些不一樣，選擇適合的委托類型。具體的到源碼中找即可。
劃重點(diǎn)====
還發(fā)現(xiàn)一個(gè)問(wèn)題。在調(diào)試的時(shí)候都是正常的，但是放到 docker中出現(xiàn)了事務(wù)連接的問(wèn)題。后來(lái)我主動(dòng)引入mysql.data最新的庫(kù)（8.0.19）解決了。
數(shù)據(jù)庫(kù)的版本太高，導(dǎo)致quartz.net引入的mysql.data庫(kù)不支持我可以理解。但是同樣的云端數(shù)據(jù)庫(kù)，本地一樣去連接，不適用最新的庫(kù)也沒(méi)問(wèn)題。
就有點(diǎn)朦。有可能是發(fā)布的問(wèn)題，本地可能有引入操作系統(tǒng)中的庫(kù)，docker上部署的是框架依賴配置的發(fā)布版。docker上不可能有mysql的服務(wù)組件?？赡苁沁@個(gè)問(wèn)題引起的。。
更重點(diǎn)================================================
今天重新試了下，昨天寫的純屬扯淡
網(wǎng)上找了一篇博客完全解決了這個(gè)問(wèn)題（https://blog.csdn.net/sinat_38740436/article/details/91895416）
quartz.jobStore.misfireThreshold 這個(gè)值要小于 定時(shí)執(zhí)行任務(wù)的周期，比如quartz.jobStore.misfireThreshold=60000一分鐘，但是我5秒鐘執(zhí)行一次定時(shí)任務(wù)，這種配置在集群下是不起作用的。所以要將?quartz.jobStore.misfireThreshold的值設(shè)置小于定時(shí)任務(wù)的周期就解決了這個(gè)問(wèn)題
數(shù)據(jù)庫(kù)連接問(wèn)題也大概有了結(jié)果，放到云服務(wù)器上，我數(shù)據(jù)路的host如果以外網(wǎng)的域名連接就是連接不上。但是我改成內(nèi)網(wǎng)的ip又可以了。。。暫時(shí)就不管這個(gè)問(wèn)題了。卸載了8.0.19的mysql.data.dll，用默認(rèn)的庫(kù)也是完美執(zhí)行。應(yīng)該不是庫(kù)版本的問(wèn)題。。在quartz.net3.07發(fā)布的 時(shí)候，8.0.19的版本還沒(méi)出來(lái)
