Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

The seckill system is a complex affair, as our last article showed, running to nearly 5,000 smelly words. It would be a huge waste of manpower to write something as complex as this once for every system. If one link is not properly considered, it will be a failure.

Since last time we talked about the design of seckill system in the technical exchange group, so far we have recruited 8 partners who are very interested in it and are the main coders. After all the discussion, we felt that in addition to making a split-kill demo, we could go one step further and make it a split-kill engine.

Here, XJJDog shares the process. It’s not the result that matters, it’s the thought and the process. You’ll probably gain some experience developing framework class code, hopefully.

First, system design points, starting from selling sick geese

A black box

The main idea is to treat the split-kill engine as a black box, shielding the logic that completes the split-kill. One end goes in, one end goes out. In other words, you take the data that you want to kill, wash it and dump it into the kill engine, and the rest of the system is nothing.

“Exquisite seckill engine, cloud acceleration, elastic scalable high availability architecture. SLA 5 9 throughout the year, green pollution-free, for your business escort. Professional pre-sales technical support to help you complete the optimal configuration.” Is that a very familiar piece of bullshit? This is the black box. All I have to do is finish the function, and you call me a monster.

Abstract concept

In terms of process, we have also categorized the kill code into three phases: prepare, kill, and clear. In order to accomplish the above goals, further abstractions are required for the resources involved. Below are some preliminary concepts, subject to change.

Actor kills the actor in seconds

Literally, you can see that what is abstracted here is the subject of the operation, the person who is involved. Actors carry attached information, such as basic information about the user. In this way, some individual flow control strategies, or risk control strategies, can be implemented. For example, let’s say there’s a logic: the newly registered account is not eligible for seckilling. The actor’s additional information should include the user’s registration time.

Queue Buffer queue

The queue is the buffer for the kill request and is the first place to land. Whether it’s an in-memory queue or a distributed queue, the operation is pretty much the same. Let’s abstract it a little bit. In this way, you can adjust the behavior and performance of the kill queue by configuring parameters.

Source Indicates the data source

Provider of data. Data may come from an external database (DB), an external push, or a pull from an external interface. This process of getting the data, we’re going to call it source. Of course, this part of the function can also be extended, such as source data from ES.

Sink SEC kill data drops and sinks

Mainly deals with the whereabouts of data after the completion of the kill. Like Source, it is a reverse action. It deals with a landing action like inventory deduction. The behavior of this component may be to push or send an event message directly. Source and sink, which constitute the specific data flow of a second kill target, are outside the black box.

Target Indicates the kill target

It’s time to give our seckill target a name. It has a unique name in the seckill engine: targetID, which identifies the item. Very, very many personalized configuration parameters, right here, such as SEC start time, queue length, lazy loading of goods, etc.

Stock operation

The inventory operation refers to the operation in the black box, the information will be merged irregularly, sink to the business side. Operations on stock need to ensure correctness and throughput. That’s one of our core concepts.

The action moves

Similar to message bus. Actions, which are the carriers of all behavior produced by actors, are Immutable throughout their life cycles. Actions are buffered, tracked, scheduled, logged, and are behavioral entities that intersect the entire engine.

Runtime Runs the unit in real time

The Runtime is variable and is used as a buffer for information during the chaotic period. In principle, it does not record and sink. Our operation unit will do a lot of calculations and judgments until the final data reaches the BASE state.

The main process

The target

Seckill engines use all kinds of technology, and we have our hands full, but we also need a way to share. With the tutorial + source code, there will be a better effect. In order to ensure the robustness of the program, unit tests are used to cover the code as much as possible. In order to evaluate the performance of the entire system, we will also introduce some tools for stress testing; Finally, a Springboot project will be used to integrate the splitter engine to make a final effect.

The part of the abstract concept should be able to achieve dynamic replacement and provide custom extension.

Tentative technical selection

The seckill engine consists of three parts.

This module relies on as few components as possible to be used in a variety of development environments (not just Spring) and covers important concepts and implementation logic. There are a lot of fine configuration parameters for performance tuning.

2. Demo uses springboot, Vue, Flutter and other popular technologies to present a complete example.

3. In the scheme part, the optimization of some special scenarios or an extended theme will be provided with typical schemes.

The most marketable word is industry solutions.

code

The project code is on Github and is only partially abstract at the moment. You can follow it if you are interested.

https://github.com/xjjdog/seckill-engine
Copy the code

Little sister taste wechat public account will continue to track state changes and technology worth mentioning, using the way of practice, some knowledge points in the past to review and intersperse.

Welcome to add my wechat, put forward your valuable opinions.

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.