目前我在CPSubsystem. ----- | I1* | * Leader ----- ---- ---- | I2 | | I3 | ---- ---- 當(dāng)所有實例都啟動運行時，所有實例都已注冊并相互查看，CPSubsystem一切都按預(yù)期工作。以下調(diào)用用于在所有實例之間執(zhí)行分布式鎖：getHazelcastInstance().getCpSubsystem().getLock(lockDefinition.getLockEntryName())當(dāng)其中兩個實例死亡時，我注意到一個問題，并且沒有領(lǐng)導(dǎo)者或其他實例可用于執(zhí)行領(lǐng)導(dǎo)者選舉： ----- | XXX | * DEAD ----- ---- ----- | I2 | | XXX | * DEAD ---- ----- 正在運行的實例然后嘗試獲取分布式鎖，但是請求凍結(jié)執(zhí)行該getLock方法，導(dǎo)致請求排隊幾分鐘（當(dāng)實例成為子系統(tǒng)中的唯一實例時需要配置超時）。我還注意到以下日志被永久打?。?019-08-16 10:56:21.697 WARN 1337 --- [ration.thread-1] Impl$LeaderFailureDetectionTask(default) : [127.0.0.1]:5702 [dev] [3.12.1] We are FOLLOWER and there is no current leader. Will start new election round...2019-08-16 10:56:23.737 WARN 1337 --- [cached.thread-8] c.h.nio.tcp.TcpIpConnectionErrorHandler : [127.0.0.1]:5702 [dev] [3.12.1] Removing connection to endpoint [127.0.0.1]:5701 Cause => java.net.SocketException {Connection refused to address /127.0.0.1:5701}, Error-Count: 1062019-08-16 10:56:23.927 WARN 1337 --- [ration.thread-1] Impl$LeaderFailureDetectionTask(default) : [127.0.0.1]:5702 [dev] [3.12.1] We are FOLLOWER and there is no current leader. Will start new election round...有沒有辦法識別實例現(xiàn)在是單獨運行的，如果是這樣，在獲取新鎖的過程中不要阻塞應(yīng)用程序？我一直在尋找某種機(jī)制來不以任何方式阻止應(yīng)用程序的流程，即使應(yīng)用程序單獨運行我也會使用常規(guī)而j.u.c.l.ReentrantLock不是FencedLock.
2 回答
海綿寶寶撒
TA貢獻(xiàn)1809條經(jīng)驗 獲得超8個贊
CP 子系統(tǒng)旨在在沒有足夠的成員可用于首先形成 CP 子系統(tǒng)時阻止對屬于 CP 子系統(tǒng)系列的數(shù)據(jù)結(jié)構(gòu)的所有操作。此屬性由CPSubsystemConfig.setCPMemberCount(int)
hazelcastInstance.getCPSubsystem().getCPSubsystemManagementService().getCPMembers()將為您提供集群中的 CP 成員。
要確定集群成員計數(shù)，您可以hazelcastInstance.getCluster().getMembers()對成員加入或離開事件使用和/或使用 MembershipListener。
慕碼人2483693
TA貢獻(xiàn)1860條經(jīng)驗 獲得超9個贊
經(jīng)過幾天的測試，我得出以下結(jié)論：
但是
CPSubsystem需要至少三個模塊才能開始工作，運行兩個實例就可以了在我提出的最災(zāi)難性的可能場景中（只有一個實例在運行），沒有什么可做的，你的環(huán)境可能有一個 ruff 時間，需要某種干預(yù)或關(guān)注來解決這個中斷
我決定在這種情況下阻止請求被滿足，以保持模塊之間所有操作的一致性。
所以方法如下：
try {
? ? if( !hz.isCpInstanceAvailable() ) {
? ? ? ? throw new HazelcastUnavailableException("CPSubsystem is not available");
? ? }
? ? ... acquires the lock ...
} catch (HazelcastUnavailableException e) {
? ? LOG.error("Error retrieving Hazelcast Distributed Lock :( Please check the CPSubsystem health among all instances", e);
? ? throw e;
}
該方法isCpInstanceAvailable將執(zhí)行三個驗證：
如果當(dāng)前應(yīng)用程序注冊在
CPSubsystem如果
CPSubsystem是如果在
CPSubsystem
所以這是解決方案：
protected boolean isCpInstanceAvailable() {
? ? try {
? ? ? ? return getCPLocalMember() != null && getCPMembers().get(getMemberValidationTimeout(), TimeUnit.SECONDS).size() > ONE_MEMBER;
? ? } catch (InterruptedException | ExecutionException | TimeoutException e) {
? ? ? ? LOG.error("Issue retrieving CP Members", e);
? ? }
? ? return false;
}
protected ICompletableFuture<Collection<CPMember>> getCPMembers() {
? ? return Optional.ofNullable(getCPSubsystemManagementService().getCPMembers()).orElseThrow(
? ? ? ? ? ? () -> new HazelcastUnavailableException("CP Members not available"));
}
protected CPMember getCPLocalMember() {
? ? return getCPSubsystemManagementService().getLocalCPMember();
}
問題來了，簡單地調(diào)用getCPMembers().get()會導(dǎo)致我遇到的長時間暫停（默認(rèn)超時）。
所以我使用了getCPMembers().get(getMemberValidationTimeout(), TimeUnit.SECONDS)，如果調(diào)用超過預(yù)期超時，它將拋出錯誤。
添加回答
舉報
0/150
提交
取消