Sticky classes are a must have for any Load Balancer, Reverse Proxy, and API Gateway price their salt. Nonetheless, I have to admit that Apache APISIX’s documentation wants a straightforward entry level into the topic.
Apache APISIX binds a route to an upstream. An upstream consists of a number of nodes. When a request matches the route, Apache APISIX should select amongst all out there nodes to ahead the request to. By default, the algorithm is weighted round-robin. Spherical-robin makes use of one node after the opposite, and after the final one, get again to the primary one. With weighted round-robin, the load impacts what number of requests Apache APISIX forwards to a node earlier than it switches to the following one.
Nonetheless, different algorithms can be found:
Constant hashing permits forwarding to the identical node relying on some worth: an NGINX variable, an HTTP header, a cookie, and so on.
Keep in mind that HTTP is a stateless protocol, so software servers set a cookie on the primary response to trace the person throughout HTTP requests. It’s what we name a “session”. We have to know the underlying session cookie identify. Totally different software servers hand out completely different cookies:
JSESSIONIDfor JVM-based serversPHPSESSIDfor PHPASPSESSIONIDfor ASP.Web- and so on.
I shall use a daily Tomcat, so the session cookie is JSESSIONID. Henceforth, the Apache APISIX documentation for 2 nodes is the next:
routes:
- uri: /*
upstream:
nodes:
"tomcat1:8080": 1 (1)
"tomcat2:8080": 1 (1)
sort: chash (2)
hash_on: cookie (3)
key: cookie_JSESSIONID (4)| 1 | Outline the upstream nodes |
| 2 | Select the constant hashing algorithm |
| 3 | Hash on cookie |
| 4 | Outline which cookie to hash on |
