Shulou(Shulou.com)06/01 Report--

Nginx+KV db how to carry out AB grayscale testing, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

I have heard some scenarios of using nginx in Taobao before, in which the grayscale test of AB may be more common, of course, the implementation was not discussed in detail at the conference.

The general demand is: when the website business updates the new feature, it does not want all users to see it, and can open this feature for regional users. Probably conceived a way to use the nginx+redis/memcache+IP library to implement, the simple flow chart is as follows:

Of course, new feature server and normal server do not have to be physical servers, but can be any logically separate service and http URI.

The module used is ngx-lua-module, and a lib: lua-resty-memcached or lua-resty-redis written based on ngx-lua. It is assumed that memcached is used as the storage of ip data, ip as key, and true (1) or false (0) as value data in cache. When the request comes, nginx uses remote_addr from cache (if XFF header is used, XFF is processed to get real ip) as key to do get from cache. Determine whether this req should be forwarded

There is a question here: whether to save the specific IP form in cache, or to store it in the supernet situation of CIDR, if you directly use IP as key, the amount of data can not be underestimated, and the accuracy of IP information must be guaranteed. If you use CIDR, you will add another IP conversion CIDR on nginx and compare the get to CIDR (the specific implementation method has not been expected), and the complexity will increase. Individuals prefer to directly use IP as key, as long as the accuracy of IP is ensured, the data size is not a big problem. Now there are caches with 32GB memory everywhere.

If you use ip as the key, a compromise is to save only the ip data of the specified region in the flush cache every time you ABtest. When ngx does get, if it does not return, it is considered that the req is to normal server.

In terms of management platform, you only need to do a simple batch set cache function. As for UI, it depends on who you use it. For your own use, the ugly spot of UI is ugly.

Performance and availability:

Added a cache connection and get operation, in theory this overhead should be very small, ngx-lua implementation of lua-resty-memcached has been tested by many people, the performance is very considerable.

In terms of usability, there will be a risk point when caching is broken. Through settimeout, the cache timeout is limited to a small time with less impact. In addition, the ABtest solution should not be online all the year round. This system is only needed when there is a need. Therefore, the impact of usability on the overall situation should be small. Compared with the risk of affecting all users when the new feature is launched, this risk is worth it.

For the time being, the above is only a personal idea, and it has not been used online yet. In the aspect of implementation, only the verification of nginx obtaining key to judge req forwarding has been completed.

This is the answer to the question about how Nginx+KV db carries out the AB grayscale test. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.