Lower Scalability Solution: Aggregation Collection

What's the point of not having a solution? We discussed some of the issues in the article "the 42 monsters that creep in on load growth", and we'll talk about what I call aggregation strategy (aggregation strategies) in this post, which I'll rearrange later.

Keep in mind that these are some of the suggestions for a low-level architecture, such as how to organize the structure of code components and how they interact. This article will not discuss a large cluster, but will discuss how your application might be internally--deep beneath the service interface. In addition to the event architecture, there are many things in this world.

Aggregation, in short, is not a stupid queue, our queues will be very smart. We hit the bottom of our hearts. The queue is considered a container for the work content, which ultimately shows how the entire system works. As a container for the content of the work, we are familiar with what requests and data are in the queue, and we can use that information as a huge advantage.

Reasonable sort of work content

The key idea here is a design approach that basically has to be kept in mind, and programmers see it as a first-order concept--what to do in every aspect of the job creation, why to do it, and when to prioritize the three questions.

Avoid cascading failures

Why is it so important to have a reasonable sort of job content? The least reliable scenario we should avoid is cascading failures. Naïve system does not have a reasonable sort of idea, in the event of failure, will let useless control layer or data layer traffic crowding out the necessary control flow.

If you need to send a request to the switch and reprogram the route to failover the traffic, if the lower-priority work item causes a line-end congestion (head-of-line blocking), you will never get control of the system without shutting down the entire system. Long-winded programs that don't understand the situation keep sending low priority control and data traffic, keeping the system busy and doing nothing at all. It's like junk food in the code.

A system that understands priorities tries to avoid useless work while ensuring that high-priority work is done on time. The network and data networks used for control are independent, so control messages are freely accessible. You will have an intelligent retry strategy, and useless work will not occupy the queue, and invalid messages will be removed from the queue. Consider caching everywhere on the Web, making sure you don't see old versions. When the latest messages come in, you can pause the current work with control messages to handle higher-priority work, and their messages will be sent out immediately, rather than into the wait. There are a lot of cool things to do to make the system more robust.

Handle Unlimited Workloads

Prioritization is a key idea for dealing with unlimited workloads, as discussed in the 42 monsters that creep up on load growth. Conventional wisdom is that we think 100% CPU usage is a bad signal. As compensation, we create complex infrastructures for load balancing, state replication, and building server clusters. The CPU is not fatigued, so we can squeeze it dry. When we discuss prioritization, we are also discussing how the system can make beautiful, predictable responses under full load. If we make a reasonable set of conditions, none of this is a problem. This becomes a problem only for software that is naïve in architecture.

Conscious control.

In a reasonably sorted work context, developers should have a conscious control of the following:

What work to do, what work to throw

The order in which work is processed

Task priority for processing work

Amount of resources given to work:

CPU Time

Memory

Queue space

Disk

Internet

Lock

You may notice that in a typical programming environment, you don't have a strong control over the content. This must be changed.

Identify priorities

A reasonable sort of work is also a common practice in scalability solutions in many other areas. Prioritizing requires a deep understanding of what is going on in the system and what you want to happen to the system. Priority depends on:

Customer

Request type

Try to provide a fair service

Number of requests

Amount of resources used

Amount of resources required

Due date in the contract

Sla

In addition to avoiding cascading failures, another key reason to embrace priority as a basic concept is to guarantee SLAs.

You have a high priority customer and he pays for a service that is superior to the average customer. In order to achieve their SLAs, all components of the system must be accustomed to understanding priorities, while not allowing other customers to be hungry and providing them with attentive service.

This has much in common with OS task scheduling and network traffic scheduling. The idea is the same, but developers need to use these ideas in the system.

Merging aggregations

A merge aggregation is the merging of individual data and/or commands together. The idea is to use resources in proportion to fixed limits.

For example, suppose an object has a sequence of commands:

New

Update

Update