Redis + webdis for data sharing or hitting analysis

Now the communication between various testing systems involves napoli messages, http or dubbo interfaces, which are not very flexible and will not be evaluated for their advantages and disadvantages. The idea of memory sharing between various systems is described today.

Redis is used to access data. redis supports richer data structures, such as list, set, and map. There are also a variety of client support, a total of dozens, and even better, there is an open-source project webdis, which can support providing Restful HTTP interfaces, such as http: // 10.20.142.160: 7379/get/foo.txt. With it, js can operate redis. The frontend and backend are connected. Imagine that a new piece of data is added to the java background, and the foreground can get it immediately, or the foreground user can record it permanently after performing a touch operation, instead of storing data locally, it is not flexible to call backend interfaces for storage.

The three application scenarios of yundun are:

1: The defects raised by various systems. Now we need to open up an additional field in each system to store this association relationship. For example, in the test management system, a bug is raised above the case with the case Id of 123, A record such as the case id, defect Id, and defect type should be stored. If redis is used for storage and webdis is used as the client, a few JavaScript files on the page can complete this function.

2: General session. Now all systems use the same buc for login, but some information after login cannot be shared, such as some user preferences, after logging on to the test management system, I chose to pay attention to a product line. After arriving at the performance warning center, it is also the product line by default. So is Amon. This experience may be good.

3: click/Report. Currently, monitoring involves various means, such as process monitoring, page monitoring, and hudson plug-in monitoring. However, this data cannot be summarized and displayed, for example, the monitoring data of hudson plug-in cannot be saved. It can be optimized to store data to redis in a predefined format, and then display the data on a unified page. For example, the plug-in can calculate the pressure on each executor (number of tasks) in each time period, and the background agent can calculate the memory, cpu, load, and other conditions in the time period, and then summarize the page for analysis, several graphs are obtained, and the optimal task arrangement can be further analyzed.