Backend Development 9 min read

Architecture and Technical Practices of JD.com’s Jingmai Message Center

The article details the Jingmai Message Center’s end‑to‑end architecture, covering message ingestion via Anycall and MQ, protocol conversion, Netty‑based push system, Snowflake ID generation, Elasticsearch storage, multi‑level caching, distributed locking, and the overall design principles that enable a scalable, reliable messaging platform.

Architecture Digest
Architecture Digest
Architecture Digest
Architecture and Technical Practices of JD.com’s Jingmai Message Center

Jingmai Message Center (MC) is a core service of the Jingmai platform, providing message push, ISV subscription, tracking, monitoring, and statistics for merchant users.

The overall architecture handles business system messages, informational messages, and other messages.

Business system messages are first received by the Anycall system and then forwarded to MC.

Informational messages are sent from the operation system to MC.

Other messages are delivered to MC via MQ topics.

MC acts as a protocol gateway, converting incoming messages into the Jingmai protocol and forwarding them to the push system.

The push system, part of the TCP gateway, uses a custom Session protocol at the application layer and Netty as the network framework to achieve fully asynchronous handling of message receipt, push, and acknowledgment.

MC System

The MC system includes modules for access, validation, distribution, configuration center, storage, statistics, and logging.

The access module uses MQ to ingest messages from various systems; the validation module checks message compliance; the distribution module routes messages based on configuration; the storage module persists protocol messages; and the logging module tracks the full message chain.

Because the original model could not support multiple distribution paths for a single message type, a Broker concept was introduced, allowing different brokers to implement distinct storage logic based on configuration, thereby improving isolation and scalability.

MQ Usage

The message flow heavily relies on asynchronous processing, with topic isolation to prevent interference between business lines, enhancing system capacity.

Anycall distributes messages to different MQ topics per business; each vendor gets a dedicated topic, ensuring offline pushes do not affect each other and improving push performance.

Snowflake Algorithm in Practice

Message IDs serve as unique identifiers for the entire message chain and client acknowledgments. Previously, IDs were generated by the database as incremental longs, which caused performance bottlenecks (≈150 ms per ID). Switching to a Snowflake algorithm yields roughly 1 ms per ID, eliminating database dependence.

Elasticsearch Usage

Given the large volume, volatility, and query performance requirements of message data, Elasticsearch is used for storage, with separate indices per message category to achieve data isolation. For time‑sensitive messages such as new orders, a one‑day expiration policy is applied.

Message logs are stored in daily indices with aliases and routing strategies, retaining up to seven days, which greatly improves query efficiency.

Cache Strategy

Real‑time message delivery requires caching. Different business types use different cache strategies:

1. Basic configuration data – a three‑level cache consisting of local Guava cache, Redis, and the database. The local cache uses expiration to boost performance, Redis provides a second‑level cache with its own expiration, and the database acts as a fallback, minimizing third‑party dependencies.

2. Unread message counter

Frequent updates and queries would overload a database, so Redis INCR is used to provide high‑performance, atomic increment operations, solving concurrency issues.

Distributed Lock Usage

The message‑pulling interface uses multithreaded polling of the Jingmai API. To handle concurrency, a distributed lock based on Redis’s SETNX command is employed.

Push System

Built on Netty as the network layer, the push system creates a massive push model using silent long‑connection channels, achieving fully asynchronous processing from message receipt to push and acknowledgment.

Summary and Insights

Beyond simple push notifications, the goal is to build a complete, stable message loop that supports diverse business scenarios, monitoring, statistics, and analysis. This enables data‑driven decision making for the platform, convenient integration for upstream services, ISV push capabilities, and operational analytics, ultimately delivering rich message reminders that increase merchant engagement with Jingmai.

Source: http://www.linkedkeeper.com/detail/blog.action?bid=1020

Copyright notice: Content is sourced from the internet, copyright belongs to the original author. We will indicate the author and source unless it cannot be confirmed. If there is any infringement, please inform us and we will delete it promptly.

-END-

Excellent talent is not lacking opportunities; the challenge is finding the right fit. 100offer rigorously matches top talent with top companies. Scan the QR code below to register and receive 5‑10 curated job offers within a week.

distributed systemsmicroservicesElasticsearchCachingNettyMessage QueueSnowflake ID
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.