[keycloak-dev] Clustering and user sessions

[Bill Burke]

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