Design Efficient Redis Keys for Pattern‑Matching Queries
This article explains how to design concise Redis keys that enable multi‑condition and fuzzy queries by using a structured naming convention, demonstrates the implementation within a Java SSM project, and provides code snippets for key assembly, querying, and deletion.
1. Introduction
Redis is a key‑value database that stores data using a unique key; however, its simple key‑value nature imposes limitations such as the inability to perform multi‑condition combined queries and difficulty with fuzzy Chinese searches. Designing an appropriate key can significantly improve query efficiency.
The source code for the demo project is available at https://git.oschina.net/xuliugen/redis-demo.git .
2. Project Structure
The project uses the SSM framework (Spring + Spring MVC + MyBatis). In addition to Redis storage, it implements read/write splitting via annotations, transaction management for both the database and Redis, JSR‑303 validation, and a simple Domain‑Driven Design approach.
Project structure diagram:
Database script diagram:
Spring configuration files location diagram:
Example of enabling Redis transactions in db-redis.xml:
Redis and MyBatis code locations diagram:
3. Key Design
The goal is to create a Redis key that supports pattern‑matching queries. Consider a SecurityUserDTO object where the most common query fields are userName and unitType . These fields should also be indexed in the relational database.
Example of the final key stored in Redis:
SU1_县级单位_wangwu_0000000035
The key consists of four parts:
1. Simplified entity name (e.g., SecurityUserDTO abbreviated) to shorten the key. 2. unitType value – the first query condition. 3. userName value – the second query condition. 4. ID value – a ten‑digit number padded with leading zeros.
Core code for assembling the key:
assembleRedisKeyPrefix()method:
assemberIdForKey()method:
Resulting stored format:
Querying can be done via SecurityUserController#listByCondition(), which constructs the key based on provided conditions and retrieves the data.
If both query conditions are present, the key looks like:
If only one condition is present, the key is constructed accordingly:
Deletion simply uses the unique ID part of the key (e.g., *39), as shown:
*39
4. Conclusion
Key concatenation is straightforward: use the most common query attributes as key components. While other strategies exist, the essential step is practical implementation. For full details and source code, visit the repository at https://git.oschina.net/xuliugen/redis-demo.git . Feel free to leave comments and suggestions for further learning.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java Backend Technology
Focus on Java-related technologies: SSM, Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading. Occasionally cover DevOps tools like Jenkins, Nexus, Docker, and ELK. Also share technical insights from time to time, committed to Java full-stack development!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
