Project Sharing-the implementation of limited-flow framework

background

I've been thinking about how to make this project clear before the opening, and it's easier to accept if the Internet company has a high concurrency scenario for that content. Here is a background: The code was written in April 2013, the beginning of the prototype was written in 2012, from another project, code intrusion is relatively strong. I carried out the stripping in April this year to achieve the pluggable control. Back then, I was very interested in the field of performance, so I was wondering how to write a framework for performance monitoring of existing projects for class level (strictly speaking method level). Since it's performance monitoring, it's easy to find three questions to answer: first, how many concurrent requests this method has. Second, the response time is how much. What is the optimal number of concurrent requests? these three questions are actually derived from the framework that we are going to talk about today: to ensure the usability of applications, real-time monitoring of the number of concurrent nodes, response time and so on. (throughput and response time are allelopathy, so you'll find an optimal balance before both, which is often the best concurrency number.) The optimal number of concurrent requests in the ideal state is the current limit threshold we want to set here. the significance of current limiting

Let's use a simple diagram to see where the current limit frame is located.

When you look at this picture, it's estimated that a lot of people subconsciously think of spring interceptors, and it's very much like this, and the principle is similar. And there are two ways to implement it later: one of these is based on the spring interceptor. The other is actually the JDK's dynamic proxy to achieve. I don't know if anyone will ask why you want to limit the flow. here are some simple explanations. To cite a simple example: The Yangtze River's Three Gorges Dam, in addition to power generation, another role is flood control, if the flood, there is no Three Gorges Dam, it is likely to the downstream production of major floods. The reference to us here is actually the same. When the number of requests is abnormally high (flood), the load on the application will also rise abnormally, so the direct effect is that the whole response time slows down, and worse, the system crashes directly. Not only that, because the system is all connected before, it's very easy to have an impact on the related applications it relies on (a bit like a domino). One of the big implications of limiting flow is to ensure the usability of the application , and it's important to understand why the current limit is needed. UML class Diagram

Next look at the entire UML class diagram:

This diagram is relatively simple. Here I have simplified the entire current limit, in the full version there will be data storage and response time monitoring. The starting data is stored in DB, then to learn some of the core knowledge of the database so I write a very simple storage (the meaning of write storage is just to learn, just want to know the whole storage in the space allocation of some ideas, for the SQL protocol that a piece of no more involved). The details about storage are not discussed here.
Back to this picture, as I said earlier, I have used two ways to implement: One is the Spring interceptor mode, the other is the JDK proxy. Code Show

Next look at a few classes of code, where the most core of the class is Flowmonitor.java, the specific logic of the current limit is inside. The following will be the specific code posted, when you see the code is estimated to feel that this thing is too simple. I will throw more questions below, which are not implemented in this article. Flowmonitor class

/** * The function of the limit current * Implement a buffer queue, let a part into the waiting state * interval monitoring * What if a thread returns particularly slowly, like throwing an exception before release * @author hundred 2013-04-11 11:26:36 *  
    /public class Flowmonitor {//The default maximum number of concurrent defaults is 100, you can configure private int maxflowsize = 100;  

    Maximum concurrent number private int maxrunningsize = 0;  

    Current concurrency number private Atomicinteger runningsize = new Atomicinteger ();  

    Number of passes through private atomicinteger passsize = new Atomicinteger ();  

    Number of failures private atomicinteger losesize = new Atomicinteger ();  
    Public Flowmonitor () {super ();  
        Flowmonitor (int maxflowsize) {this ();  
    This.maxflowsize = maxflowsize; 
     /** * thread into the switch, even if there are some atomic classes here, there will still be concurrency problems.  
            * @return/public Boolean entry () {//a configuration in each class Maxflowsize if (maxflowsize>0) {  
                if (Maxflowsize<=runningsize.get ()) {//has exceeded the maximum limit losesize.incrementandget (); return FALSe  
            //Concurrency number +1 runningsize.incrementandget (); if (Runningsize.get () >maxrunningsize) {//record maximum concurrency number, concurrency problem maxrunningsize = runningsize  
            . get ();  
        }//record number of threads passed Passsize.incrementandget ();  
    return true; /** * After execution, concurrency number-1 * @param key/public void release () {Runningsize.decrementan  
    Dget ();  
    Public Atomicinteger getrunningsize () {return runningsize;  
    Public Atomicinteger getpasssize () {return passsize;  
    Public Atomicinteger getlosesize () {return losesize;  
    public int getmaxrunningsize () {return maxrunningsize;  
        /** * Reset, can be monitored in a period of time * * public void Reset () {passsize.set (0);  
        Losesize.set (0);  
    maxrunningsize = 0;  }  

}

The two most core methods in the above class are: one is entry () and one is release () . Entry () is called before the target method is invoked, and release () is invoked after the target method is invoked. For the code level there is not much to read, there are some comments in the code, it is estimated that the study of Java can understand what is written above. In the comments on the class I wrote a few questions:
The first is to implement a buffer queue . My handling strategy above is one of the easiest ways to do this: do nothing else as long as the current concurrency number is greater than the current set maximum number of concurrent returns false. The second problem with
is that if the process of handling specific logic exits so that the release () method does not execute, the current monitored concurrency number is not normal. So here's a workaround: You can implement a queue where each node on the queue is a concurrent request, and when you execute the entry () method, you insert a node into the queue and then move the node out when you execute release (). The node is then removed when it is discovered that the concurrent request exception, which can be judged by time, such as the interruption of over 5s, has not yet been returned. This allows more accurate monitoring of the current number of concurrent concurrency.
The third issue is the question of monitoring data, which can only be monitored for a few data: total number of passes, total number of failures, maximum concurrent number, current concurrency number . If I want to implement a requirement that I want to monitor for a certain period of time, the point is that once there is a problem (for example, if the number of failures goes up) I can clearly see at what point the node is having problems. And the current way of implementation is not possible. In the above class I left a reset () method, the meaning of which is to implement the monitoring of the time segment to provide a reset of several parameters of the interface. The fourth problem here is that I do not know the method's RT (response time: Here is the time to perform this method) monitoring, which can also be implemented. Because this article focuses on limiting the flow, so do not want to talk too much about RT of things. You are interested can also be implemented on their own, the principle is the same: still use interceptors to achieve, the specific implementation strategy can be varied. Monitorhandler class

/** 
 * TODO Comment of Monitorhandler 
 * @author hundred 2013-4-9 a.m. 10:16:43 
 * * 
 * * Public  
interface Monitorhandler {public  

    Boolean before ();  

    public boolean after ();  

This interface does not make any explanation, you can refer to the UML class diagram to see where it is located. Abstractspringmonitor class

/** 
 * TODO Comment of abstractspringmonitor 
 * @author hundred 2013-4-9 pm 04:42:04 
 * * 
 * * Public  
Abstract Class Abstractspringmonitor implements methodinterceptor,monitorhandler{  

    /* (non-javadoc) 
     * @see Org.aopalliance.intercept.methodinterceptor#invoke (org.aopalliance.intercept.MethodInvocation) 
     * *  
    Override public  
    Object Invoke (Methodinvocation method) throws Throwable {  
        Boolean result = before ();  
        if (result) {  
            try{  
                method.proceed ();  
            } catch (Exception e) {  

            } finally{after  
                ();  
            }  
        return null;  
    }  
}  

Springflowmonitorhandler class

/** * using spring Interceptor for monitoring * * @author Hundred 2013-4-9 pm 06:36:24/public class Springflowmoni  

    Torhandler extends Abstractspringmonitor {private Flowmonitor flowmonitor; * * * (non-javadoc) * @see Com.yuzhipeng.monitor.monitorhandler#before ()/@Override public  
        Boolean before () {if (!flowmonitor.entry ()) {return false;  
    return true;  
    }/* * (non-javadoc) * @see com.yuzhipeng.monitor.monitorhandler#after ()/@Override  
        public Boolean after () {flowmonitor.release ();  
    return true;  
    Public Flowmonitor Getflowmonitor () {return flowmonitor;  
    public void Setflowmonitor (Flowmonitor flowmonitor) {this.flowmonitor = Flowmonitor; }  
}  

The two classes posted above are implemented in the way of spring, because this method will also be used more in the project. Another approach to the JDK dynamic proxy code is not posted, the implementation of the method is very simple. Summary

Here is a simple sharing of the meaning and implementation of the "current limit". In the article I also cited an example of why to limit the flow. In the traditional internal system, the significance of the current limit is not significant. If you are in an Internet company, you will need to use a current limit when you have high performance requirements. Later on the specific implementation of the estimate will feel more simple, the amount of code is very small. Here it goes back to Spring's AOP, the use of interceptors. Same, spring's use (the idea that it should be the interceptor in strict terms) is very broad. Usually use more likely is the permission checksum, log record these.
One of the important ideas that I convey in every blog is " thinking ." The implementation of this article is not perfect, for example, my comments in the Flowmonitor class also said there would be concurrent problems, but I didn't lock it up there and that's why. The important idea here is that there is still a balance in programming . One example we often encounter is " time for space, space for time ". So I'm really going to lock it from the code level here, but it's a better strategy to do it from the actual application.

Reproduced from: http://blog.csdn.net/luohuacanyue/article/details/14055715