goodsKill: a Spring Cloud 2025 seckill lab you run locally
🐎基于SpringCloud 2025.x + Dubbo 3.x + AI构建的模拟秒杀微服务项目，集成了Elasticsearch🔍、Gateway、Mybatis-Plus、Sharding-JDBC等常用开源组件
At a glance
- What is it?
- goodsKill is a Java microservice project that implements ten different seckill (flash sale) strategies behind one test controller. It is a study framework, not a production flash-sale system, and the README says so.
- Who is it for?
- Adopt goodsKill if you want a runnable reference for comparing lock, queue and atomic-update approaches to inventory under contention, and you are comfortable starting a large Docker stack. Skip it if you need a production seckill service: the README states the project omits details of real scenarios and is for learning reference only.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 72 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What goodsKill actually is, and who it is for
goodsKill is a simulated seckill project. The README is explicit that it exists to assemble a complete project skeleton and fold in good techniques and development habits, mostly on the backend, for learning and reference. It also warns that using more technology stacks is not automatically better, because every extra stack adds maintenance and usage cost. That sentence is the most honest thing in the repository, and it should shape how you read everything else.
The intended reader is a Java backend engineer who already knows Spring Boot and wants to see how the same inventory-contention problem behaves under ten different mechanisms. The project exposes those mechanisms through a single test controller, SeckillMockController, so the comparison is structural rather than anecdotal. If you are looking for a drop-in flash-sale service, this is the wrong artifact: the README states the implementation is currently rough, that real seckill scenarios are far more complex, and that the project omits some technical details of real scenarios.
Ten seckill strategies behind one controller
The README lists the scenarios by number. Scenario one uses a synchronized lock. Scenario two uses a Redisson distributed lock. Scenario three used ActiveMQ and is marked deprecated. Scenario four uses Kafka. Scenario five relies on an atomic database update. Scenario six, real-time waiting for the seckill result, is also deprecated. Scenario seven uses a ZooKeeper distributed lock. Scenario eight decrements stock in Redis, sends a success message asynchronously after the seckill ends, and lands the data in MongoDB. Scenario nine uses Spring Cloud Stream. Scenario ten combines Sentinel rate limiting with the atomic database update, and the README notes it needs a flow-control rule configured in the Sentinel console for the resource named limit.
That list is the real product. Each scenario is a different answer to the same question: how do you stop overselling when many requests hit one row of stock. The in-process lock, the distributed lock, the queue, and the conditional UPDATE are four distinct families, and having them side by side in one codebase is more useful than any single implementation. The two deprecated entries are worth noting because they show the author retired approaches rather than quietly leaving them.
The README includes a sample log block showing a run across several scenarios, with a StopWatch breakdown printing per-scenario timings in nanoseconds. Treat that block as an example of the output format, not as a benchmark: the README does not state the machine, the concurrency level or the data volume behind those numbers.
Modules, registries and the request path
The repository is a Maven multi-module build. The README's module tree lists goodskill-web for the simulated seckill endpoints, goodskill-seckill-provider and goodskill-order-provider as service providers, goodskill-gateway as an API gateway with unified authentication and dynamic route loading, goodskill-auth with an auth-service built on Sa-Token, goodskill-admin for Spring Boot Admin monitoring, goodskill-job for elastic-job scheduled tasks, goodskill-ai for the AI chat service, goodskill-common for shared code including MinIO upload and download, and goodskill-spring-boot-starter for auto-configuration. Two Vue 3 plus Vite front ends sit alongside: goodskill-ui for administration and goodskill-customer-ui for the customer-facing store.
Service registration, discovery and configuration go through Nacos. Inter-service calls use Dubbo 3.x plus the native RestClient, which is an unusual pairing: Dubbo for RPC and the plain HTTP client for the rest. Distributed transactions are handled with Seata, and the goodskill-seata module is described as a worked example combining Nacos, Dubbo, Sharding-JDBC and Seata. Database sharding comes from Sharding-JDBC 5.5.0, and data state transitions run through a Spring Statemachine. Observability is wired through OpenTelemetry, with the README pointing at Grafana OTel LGTM for metrics, logs and traces together.
The top-level listing also shows directories the README does not describe, including goodskill-canal and goodskill-chat-provider. The README is silent on what those contain, so read the code before assuming a role for them.
Installing goodsKill and running your first seckill
The README's quick start has two steps. First build from the repository root, where the README gives both a full build and a test-skipping variant.
mvn clean install
# or skip unit tests
mvn clean install -DskipTestsSecond, start the dependencies. The README says to start Nacos, Redis, MySQL, RabbitMQ, Kafka, ZooKeeper, Elasticsearch and the Seata server on their default ports, or to use docker-compose instead.
docker-compose up -dThe compose file defines more than the README's sentence implies: alongside RabbitMQ, Nacos, ZooKeeper, Kafka and Prometheus it also brings up nginx on port 80. Nacos is published on 18080 for the console and 8848 for the client, with the console credentials nacos:nacos. Redis listens on 6379 with password 123456. MySQL is on 3306 with root:Password123. Kafka is on 9092, MongoDB on 27017, ZooKeeper on 2181, Elasticsearch on 9200 and 9300, Kibana on 5601, RabbitMQ on 5672 and 15672, PostgreSQL on 5432 with goodskill:Password123, MinIO on 9000 with root:password, Seata on 7091 and 8091 with seata:seata, and Grafana OTel LGTM on 3000 for the UI, 4317 for OTLP gRPC and 4318 for OTLP HTTP, with admin:admin. Those values come from the README's image table and the compose file. Change the default passwords before exposing any of these ports beyond localhost.
Once the stack is up, the README points at two consoles. The aggregated gateway OpenAPI document is at http://localhost/doc.html#/home and requires the gateway service to be running. Spring Boot Admin is at http://www.goodskill.com:19031 with user/123456. The seckill scenarios themselves are triggered through SeckillMockController, and the README says the web console shows the results. Scenario ten additionally needs a Sentinel flow-control rule for the resource named limit; without that rule the rate limiting is not in play.
Where goodsKill breaks down as a reference
The largest limitation is stated by the author: real seckill scenarios are far more complex than what is implemented here, and the project omits some technical details of real scenarios. That is a scope boundary, not a bug, but it means you cannot lift a scenario into production and expect it to hold. The synchronized-lock scenario in particular only makes sense inside a single JVM, and the README does not present it as anything else.
Operationally, the entry cost is high. Running the full comparison requires Nacos, Redis, MySQL, RabbitMQ, Kafka, ZooKeeper, Elasticsearch, Seata and more, and the compose file adds Prometheus and nginx on top. The README itself concedes that too many stacks bring extra maintenance and usage cost. If your goal is to understand one locking strategy, booting a dozen services to get there is a poor trade.
The build surface is also thin. The README's quick start does not document a rollback path, a migration procedure or a supported upgrade path between versions. The release list shows v3.2.4 from 2024-04-20 and v2.7.4 from 2023-04-25, while the README describes a stack built on Spring Cloud 2025.x, Spring Boot 4.x and JDK 21. The README does not explain how a user of an older release gets to the current main branch. The last push to the repository was on 2026-07-07, so the code is not abandoned, but the README does not document the upgrade route and the release tags lag the stack description.
How it compares with building on Seata and Sharding-JDBC alone
The closest alternative is not another seckill demo but the underlying components used directly. Sharding-JDBC 5.5.0 handles sharding, and Seata handles distributed transactions; both are documented projects with their own reference guides. If your question is how to configure a sharded order table or how to wire an AT-mode transaction, the goodsKill README is not the place to learn it, because it documents the integration only at the level of a module description.
goodsKill's difference is the side-by-side comparison. Sharding-JDBC and Seata documentation each explain one mechanism well; goodsKill puts ten mechanisms for the same inventory problem in one repository, under one controller, with one result console. That is a different artifact with a different purpose. The trade-off is depth: the project shows you that a ZooKeeper lock scenario exists and how it is invoked, but the README does not explain the failure semantics of each approach, and it does not state which scenario is fastest or safest. The sample StopWatch output is illustrative, not a verdict. If you want a defensible answer about which approach to use, you will have to run the scenarios yourself on your own hardware.
Licence and the cost of keeping this running
goodsKill is MIT licensed, and the badge in the README links to the LICENSE file at the repository root. MIT is permissive: you can reuse and modify the code with attribution and without a copyleft obligation on your own project. That is a statement about the project's licence, not legal advice about your situation.
The licence covers the code in this repository. It does not cover the third-party components the project depends on, and the README's table lists a long set: Nacos, Redis, Kafka, RabbitMQ, MongoDB, MySQL, PostgreSQL, Elasticsearch, Sharding-JDBC, Spring Cloud Alibaba, Dubbo, Spring Cloud Gateway, Seata, GraphQL, Spring Statemachine, Sa-Token, Flyway, MinIO, Spring AI and OpenTelemetry. Each has its own licence, and several have their own versioning and release cadence. Upgrading goodsKill means tracking all of them.
That is the real maintenance cost. The README pins specific versions for Sharding-JDBC, Nacos, Kafka, MongoDB, MySQL, ZooKeeper, Elasticsearch, Kibana, Seata and PostgreSQL, so a version bump in any one of them is a coordinated change across the compose file and the modules that depend on it. The repository does carry CI: the README shows Maven build, Codecov and CodeQL badges for the main branch, which means build and static analysis run on push. There is no documented migration guide for moving between releases, so plan on reading diffs.
Editorial conclusion
Adopt goodsKill if you want a runnable reference for comparing lock, queue and atomic-update approaches to inventory under contention, and you are comfortable starting a large Docker stack. Skip it if you need a production seckill service: the README states the project omits details of real scenarios and is for learning reference only. Verify first that your JDK is 21, that the docker-compose services match the versions in the README table, and that the module you plan to run has a current main-branch build.
Frequently asked questions
What is goodsKill?
goodsKill is a simulated seckill (flash sale) microservice project built on Spring Cloud 2025.x, Spring Boot 4.x, JDK 21 and Dubbo 3.x. The README describes it as a framework for learning and reference that integrates techniques such as Sharding-JDBC, Seata, Spring Statemachine and OpenTelemetry.
How do I install and start goodsKill?
Run mvn clean install from the repository root, or mvn clean install -DskipTests to skip unit tests, then start the dependencies with docker-compose up -d. The README also lists the individual services to start if you prefer to run them yourself.
How many seckill scenarios does goodsKill implement?
The README lists ten scenarios, covering synchronized locks, Redisson and ZooKeeper distributed locks, Kafka and Spring Cloud Stream queues, atomic database updates, a Redis-decrement plus MongoDB approach, and Sentinel rate limiting combined with an atomic update. Two of the ten, the ActiveMQ and real-time-wait scenarios, are marked deprecated.
Is goodsKill suitable for production use?
No. The README states that real seckill scenarios are far more complex than this implementation, that the project omits some technical details of real scenarios, and that it is currently for learning reference only.
Community notes