微服務架構的同步代碼塊

Question

我們有一個方法需要同步所有微服務實例的代碼塊。

DynamoDB 示例中的 MyEntity（類）：

field1(Partition Key), field2(Sort Key), isPrimary
1                           1               true
1                           2               false
1                           3               false
2                           1               true
2                           2               false
3                           2               true

基於 field1 的一種類型的值可以是主要的，它是根據 field2 決定的。

就像，在所有 1 中，一個將是主要的，依此類推，對於 field1 中的 2s 和 3s，這是根據 field2 的值決定的。

如果 field1 的值在整個表中是新的，那么基於 FCFS 邏輯它將成為主要的。

問題：問題出在微服務架構中，如果多個實例試圖插入具有相同字段 1 值但表中不存在的實例，那么它們最終可能會將兩者都設為主要實例。 由於我們使用的是 DynamoDB，因此不能對表施加約束。

public MyEntity saveMyEntity(MyEntity myEntity) {
    if (!myEntity.isPrimary()) {
        synchronized (myEntity.getField1().intern()) {
            if (!existsByField1(myEntity.getField1())) {
                myEntity.setPrimary(true);
            }
        }
    }
    dynamoDBMapper.save(myEntity);
    return myEntity;
}

private boolean existsByField1(String field1){
    //checks if field1 value exists in table column field1.
}

嘗試進行塊級同步，但它只適用於同一實例，不適用於其他實例。

如何實現微服務級別的代碼塊同步？

Answer 1

您正在尋找的是分布式鎖定：您使用高度一致的可線性化數據存儲來管理鎖。 此類商店的示例包括 zookeeper、etcd 和 consul。 您也可以通過讓實例相互通信並實現像 Raft 或 Paxos 這樣的共識協議來自己實現它（盡管必須說滾動自己的共識協議與滾動自己的密碼學屬於類似的類別：作為學習很有用鍛煉，但可能不是您在生產中應該想要的東西）。

請注意，這里的一致性要求（我假設如果有多個初選真的很糟糕）意味着存在不可避免的情況，您的系統將至少在一段時間內停止運行（例如實例服務在持有鎖時停止或崩潰）。 您可以減少那段時間，但這樣做通常意味着增加多個主節點的風險，因為沒有簡單的方法來保證持有鎖的實例實際上沒有對它做任何事情。