Evolution of the Rainbow Bridge Architecture: From BIO to NIO with Custom Database Driver and Connection Pool

This article reviews the evolution of the “Rainbow Bridge” proxy architecture, focusing on improving stability and functionality by migrating the Proxy‑DB layer from a blocking BIO model to a non‑blocking NIO model.

In the original design the Proxy consists of three layers – Frontend (Netty server), Core (routing, sharding, etc.) and Backend (JDBC). The Backend uses the vendor’s JDBC driver, which operates in BIO mode, causing one thread per connection, high resource consumption, limited scalability, I/O blocking and complex thread management.

To address these issues the authors replaced the JDBC driver with a self‑developed NIO driver based on Netty and built a matching NIO connection pool. The driver handles MySQL packet encoding/decoding, command serialization via a lock‑free queue, and binds responses to requests using Netty promises.

Key optimizations include:

Skipping unnecessary codec stages when the Proxy does not need to modify result sets.

EventLoop affinity: connections are bound to the same EventLoop that processes the request, reducing context switches.

Asynchronous full‑link processing using Netty futures and a utility that executes completed futures immediately.

Compatibility work for special field types, JDBC URL parameters, ThreadLocal migration, and logging MDC/TraceContext.

Performance tests show the NIO architecture achieves up to 67% higher maximum throughput, 37% lower load, and a 98% reduction in thread count compared with the BIO version.

Example SQL statements illustrating when result‑set merging can be skipped:

SELECT id, name FROM user WHERE user_id in (1, 2)

SELECT id, name FROM user WHERE user_id in (1)

The article concludes that despite the large migration effort, the NIO redesign delivers significant stability and performance gains, positioning the system among the top tier of DAL middleware.