On 9/17/2014 7:03 AM, Stian Thorgersen wrote:
By far the most common request to Keycloak is going to be refreshing
the token and if we're sending a message to the cluster for every token refresh
it's just not going to scale very well.
Will it even scale past 1 node?! Think about it, every refresh causes a request one node
to handle one request from the client and send a message to the cluster, while all other
nodes have to deal with a message from the cluster. It's going to increase
availability, but not scalability.
So we're going to have to do something smarter than simply sending lastSessionRefresh
every time.
Following your example I don't think it's a big deal that there's a window
where the session is expired on one node, while not on another. We can always come up with
a schema to improve that. Two alternatives we could do if a node detects a session as
expired:
1. Ask the cluster if the session is expired, if at least one node says it's not
expired it's not
2. Tell the cluster that the session is expired
Another solution we could consider is sharding. We have one or more front servers to the
cluster which just delegate to a shard to process a request. Each shared handles one set
of users and can consist of one or more nodes for increased availability. The front
servers only need to know about the shards and members of a shard. This is probably the
only solution that's going to scale to really big numbers, so might eventually be
required.
For sharding, you'd also have to change our architecture. When the
client needs to change the code to a token, it is going to have to know
which shard to communicate to.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com