AerospikeC client manual-transaction-level consistency assurance

AerospikeC client manual-transaction-level consistency assurance
Zookeeper
Transaction-level consistency is guaranteed as a distributed database. Aerospike supports automatic data replication. Most often, the database is configured to maintain two identical copies for each record. That is to say, "The replication factor is 2. The server also supports other replication factors and is configured based on namespace.
(For more details about data replication, see the Aerospike architecture topic data distribution ])
Automatic data replication provides high performance and fault tolerance system advantages, but increases transaction latency (potential) consumption. The delay consumption of read transactions generally occurs in the cluster reconfiguration phase, and the copy may not be synchronized to the latest copy. The write transaction delay is affected by the replication factor, because the commit modification to the slave copy on a node other than the master replica server increases the internal communication in the cluster.
Each transaction operates on all copies to ensure full data consistency. However, it is often advisable to choose to run at a lower consistency level, which means that transaction processing does not necessarily access all copies of a record.
The default behavior of the Aerospike server/client is the most common choice to provide consistency assurance:

By default, read transactions only view a single copy, even during cluster reconfiguration.

Write transactions (including deletion and UDF applications) commit all copies synchronously by default, and then return the transaction success.

This option works well when reading and synchronizing all copies of a single copy, providing Aerospike with instant consistency with low latency.

However, application developers sometimes want to change the system's default copy-related behaviors in their own applications.

Note: Even if consistency guarantee is lower than the highest level, data read/write is likely to be regarded as consistent. For the sake of speed, a low consistency guarantee level is used, but a short time window is opened. In this window, the data involved in a transaction is viewed from the entire cluster range, it may be inconsistent for the moment. Whether this trade-off is acceptable depends entirely on the Application Designer.

In the read scenario, a lower consistency guarantee is used, and subsequent reads may return previous values of records. (This is possible, for example, because the cluster is being reconfigured and the master copy is not the latest copy .)

In the write scenario, a low consistency guarantee is used. During the period when the master copy has been submitted and the slave copy has not been submitted, the previous value of the record may be read ("Dirty read ").

To maximize application flexibility, Aerospike provides optional transaction-level consistency assurance. The copy-related policy allows applications to choose between the required performance and consistency assurance.

Copy and consistency assurance policies

The Aerospike C client provides three replica and consistency assurance policies: 1) read replica selection (read replica); 2) read consistency level (read consistency level); 3) write commit level ).

Application developers can specify the desired copy selection and consistency assurance level policy. They can set a connection level global policy in the client configuration, or specify a transaction level policy when calling a separate C-client API function. The default value is used for the policy that has not been modified by the application. Internally, the C client uses these policy settings to send appropriate line protocol commands to the server.

Read copy selection policy

Read copy selection policy, which is set by read. replica and applied to read operations. It specifies which copy the client accesses when reading data.

By default, the primary copy is read ).

Another option is to read one of the replicas (any ). (In fact, one is randomly selected for read)

Read consistency Level Policy

The read consistency level policy is set by read. consistency_level and applied to read-related operations. Specify the number of copies on the server to check the latest record value and return it to the client.

The default value is read one ).

The other option is to read all (all ).

Write submission Level Policy

Write submission guarantee, which is set by write. commit_level and applied to any write-related operations. Specify the number of copies that the server must successfully submit before returning to the client.

The default value is to submit all (all) and copy the data before the return.

Another option is to return the result when only the master copy (master) is submitted and asynchronously replicated to each slave copy.

Horizontal coverage principle of server consistency assurance

Ensure transaction-level consistency selected by the client, covering the relevant parameters that can be dynamically configured at the namespace level on the server side. (Note: The read copy selection policy is limited to the client, so there is no server overwrite Statement)

For more information, see the consistency overwrite parameters section in the server topic in the configuration reference manual.

Sample Code for transaction-level consistency assurance policy usage

To use any copy selection or consistency assurance policy, you must first create and initialize a client connection:

as_config config;as_config_init(&config);// [(A): Non-default policies may be set on 'config.policies' here.]aerospike client;aerospike_init(&client, &config);as_policies *p_policies = &client.config.policies;// [(B): Non-default policies may be set via 'p_policies' here.]

The policies in the config object will be initialized to the Default policy value and used to initialize the client object.

You can use config. policies in [A] To set non-default policies before initializing client objects.

After the client object is initialized (for example, [B]), you can change the client connection policy settings, retrieve the es pointer (p_policies), and use the pointer to obtain and set individual policies.

Set Client Connection-level policies

The following three sections describe how an application selects non-default policy behavior at the client connection level.

Select to read any copy

By default, all client reads will be directed to the master copy (policy value: AS_POLICY_REPLICA_MASTER ). However, in some scenarios, read may need to be distributed to all available copies. (For example, to reduce the performance impact of reading hot keys, it can be reduced by about multiple replication factors ). In this scenario, the application can choose to read any copy ("random") and set the read. replica policy to AS_POLICY_REPLICA_ANY:

p_policies->read.replica = AS_POLICY_REPLICA_ANY;

Choose high read consistency assurance

The Default Client record read behavior (including read and operation of API functions) is to read only one copy (policy value: AS_POLICY_CONSISTENCY_LEVEL_ONE, specified by read. replica ). However, when the cluster is reconfigured, a value other than the latest version is returned if only one copy is read. In the scenario where the maximum read consistency level is required, set the policy read. consistency_level to AS_POLICY_CONSISTENCY_LEVEL_ALL:

p_policies->read.consistency_level = AS_POLICY_CONSISTENCY_LEVEL_ALL;

Note: The potential performance impact of reading all copies is significant only during cluster reconfiguration.

Low write consistency

The Default Client record modification behaviors (such as writing, removing, operating, and applying udf api functions) are returned after the modification is successfully submitted to all copies. This default policy (AS_POLICY_COMMIT_LEVEL_ALL) ensures the highest level of write consistency.

If a low write latency is required, and the application can tolerate a low write consistency guarantee (there is a possibility of "Dirty read", such: reads the record value from an uncommitted non-primary copy, and may read back an old value) and sets write. the comit_level policy is AS_POLICY_COMMIT_LEVEL_MASTER:

p_policies->write.commit_level = AS_POLICY_COMMIT_LEVEL_MASTER;

Ensure transaction-level consistency

The sample code above defines the global policies used by the customer connection level. To set a transaction-level policy, you can set the required policy as a parameter and pass it to a single API call. For example, if you use the master copy to submit (master) to ensure the level of writing records, follow these steps:

as_policy_write my_write_policy;as_policy_write_init(&my_write_policy);my_write_policy.commit_level = AS_POLICY_COMMIT_LEVEL_MASTER;// [...Define other variables, etc...]as_status status = aerospike_key_put(&as, &err, &my_write_policy, &key, &rec);

The policy specified on a single API call. If it is not NULL, it overwrites the corresponding policy settings at the client connection level. (Note: if the corresponding server settings are set, the client policy settings will be overwritten ).