You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@zookeeper.apache.org by GitBox <gi...@apache.org> on 2019/09/30 04:13:37 UTC
[GitHub] [zookeeper] maoling commented on a change in pull request #1045:
ZOOKEEPER-3400: Add documentation on local sessions
maoling commented on a change in pull request #1045: ZOOKEEPER-3400: Add documentation on local sessions
URL: https://github.com/apache/zookeeper/pull/1045#discussion_r329403355
##########
File path: zookeeper-docs/src/main/resources/markdown/zookeeperProgrammers.md
##########
@@ -503,6 +503,88 @@ new list and failing to connect, the client moves back to the normal mode of ope
an arbitrary server from the connectString and attempts to connect to it. If that fails, it will continue
trying different random servers in round robin. (see above the algorithm used to initially choose a server)
+**Local session**. Added in 3.5.0, mainly implemented by [ZOOKEEPER-1147](https://issues.apache.org/jira/browse/ZOOKEEPER-1147).
+
+- Background: The creation and closing of sessions are costly in ZooKeeper because they need quorum confirmations,
+ they become the bottleneck of a ZooKeeper ensemble when it needs to handle thousands of client connections.
+So after 3.5.0, we introduce a new type of session: local session which doesn't have a full functionality of a normal(global) session, this feature
+will be available by turning on *localSessionsEnabled*.
+
+when *localSessionsUpgradingEnabled* is disable:
+
+- Local sessions cannot create ephemeral nodes
+
+- Once a local session is lost, users cannot re-establish it using the session-id/password, the session and its watches are gone for good.
+ Note: Losing the tcp connection does not necessarily imply that the session is lost. If the connection can be reestablished with the same zk server
+ before the session timeout then the client can continue (it simply cannot move to another server).
+
+- When a local session connects, the session info is only maintained on the zookeeper server that it is connected to. The leader is not aware of the creation of such a session and
+there is no state written to disk.
+
+- The pings, expiration and other session state maintenance are handled by the server which current session is connected to.
+
+when *localSessionsUpgradingEnabled* is enable:
+
+- A local session can be upgraded to the global session automatically.
+
+- When a new session is created it is saved locally in a wrapped *LocalSessionTracker*. It can subsequently be upgraded
+to a global session as required (e.g. create ephemeral nodes). If an upgrade is requested the session is removed from local
+ collections while keeping the same session ID.
+
+- Currently, Only the operation: *create ephemeral node* needs a session upgrade from local to global.
+The reason is that the creation of ephemeral node depends heavily on a global session. If local session can create ephemeral
+node without upgrading to global session, it will cause the data inconsistency between different nodes.
+The leader also needs to know about the lifespan of a session in order to clean up ephemeral nodes on close/expiry.
+This requires a global session as the local session is tied to its particular server.
+
+- A session can be both a local and global session during upgrade, but the operation of upgrade cannot be called concurrently by two thread.
+
+- *ZooKeeperServer*(Standalone) uses *SessionTrackerImpl*; *LeaderZookeeper* uses *LeaderSessionTracker* which holds
+ *SessionTrackerImpl*(global) and *LocalSessionTracker*(if enable); *FollowerZooKeeperServer* and *ObserverZooKeeperServer*
+ use *LearnerSessionTracker* which holds *LocalSessionTracker*.
+ The UML Graph of Classes about session:
+
+ ```
+ +----------------+ +--------------------+ +---------------------+
+ | | --> | | ----> | LocalSessionTracker |
+ | SessionTracker | | SessionTrackerImpl | +---------------------+
+ | | | | +-----------------------+
+ | | | | +-------------------------> | LeaderSessionTracker |
+ +----------------+ +--------------------+ | +-----------------------+
+ | |
+ | |
+ | |
+ | +---------------------------+
+ +---------> | |
+ | UpgradeableSessionTracker |
+ | |
+ | | ------------------------+
+ +---------------------------+ |
+ |
+ |
+ v
+ +-----------------------+
+ | LearnerSessionTracker |
+ +-----------------------+
+ ```
+
+- Q&A
+ - *What's the reason for having the config option to disable local session upgrade?*
+ - In a large deployment which wants to handle a very large number of clients, we know that clients connecting via the observers
Review comment:
- When users want to scale the read throughput with hundreds of observers(e.g: the distributor of configurations), these observer servers only sync updates with leader for the read of downstream applications/clients, so they only use the local session and don't need to turn on the `localSessionsUpgradingEnabled` to use the global session.
- On the other hand, disable the `localSessionsUpgradingEnabled` is a protection mechanism to avoid the malicious observer nodes who want to creates lots of ephemeral nodes with global sessions, which take a harm effect on the throughput of the whole ensemble.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services