Backend Implementation of a SpringBoot-Based Seckill (Flash Sale) Project
This article details the design and implementation of a Java SpringBoot seckill system, covering its architecture, technology stack, double‑MD5 password encryption, distributed session management with Redis, unified exception handling, page and object caching, static page generation, memory‑flag plus Redis pre‑decrement and RabbitMQ asynchronous order processing, oversell prevention, and API rate limiting, accompanied by key code snippets.
The SeckillProject is a reference‑grade flash‑sale system built with SpringBoot, MyBatis, MySQL, Redis, and RabbitMQ, demonstrating core backend functionalities such as user login, product listing, product details, seckill ordering, and order details.
Technology Stack : Backend – SpringBoot, MyBatis, MySQL, RabbitMQ, Redis; Frontend – HTML, jQuery, Thymeleaf.
Key Implementation Details :
Double MD5 encryption of user passwords – the first hash protects the password in transit, the second protects stored credentials.
Distributed session maintenance – after successful authentication a UUID token is stored in Redis as token → userObject and also placed in a cookie; subsequent requests retrieve the user from Redis using the token.
Unified exception handling – a custom interceptor combined with @ControllerAdvice and @ExceptionHandler captures all exceptions and returns a unified response.
Page caching and object caching – rendered HTML pages are cached in Redis to reduce server load, and hot objects such as user, product, and order data are also cached; seckill products are pre‑loaded into Redis at startup.
Static page generation – AJAX is used for data fetching; after the first load the page and data are cached in the browser for faster subsequent access.
Memory flag + Redis pre‑decrement + RabbitMQ async processing – a local Map localOverMap tracks sold‑out items to avoid unnecessary Redis calls; Redis pre‑decrements stock, and successful requests are placed into a RabbitMQ queue for asynchronous order creation.
Oversell prevention – SQL update only succeeds when stock > 0; a unique index on (user_id, goods_id) prevents duplicate orders; optimistic locking with a version field adds another safety layer.
API rate limiting – a custom @AccessLimit annotation limits each user to a configurable number of requests within a time window.
Memory‑Flag and Redis Pre‑Decrement Code :
// System startup initializes all seckill product IDs into a map, stock = 0 means sold out
private Map
localOverMap = new HashMap<>();
// Memory flag to reduce Redis access
boolean over = localOverMap.get(goodsId);
if (over) {
return Result.error(CodeMsg.MIAO_SHA_OVER);
}
// Redis pre‑decrement
long stock = redisService.decr(GoodsKey.getSeckillGoodsStock, "" + goodsId);
if (stock < 0) {
localOverMap.put(goodsId, true);
return Result.error(CodeMsg.MIAO_SHA_OVER);
}
// Check if user already placed an order
SeckillOrder order = orderService.getOrderByUserIdGoodsId(user.getId(), goodsId);
if (order != null) {
return Result.error(CodeMsg.REPEATE_MIAOSHA);
}
// Push to message queue for async processing
SeckillMessage sm = new SeckillMessage();
sm.setUser(user);
sm.setGoodsId(goodsId);
sender.sendSeckillMessage(sm);SQL for Stock Update (Oversell Guard) :
update seckill_goods set stock_count = stock_count - 1 where goods_id = #{goodsId} and stock_count > 0The article also provides screenshots of the project structure, login page, product list, product details, order details after a successful seckill, and a link to download the full source code from Gitee.
Top Architect
Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.
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.