|
63 | 63 |
|
64 | 64 | ZooKeeper service, MasterServer and WorkerServer nodes in the system all use ZooKeeper for cluster management and fault tolerance. With evolving needs and modern deployment environments, DolphinScheduler now supports event monitoring and distributed locks not only based on ZooKeeper, but also on **JDBC** and **Etcd** implementations.
|
65 | 65 |
|
66 |
| - - **JDBC** provides a lightweight solution for lock and event management through relational databases, making it ideal for simpler deployments or systems that already rely heavily on SQL databases. |
| 66 | +- **JDBC** |
| 67 | + DolphinScheduler also provides a JDBC-based registry implementation, located in the `dolphinscheduler-registry/dolphinscheduler-registry-plugins/dolphinscheduler-registry-jdbc` module. Unlike external systems such as ZooKeeper or Etcd, the JDBC approach leverages a relational database to support event monitoring and distributed locking, making it well-suited for environments that already rely on SQL databases. |
67 | 68 |
|
68 |
| - - **Etcd** enables distributed coordination using a high-performance key-value store, suitable for modern cloud-native environments. |
| 69 | + - **Event Monitoring** |
| 70 | + |
| 71 | + - **Subscribe Method** |
| 72 | + The `subscribe(String watchedPath, SubscribeListener listener)` method in `JdbcRegistry` registers a data change listener using the `JdbcRegistryDataChangeListenerAdapter`. When changes (such as creation, update, or deletion) occur for the specified key or path in the database, the adapter converts these changes into DolphinScheduler `Event` notifications and triggers the `SubscribeListener` callback. |
| 73 | + |
| 74 | + - **Polling/Trigger Mechanism** |
| 75 | + Internally, the system uses periodic polling or a trigger-based mechanism to detect changes in the registry data stored in the database, simulating a Watcher-like behavior similar to ZooKeeper. |
| 76 | + |
| 77 | + - **Distributed Lock** |
| 78 | + |
| 79 | + - **Lock Acquisition and Release** |
| 80 | + The JDBC registry offers both `acquireLock(String key)` and `acquireLock(String key, long timeout)` methods, which correspond to blocking and timeout-based lock acquisition respectively. These methods internally call `JdbcRegistryClient.acquireJdbcRegistryLock(...)` to manage locks via database records, ensuring mutual exclusion in a distributed environment. |
| 81 | + |
| 82 | + - **Ephemeral vs. Persistent Locks** |
| 83 | + Data entries are classified as either **EPHEMERAL** or **PERSISTENT**. For ephemeral locks, if the client disconnects or fails, heartbeat mechanisms detect the lapse and clean up the lock record automatically, thus releasing the lock. |
| 84 | + |
| 85 | + - **Lock Management** |
| 86 | + Under the hood, components like `JdbcRegistryLockManager` (or equivalent) use row-level locking or specific database fields to ensure atomic lock operations, maintaining consistency even when multiple masters/workers compete for the same lock. |
| 87 | + |
| 88 | + *** |
| 89 | + |
| 90 | + By leveraging JDBC for both **event monitoring** and **distributed locking**, DolphinScheduler can achieve reliable task coordination and scheduling without relying on external registry centers, making it an attractive option for environments that prefer or already have robust database infrastructure. |
| 91 | + |
| 92 | +- **Etcd** |
| 93 | + |
| 94 | + DolphinScheduler also provides an Etcd-based registry implementation. The Etcd-based registry, implemented in the module `dolphinscheduler-registry/dolphinscheduler-registry-plugins/dolphinscheduler-registry-etcd`, leverages the Jetcd client library to interact with an Etcd cluster. This implementation provides several key functionalities: |
| 95 | + |
| 96 | + - **Event Monitoring** |
| 97 | + |
| 98 | + - **Watch API** |
| 99 | + The `EtcdRegistry` class uses Etcd’s Watch API to observe changes (creation, update, or deletion) on specified keys or key prefixes. Low-level Etcd watch events are translated into DolphinScheduler’s `Event` objects, triggering `SubscribeListener` callbacks for real-time notifications. |
| 100 | + |
| 101 | + - **Distributed Lock** |
| 102 | + |
| 103 | + - **Lease-Based Locking** |
| 104 | + The `EtcdKeepAliveLeaseManager` grants a lease with a specified TTL, continuously kept alive via Etcd’s keep-alive mechanism. If the client disconnects, the lease expires automatically, releasing the lock without manual intervention. |
| 105 | + |
| 106 | + - **Connection Health Monitoring** |
| 107 | + The `EtcdConnectionStateListener` tracks the connection state between DolphinScheduler and the Etcd cluster. Upon disconnection or reconnection, it re-establishes locks or re-registers services as needed. |
| 108 | + |
| 109 | + - **Configuration** |
| 110 | + |
| 111 | + - **Flexible Configuration** |
| 112 | + The behavior of the Etcd registry is controlled by `EtcdRegistryProperties`, which maps various settings (endpoints, namespace, SSL, authentication, etc.) from configuration files. These settings are integrated into the Spring Boot auto-configuration process via `EtcdRegistryAutoConfiguration`, ensuring that the Etcd registry is instantiated automatically when `registry.type` is set to `"etcd"`. |
| 113 | + |
| 114 | + Together, these components ensure that DolphinScheduler can reliably use Etcd as an alternative registry center. This is especially useful in cloud-native environments where low latency, high scalability, and ease of deployment are critical. |
| 115 | + |
| 116 | + *** |
69 | 117 |
|
70 | 118 | We have also implemented queues based on Redis, but we hope DolphinScheduler depends on as few components as possible, so we finally removed the Redis implementation.
|
71 | 119 |
|
|
0 commit comments