Alibaba Druid

Alibaba Druid is a high-performance, scalable JDBC connection pool implementation for Java applications. It provides efficient database connection management along with advanced features for monitoring, statistics, and security.

Key Features:

• JDBC Connection Pooling: Managed via DruidDataSource.
• SQL Monitoring & Analysis: Includes SQL parsing and statistics collection.
• Security: Features a SQL firewall via WallFilter.
• Spring Boot Integration: Provides dedicated starters for Spring Boot 2.x (druid-spring-boot-starter) and Spring Boot 3.x (druid-spring-boot-3-starter).

Alibaba Druid is a database middleware providing two primary functional areas:

1. JDBC Connection Pool: A high-performance, monitorable implementation of a database connection pool.
2. SQL Parser: A comprehensive framework for SQL parsing, Abstract Syntax Tree (AST) construction, and visitor patterns, supporting over 30 database dialects.

It is designed for Java 8+ and is licensed under Apache License 2.0.

Druid is composed of four core subsystems that collaborate through clear API boundaries:

1. Connection Pool Subsystem: Manages the lifecycle of physical database connections via DruidDataSource.
2. Filter-Chain Subsystem: An interceptor mechanism using the Responsibility Chain pattern to inject logic (security, logging, statistics) into JDBC operations.
3. SQL Parser Engine: Converts SQL text into a structured Abstract Syntax Tree (AST) using a pipeline of Lexer, Parser, and Visitors, supporting over 30 dialects.
4. Monitoring & Statistics Subsystem: Collects performance metrics (SQL execution time, slow SQL, pool status) via StatFilter and exposes them through web interfaces or programmatic APIs.

HighAvailableDataSource is a wrapper around the standard Druid DataSource that provides client-side load balancing without requiring external tools like LVS or HA Proxy. It is particularly useful for:

1. Read/Write Splitting: Distributing read requests across multiple database replicas.
2. Middleware Scaling: Distributing connections across multiple instances of a sharding middleware (e.g., MyCat).

Key Features:

• Node Routing: Supports routing by name, random, or sticky random selection.
• Flexible Configuration: Nodes can be configured manually, via property files, or dynamically via ZooKeeper.
• Health Checking: Automatically detects and blacklists unhealthy nodes using a background validation mechanism.

Druid's architecture is composed of several core capability modules. Understanding these modules helps in identifying which part of the system handles specific tasks:

• sql-parser-core: Manages the Lexer, Parser, and AST (Abstract Syntax Tree) pipeline, including dialect dispatching.
• connection-pool-core: Handles connection pool capacity, lifecycle management tasks, and ensures concurrency safety.
• filter-chain: Provides an ordered interception mechanism and allows for extensible filter integration.
• wall-security: Performs AST-based SQL security validation with awareness of specific SQL dialects.
• monitoring-stat: Responsible for collecting runtime statistics and managing their exposure channels.

To ensure SQL parser feature gates remain readable and reviewable, all LexerFeature and ParserFeature identifiers must follow a deterministic naming convention.

Naming Pattern: Use the pattern Scope + Intent.

Key Rules:

1. Consistent Scope: Use aligned scope wording for equivalent behavior constraints across both lexer and parser paths. Avoid using divergent synonyms for the same concept.
2. Explicit Polarity: Names describing enabled or disabled behavior must use explicit polarity terms. Avoid double negatives and ambiguous abbreviations to ensure intent is clear.
3. Semantic Clarity: Reviewers should be able to infer the equivalence of gates without inspecting implementation details.

The parser framework uses a deterministic two-step strategy to select the correct parser for a specific SQL dialect. This allows for custom dialect providers to be registered without modifying the core parser logic.

Dispatch Logic:

1. Registered Provider: The framework first attempts to resolve a registered dialect provider for the given dialect key. If found, the parser creation uses this provider, and the built-in dispatch is bypassed.
2. Built-in Fallback: If no provider is registered for the dialect key, the framework falls back to the built-in DbType parser dispatch path.
3. Unregistration: If a previously registered provider is unregistered, the framework automatically reverts to the built-in DbType dispatch.

This mechanism ensures that the base parser remains decoupled from concrete dialect type constants.

Druid uses two primary mechanisms to handle dialect-specific behavior. Understanding when to use which is critical for extending the parser:

1. DialectFeature (Bitmask): Used for simple, toggleable behaviors or switches. These are declared in the Lexer and checked via dialectFeatureEnabled(). Use this for non-structural differences (e.g., ScanString2PutDoubleBackslash).
2. Class Inheritance & Method Overriding: Used when a dialect requires a fundamentally different logic flow or structural parsing rule. Use this when you need to change how a specific token is scanned or how a statement is structured (e.g., HiveLexer.scanString()).

The Parser layer uses a hand-written recursive descent approach to build the AST. It is organized into a hierarchy of specialized parsers:

• SQLParser: The base class providing core utilities like accept(Token) and alias resolution.
• SQLExprParser: Handles complex expression logic (e.g., primary(), relational(), additive()).
• SQLStatementParser: The primary engine for parsing full statements (e.g., parseSelect(), parseInsert(), parseCreate()).
• SQLSelectParser: A specialized parser for SELECT queries, handling WITH clauses, JOINs, and GROUP BY logic.

Each database dialect (like MySQL) provides its own implementation of these parsers (e.g., MySqlStatementParser) to handle vendor-specific syntax like SHOW commands or specific ENGINE options in CREATE TABLE statements.