Hazelcast’s Replication Algorithm For AP Data Structures

Giriş

Açıklaması şöyle. İşlem önce birincil (primary) üzerinde gerçekleşir, daha sonra da senkron veya asenkron olarak yedek üzerinde gerçekleşir. 

 In the context of CAP principle, Hazelcast offers AP and CP functionality with different data structure implementations. Data structures exposed under HazelcastInstance API are all AP data structures. Hazelcast also contains a CP subsystem, built on the Raft consensus algorithm and accessed via HazelcastInstance.getCPSubsytem() which provides CP data structures and APIs.

For AP data structures, Hazelcast employs the combination of primary-copy and configurable lazy replication techniques. ..

When you read or write a map entry, you transparently talk to the Hazelcast member to which primary replica of the corresponding partition is assigned. By this way, each request hits the most up-to-date version of a particular data entry in a stable cluster. Backup replicas stay in standby mode until the primary replica fails. Upon failure of the primary replica, one of the backup replicas is promoted to the primary role.

With lazy replication, when the primary replica receives an update operation for a key, it executes the update locally and propagates it to backup replicas. It marks each update with a logical timestamp so that backups apply them in the correct order and converge to the same state with the primary. Backup replicas can be used to scale reads (see the Enabling Backup Reads section) with no strong consistency but monotonic reads guarantee.

Burada önemli olan şey eğer transaction mantığıyla düşünürsek, transaction birincil üzerine başlar ve biter, daha sonra yedeğe uygulanır. Yani replica çökse, bağlantı kaybolsa bile transaction'a sadece primary açısından bakıldığı için işlem başarılıdır. Yani birincil ile yedek arasında geride kalma (lag) vardır.

Senkron ve Asenkron Replication

Senkron veya asenkron şu anlama gelir. Senkron ise yedeğe gönderme isteminin cevabı belli bir süre beklenir. Asenkron ise at ve unut tarzı çalışır. Yedekten cevap beklenmez.

Senkron Replication

Açıklaması şöyle. Yani birincil, işlemi yedeğe de gönderir ve cevabı 5 saniye bekler. Eğer yedek 5 saniye içinde cevap vermezse, de birincil yoluna devam eder. 

When backup updates are propagated, the response of the execution, including the number of sync backup updates, is sent to the caller and after receiving the response, the caller waits to receive the specified number of sync backup acknowledgements for a predefined timeout. This timeout is 5 seconds by default and defined by the system property hazelcast.operation.backup.timeout.millis.

A backup update can be missed because of a few reasons, such as a stale partition table information about a backup replica member, network interruption, or a member crash. That’s why sync backup acks require a timeout to give up.

Consistency Guarantees

Strong consistency sağlamaz. Bu da veri kaybı (data loss) olabileceği anlamına gelir. Çünkü yazma gerçekleştikten hemen sonra birincil çökerse, yedeğin artık en son güncel veriyi alma şansı yoktur. Açıklaması şöyle

Best Effort Consistency

The replication algorithm for AP data structures enables Hazelcast clusters to offer high throughput. However, due to temporary situations in the system, such as network interruption, backup replicas can miss some updates and diverge from the primary. Backup replicas can also hit VM or long GC pauses, and fall behind the primary, which is a situation called as replication lag. If a Hazelcast partition primary replica member crashes while there is a replication lag between itself and the backups, strong consistency of the data can be lost.

Please note that CP systems can have similar problems as well. However, in a CP system, once a replica performs an update locally (i.e., commits the update), the underlying consensus algorithm guarantees durability of the update for the rest of the execution.

On the other hand, in AP systems like Hazelcast, a replica can perform an update locally, even if the update is not to be performed on other replicas. This is a fair trade-off to reduce amount of coordination among replicas and maintain high throughput & high availability of the system. These systems employ additional measurements to maintain consistency in a best-effort manner. In this regard, Hazelcast tries to minimize the effect of such scenarios using an active anti-entropy solution as follows:

- Each Hazelcast member runs a periodic task in the background.

- For each primary replica it is assigned, it creates a summary information and sends it to the backups.

- Then, each backup member compares the summary information with its own data to see if it is up-to-date with the primary.

- If a backup member detects a missing update, it triggers the synchronization process with the primary.