Shulou(Shulou.com)06/02 Report--

Kong clustering allows you to scale out the system by adding more machines to handle more incoming requests. They will share the same configuration because they point to the same database. Kong nodes that point to the same data store will belong to the same Kong cluster.

You need to install a load balancer in front of the Kong cluster to distribute traffic among available nodes.

What can and cannot be done by Kong clusters

Having a Kong cluster does not mean that your client traffic will be load balanced out of the box between your Kong nodes. You still need to install a load balancer in front of the Kong node to distribute traffic. Instead, Kong clustering means that these nodes will share the same configuration.

For performance reasons, Kong avoids database connections when proxying requests and caches the contents of the database in memory. Cached entities include services, routing, consumers, plug-ins, credentials, etc. Because these values are in memory, any changes made through the administrative API of one of the nodes need to be propagated to the other nodes.

This document describes how to invalidate these cached entities and how to configure Kong nodes for a use case that lies between performance and consistency.

Single node cluster

A single Kong node is connected to the database to create a single-node Kong cluster. Any changes applied through the administrative API of this node will take effect immediately.

Consider a separate Kong node A. If we delete the previously registered service:

$curl-X DELETE http://127.0.0.1:8001/services/test-service

Then, any subsequent requests to node A will immediately return 404 Not Found because the node clears it from the local cache.

Multi-node cluster

In the case of multiple Kong nodes in a cluster, other nodes connected to the same database are not immediately notified that the service has been deleted by node A. Although the service is not in the database (deleted by node A), it is still in the memory of node B.

All nodes perform a periodic background job to synchronize changes that may be triggered by other nodes. The frequency of this job can be configured in the following ways:

Db_update_frequency (default: 5 seconds)

Every db_update_frequency second, all running Kong nodes poll the database for any updates and, if necessary, purge related entities from the cache.

If we remove a service from node A, the change will not be valid in node B until the next database poll of node B, which will occur in a few seconds until db_update_frequency (though possibly faster).

This makes the Kong cluster ultimately consistent.

The construction of cluster

Kong clusters were created and maintained through the cluster command in the early days, and the way clusters are built has been changed since version 0.11. Reference document Kong 0.11 changeLog.

After the cluster management function was removed from version 0.11, Kong became completely stateless, and as long as the nodes connected to the same Kong database were considered to be the same Kong cluster without additional communication mechanism, there was no need to configure cluster parameters in the kong.conf file.

The construction of the Kong cluster is to put all the Kong nodes together with a Kong database, and all the results are read from the database through the polling mechanism to ensure data consistency.

What is caching?

All core entities, such as services, routing, plug-ins, consumers, and credentials, are cached by Kong and depend on their failure through the polling mechanism to be updated.

In addition, Kong caches the misses of the database. This means that if you configure a service without a plug-in, Kong will cache this information. Example:

Suppose we add a plug-in to the service through the administrative API of node A:

# node A $curl-X POST http://127.0.0.1:8001/services/example-service/plugins\-- data "name=example-plugin"

Because this request is made through the Admin API of node A, node An invalidates its cache locally and detects that the API is configured with a plug-in in a subsequent request.

At this point, Node B has not yet run the database synchronization update cache task, and still caches the data that the API does not have a plug-in to run. This will be the case until Node B runs its database polling job.

Conclusion: all CRUD operations trigger cache invalidation. Creating (POST, PUT) will invalidate the error of the cache database, while update / delete (PATCH, DELETE) will invalidate the error of the cache database.

How to configure database caching

There are three attributes that can be configured in the Kong configuration file, the most important of which is db_update_frequency, which determines the tradeoff between performance and consistency of the Kong node.

Kong already provides a default configuration to allow you to weigh cluster performance and data consistency to avoid unexpected results. You can follow the configuration steps below to change the value of the configuration to ensure that performance and data consistency are acceptable.

1.db_update_frequency (default: 5s)

This configuration determines the interval at which the kong node pulls the update cache from the database and how often synchronization tasks are executed. A lower value means that synchronization tasks will be performed more frequently, and the cached data of the Kong node will be more consistent with the database. A higher value means that your Kong node spends less time processing synchronization tasks, thus devoting more resources to processing requests.

Note: the changes will take effect on the entire cluster node after db_update_frequency seconds.

2.db_update_propagation (default: 0s)

If your database is also clustered and ultimately consistent (e.g. Cassandra), you must configure this value. It ensures that after db_update_propagation seconds, changes between database nodes take effect on all nodes in the entire database cluster. When this value is configured, the Kong node receives invalid events from the synchronization task, and clearing the local cache will delay db_update_propagation seconds.

If a Kong node connects to the final consistency database and there are no latency events to handle, it may clear the cache and cache the values that are not updated again. (because this change has not been propagated to every node in the database cluster, note: database consistency has not yet been consistent in the database cluster, and the Kong cache expires, but is not updated to the change event, and the values that are not updated will be cached again, resulting in Kong inconsistencies, even if Kong performs the synchronization task. ).

You should configure this value to assess how long it will take to achieve consistency after a change in the database cluster. (after ensuring database consistency, perform Kong synchronization tasks to handle change events, thus achieving Kong data consistency.)

Note: when this configuration item is configured, the maximum time for data changes to propagate to the Kong cluster is db_update_frequency + db_update_propagation seconds.

3.db_cache_ttl (default: 3600s)

The time (in seconds) of this configuration item is the time that Kong caches the database entity (including cache hit or penetration). This survival time is a protective measure in case the Kong node misses handling cache invalid events and prevents old data from not being cleaned for a long time. When the cache lifetime is up, the cache value will be cleared, and next time the data will be read from the database and cached again.

4. When using a Cassandra database

If you use Cassandra as the database for Kong, you must configure db_update_propagation to a non-zero value. Since Cassandra itself is the ultimate consistent database, this ensures that the Kong node does not invalidate the local cache prematurely, only when a non-up-to-date value is obtained again. If you use Cassandra but you do not configure this value, Kong will output a warning log.

In addition, you can configure the value of cassandra_consistency to QUORUM or LOCAL_QUORUM to ensure that the value cached by Kong is the latest in the database.

Summary

This article explains Kong's cluster-related things. If for some reason you want to check the value of the cache through Kong, or manually clean the cache (when the cache is hit or lost), you can manage it by using the / cache interface of Admin api.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.