For low latency trading systems, you cannot use any off-the-shelf messaging system. To reach 20 millions per seconds you need a high performance queuing solution.
Java Chronicle is a much better alternative to using memory-mapped files with the risky sun.misc.Unsafe API. In short, Java Chronicle allows a producer process to write data to a shared memory location, only to be consumed by some other process.
So, Java Chronicle is more like a memory-mapped file utility than an actual messaging system. So if you plan on connecting two separate applications running in the same box, then you should definitely give a try to this low latency library.
While you should always strive for the least possible latency, an enterprise application requires a totally different queuing solution. An enterprise system is built of several applications that need to be inter-connected and these applications might reside on different nodes.
So an enterprise messaging system must be designed for networking in the very first place. Compared to trading systems latencies (microseconds), network latencies are much higher (milliseconds).
An enterprise queue must deal with both multiple producers as well as multiple consumers. Some systems use brokers, to acknowledge consumed messages (e.g. JMS), while other systems delegate message reading offsets to the consumer-side (Apache Kafka).
Apache Kafka is a publish-subscribe messaging solution based on a distributed commit log. So while Java Chronicle increases throughput by reducing latency, Kafka uses distributed scaling instead.
Based on my book, High-Performance Java Persistence, this workshop teaches you various data access performance optimizations from JDBC, to JPA, Hibernate and jOOQ for the major rational database systems (e.g. Oracle, SQL Server, MySQL and PostgreSQL).