Cluster Session module design

Since the Interpreter process in Zeppelin is a resident process, the Zeppelin-Server service natively saves the runtime environment of the user, Note, and the Thrift remote connection of the corresponding interpreter process through the Session, but in a distributed environment, you It is not possible to determine which Zeppelin-Server service the user will log in to through the domain name, so the Zeppelin-Server service must be able to support users who are still on the A server to continue to use it in the B server. For this reason, we have two implementations:

1. Cluster unified cache Session

The Session created in each Zeppelin-Server service is stored in a unified manner through Cluster MetaData, and the session information is obtained from Cluster MetaData regardless of which Zeppelin-Server service the user logs in.

Advantages and Disadvantages: The code size is large, and it is complicated to synchronize the session state logic in each server. The metadata stored in Cluster MetaData is also more;

2. Rebuild Session

The user who originally uses the A server will have the user's session. When the user logs in to the B server, the Zeppelin-Server service of the B server re-establishes the user in the B server according to the user and the Note information combined with the Interpreter metadata in the Cluster MetaData. Session

Advantages and Disadvantages: The code implementation is relatively simple, and there is no need to synchronize the session state in each server. The process of rebuilding the Session is very fast and simple;