When Golang encounters high concurrency instant kill~

下面由golang教程栏目给大家介绍当Golang遇到高并发秒杀，希望对需要的朋友有所帮助！

遇到GO语言也是偶尔的一次机会，工作上做架构相关的事情，对新发展比较火爆的语言肯定要关注下。就这样步入了GO语言的世界，GO给我带来了全新的体验;

　　一直做一件事情的人往往会被一件事情所困，开始实践GO语言的时候总感觉哪哪都别扭，特别是把结构体当成类，还有结构体的继承，写面向对想多了开始还真扭不过来。不过写的多了渐渐地也习惯了，甚至感觉越来越顺眼。

　　在熟悉了GO一段时间后，也停止了一会，脑子里一直在想着GO的简洁(代码风格一致，用起来简练不拖泥带水，部署极其简单，编译速度用快来形容)，能给项目系统和架构带来哪些改变。但是当时一时半会儿还真没想到有多大帮助，后来系统逐步开始用GO实现，用的多了慢慢地发现：

　　咦～，部署再也不要搭建依赖环境了(不部署环境发布，刚开始还真有点不习惯，总感觉少来点什么;

　　别人写的代码看着也没有抵触心理，虽然说有的代码不是自己写的，仔细阅读的时候就感觉像是自己写的，写JAVA 和PHP的时候 阅读代码哪是从内心拒绝的;

　　开发某个微服务接口一切变得简单了，写个main，写个接口，提交，秒秒种就上线了～;

The above mainly talks about my encounter with GO and the initial impact GO has had on me. One night, an idea suddenly popped into my head. The simplicity of the GO language has brought many improvements, and the architecture system I am engaged in Can GO also be used to simplify and reduce system complexity? This idea has been lingering in my head since it popped up. Thinking back to when I first started working on architecture, I was very excited when I saw what principles middleware talks about and what optimizations can improve performance. I studied hard until I felt that I had mastered it (of course I still want to), and then I vowed to use it. In the system, I feel that the more middleware components used in the system architecture, the better. The more middleware components the system has, the more powerful it becomes. But as you do it for a longer time, you will find that the system only needs to be usable, and you cannot build it for the sake of architecture. Subtracting from the traditional technology stack also requires deep knowledge, because only by fully understanding the technical principles can we replace it, and only then can we dare to think and do it without causing problems. As the saying goes: "All continents lead to Rome". From a personal perspective, the architecture must be suitable for the business at that time. The goal of architectural design is to accomplish as many things as possible at the least cost, just like consuming the same server resources. In some cases, it can support several times or even dozens of times of requests. When the same request volume is reached, the implementation and deployment are very simple and operable. GO's thoughts have been subtly influencing me during this period.

Until our company decided to do microservices, we used Java to do microservices at the beginning. Later, I thought about whether other languages ​​​​can also do microservices, and naturally I thought of GO. After a lot of tossing, I felt that it was okay, so I started writing some microservices using GO. As I continued to write, I found that Golang is quite good for writing microservices. It's convenient, it's so efficient, and you don't need to encapsulate Tomcat (it feels very inappropriate to put this thing in a jar package). Binaries can run in docker without system dependencies (try it if you don't believe me). From the bottom of my heart, it's getting better and better. The more I like GO, the more I want to use GO to reconstruct subsequent systems (I write a lot of Java, and when I encounter such convenience, I feel like I discovered spring). GO has deeply affected the view of the system architecture.

But what exactly is architecture, and how is an architect made? Here are the eight stages of hardship in becoming an architect:

The first paragraph: Moving bricks is divided into those who can do it. Those who are good at moving bricks and those who can only move bricks (a group of people stay in moving bricks, and the rest continue to develop);

Second paragraph: Those who can move bricks can be divided into those who need to understand the principles and those who can program and move bricks. Brick;

The third paragraph: Those who understand the principles can be divided into those who are constantly researching and those who have a partial understanding;

The fourth paragraph: The continuous research can also be divided into two types: the research is in-depth, the breadth and the dragonfly knowledge. Breadth;

The fifth paragraph: Those with depth and breadth are divided into purely technical and business types (beginning to differentiate);

The sixth paragraph: The business type requires good communication. Those who have certain design control capabilities for the system and requirements;

Paragraph 7: It is easy for someone to simply use heap middleware to build an "architecture" system at this level (junior architect);

Paragraph 8: A very important point at this level is to consider the problem carefully, comprehensively, and be good at communication. Do the underlying implementation, understand the underlying principles, and start from multiple perspectives of business, R&D, testing, deployment, maintenance and upgrades. The "architecture" built according to local conditions is for development efficiency, operational efficiency, development quality, business flexibility and operational stability. For convenience of maintenance, such people can be called architects (if you have experience in this area, think about how many architectures look beautiful on the surface, but are actually uncomfortable to use).

When building a flash sale system, the traditional technology stacks that first come to mind and are easiest to think of are distributed sessions, Redis clusters, distributed caches, nginx reverse proxy nginx deep optimization, machine optimization, and message queues . Yes, Mr. Cap also thought of this back then, and believed that it would be no problem for these "mature" technologies to be applied to our flash sale system. Moreover, internal discussions within the company felt that there would be no problem with this. And we have done in-depth research, such as:

1. Distributed Session We have put a lot of effort into using Nginx web redis cluster to save Session to achieve the purpose of Session verification, and single-point Session architecture As shown in the figure below:

At first glance, it seems to be no problem. This is how it is done. When the traffic is really big, just add Nginx and web server, which also meets the horizontal requirements. Expansion, but after the traffic reaches hundreds of millions, the cost for our door is a bit high. We also want to squeeze the time of the back and forth network request session (at that time, I always felt that something was wrong), and nginx also appears 504 from time to time under high traffic.

　2. Distributed cache, this thing looks very simple, but it is a very complicated thing in a high-traffic and high-concurrency system. The following problems may be encountered;

　1) Cache Consistency (if this is used, oversold will occur if it is not handled well);

　2) Cache penetration;

　3) Cache avalanche;

　4) Cache black hole Question:

5) Dog pile effect;

　...There are many things that need to be paid attention to. In short, distributed cache is very versatile and valuable, but building a distributed cache system that can meet high concurrency and large traffic requires a very strong technical team. Support, the implementation is also very complicated, so I won’t go into details here;

However, our seemingly problem-free solution has huge problems. It is “too difficult” to implement, and the threshold is high. The resource cost is also quite high. Session must meet horizontal expansion, and web cache must also meet horizontal expansion, including redis cluster. The only way is to continuously add clusters;

Give a simple example ( Putting aside other factors, in order to illustrate the importance of architecture), assume that we have a single machine now, the interface has a processing capacity of 5000QPS (8 cores and 8G), and it has to handle hundreds of millions of traffic for the flash sale. The instantaneous traffic at the start of the flash sale is estimated to be 300W, on average The waiting time is calculated based on 7 seconds (the interface tolerates up to 3.5WQPS). The result is that our system requires nearly 90 interfaces. This does not include other supporting servers with the same requirements. These supporting servers are briefly described as follows. ;

1. First of all, the nginx level must have the same level of processing capabilities (about 2WQPS per unit without optimization, estimated to be about 20 units);

2. The web interface must also be expanded to the corresponding level ( Estimated 90 units);

　3.Reids cluster may be useful if there are multiple products (for individual products, the cluster is useless when there is a large number of visits);

　The above is distributed The machine requirements that Session needs to meet do not include distributed cache. Students can probably feel how difficult it is to build and implement a flash sale system, and the complexity of deployment has not been considered. It's really complicated to implement, and one or two people with 4-5 years of experience really can't complete it in a short time. Can you think of other ways to simplify it? The answer is: yes. First, we must understand the principle, and secondly, we must make subtractions from the architecture. If you don't use it, there is no need to optimize.

Where should we optimize?

1) Session can be omitted in flash kill concurrency based on the principle of permission verification;

2) We can not use distributed Caching (replaced by interface);

　3) Omit nginx (reduces the difficulty of operation and maintenance);

　4)Redis cluster can also be omitted;

　This way Second, how to do flash sales? It’s not that it can’t be achieved with Java and PHP, but it can be difficult to implement, but now it can be combined with GO language features to provide us with new ideas;

　1. Nginx can be omitted , directly use GO to start the port exposure service (nginx can be omitted here);

2. Use cookie method or wt method to replace the distributed Session solution, and server-side code level verification;

3 .Oversold uses interface form instead of redis cluster;

　4.Load balancing uses cheap SLB (avoiding Nginx);

After flash sale optimization, the presidential architecture can be displayed as the structure in the figure below, the detailed method Please refer to "Go High Concurrency Flash Kill Practice":

From the results of the transformation, we mainly list the following:

1. Web applications all use Go For the method of deploying binary files, the centos server does not need to follow any dependencies (which greatly facilitates deployment):

2. Use SLB cheap and practical solution to avoid nginx reverse proxy, and even advanced lua scripts can avoid it ;

3. The redis cluster is also avoided here, and services are provided through interfaces;

The entire technology stack only needs to know: GO, RabbitMQ, and Mysql to complete high-concurrency flash sales The system is very attractive in terms of ease of operation; you can deduce it based on the adjusted architecture below (currently, stand-alone GO provides a web interface, which can probably reach 2WQPS without optimization):

1. The single-machine GO interface permission verification performance has been improved by 4 times, and the deployment complexity can be said to be close to zero (no nginx, no redis cluster, and no dependent environment for operation);

　2. As the traffic level continues to increase To improve, you only need to add web servers and quantity control servers, and there is no other service overhead (the scalability can be said to reduce costs as much as possible, with a proportional growth model and no performance bottlenecks);

　3. Comparison With the traditional solution, the number of servers is reduced by more than 4 times (you can calculate it on the original basis); In terms of implementation, it happens that GO can provide web services and reduce external dependencies (the web service performance itself is also very high). With the two just-in-time features of GO, it is not difficult to implement the flash sale system as a whole by subtracting the matching architecture. Of course, both Java and PHP can implement the adjusted flash sale architecture in the picture above, but from many aspects, , the president still has a clear advantage over GO.

Looking back at the plan, I feel that Go has driven changes in thinking patterns. Its simplicity has led to simple implementation, and its high efficiency and stability have led to architectural optimization. A good system architecture should be simple, efficient, and easy to implement;

The above is the detailed content of When Golang encounters high concurrency instant kill~. For more information, please follow other related articles on the PHP Chinese website!