Improve concurrent throughput design for Redis client multithreading operations more effectively

Redis is a very efficient memory-based NoSQL database, It provides very efficient data read and write performance. In practice, bandwidth and client library read-write losses are too high to make redis better capable. The following combines some of the features of Redis itself and some changes in client operations to improve traffic across Redis operations.

is a reflection of the usual operation of Redis, each of which initiates a corresponding connection to the Redis network. Although we can combine the current multiple operations into one by batch operation, this method can only be used for single-threaded Multi-threaded merging is rarely a concern in design. There is no limit to the Redis protocol, but the client library design is generally not considered.

If you are able to combine network operations while working with Redis at the same time, it means that you can reduce the operation of the network to read and write to maximize processing power. As a result, the overall performance of the client is improved, and Redis achieves better utilization due to lower surface network reads.

The above is a design diagram, the principle is not complex, in fact, the operation of each request is put into a queue, followed by a thread to carry out the previous instructions for a merge operation. A thread can not be merged more quickly under high concurrency, and can be applied reasonably as needed.

Is the effect of this design really more ideal, to one is a simple test

            public void Anycset () {codetimer.time ("Beetle.redis Asynset", () = {parallel.for (0, Count, x = = {Protobufkey key = X.tos                        Tring (); Key. Asynset (New User () {UserId = x, nickname = " Sdffffffffffffffffffffffffffffffffffffffffsdffffffffffffffffffffffffffffffffffffffffbeetlesdfffffffffffffffffffffffffffff                    Fffffffffffsdffffffffffffffffffffffffffffffffffffffff "+ x}";                });            });                    } public void Set () {Codetimer.time ("Beetle.redis set", () = = { Parallel.For (0, Count, x = = {Protobufkey key = X.tostring ()                        ; Key. Set (New User () {UserId = x, nickname = " Sdffffffffffffffffffffffffffffffffffffffffsdffffffffffffffffffffffffffffffffffffffffbeetlesdfffffffffffffffffffffffffffff FffFfffffffsdffffffffffffffffffffffffffffffffffffffff "+ x}";                });            }); }

The test results are as follows

The above is a 10W operation test result, because Redis is in the native so the interaction is very considerable.

Although in multithreading high concurrency under such a design can have a very good performance of throughput and performance, but it also has a flaw because each operation is a different thread of the processing, if the concurrent threads are not much operation density is not high. The effect is not ideal, because the network operation density is not high, can get the number of combined and not many, This loss is likely to be less than the loss caused by the operation's cross-thread scheduling.

Improve concurrent throughput design for Redis client multithreading operations more effectively