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

2018 Feitian Technology Exchange Phase 24-Cloud Database Redis product conference, lectures entitled "Redis Global Live products", "Redis Hybrid Storage products" and "Redis Multithreading performance Enhancement" were delivered by Wang Huan, Huai Ling and Liang Pan, technical experts of Ali Cloud Database Technology Group. This paper gives a brief introduction to Redis, and then develops different products according to different application scenarios, and introduces different products in detail.

In the time-limited discounts of dozens of Aliyun products, click here as soon as possible to get the coupons and start the practice on the cloud.

Review of live video

PPT download address (cloud mark) (listening) (Liang Pan)

The following content is sorted out according to the wonderful video sharing.

Introduction to Redis

Redis is a high-performance key-value database, and Redis has many advantages. For example, its performance is extremely high, with a reading speed of 110000 times / s and a writing speed of 81000 times / s. It has rich data types and can support Strings, Lists, Hashes, Sets and Ordered Sets data type operations in binary cases. All its operations are atomic, meaning either successful execution or failure does not execute at all. It also has rich features, that is, support for publish/subscribe, notification, key expiration, and so on.

Redis and other key-value cache products have three common characteristics: first, Redis supports data persistence, which can be saved in memory on disk and can be loaded again when rebooting; second, Redis not only supports simple key-value type data, but also provides storage of list, set, zset, hash and other data structures; third, Redis supports data backup, that is, master-slave mode data backup.

Redis differs from other key-value stores in that Redis has more complex data structures and provides atomic operations on them, which is an evolutionary path different from other databases. Redis's data types are based on basic data structures and are transparent to programmers without additional abstraction. Another difference is that Redis can be persisted to disk when running in memory, so memory needs to be weighed when reading and writing high-speed data sets, because the amount of data cannot be larger than hardware memory. As a result, it is easier to operate in memory than the same complex data structure on disk, so Redis can do a lot of things that are intrinsically complex. At the same time, they are compact and appended in terms of disk format, because they do not require random access.

Redis global multi-live products

Redis global live product means that multiple Redis instances are distributed in different regions of the world. It is a multi-active database system developed by Aliyun, based on Redis version of cloud database (ApsaraDB for Redis), and 100% compatible with Redis protocol. Through the data synchronization channel, multiple Redis instances are networked into a logical Redis multi-active instance, and all instances in the multi-active instance can be read and written and keep real-time data synchronization. The data synchronization channel is connected through the intranet, which has the characteristics of high reliability, high security and low delay. CRDT (Conflict-free Replicated Data Type) mechanism is used to detect and resolve data conflicts between sub-instances to ensure the final consistency of data. Redis global multi-live products easily support business scenarios in which multiple sites provide services at the same time, helping enterprises to quickly replicate Alibaba's remote multi-live architecture.

The road to high availability architecture walkthrough

Programs always encounter a variety of problems in the process of running, such as program bug, machine failure, computer room power failure, fire failure, and so on. In business, it is required to ensure data consistency and business availability when these failures occur, so there is a road to architecture exercise, that is, single availability zone-disaster recovery in the same city-two places and three centers-multi-location activity.

Since the single availability zone architecture is unable to cope with the failure of the data center, there is a disaster recovery architecture in the same city. Because the urban disaster recovery framework can not cope with the problem of regional level, then there is a two-place three-center structure. Since many financial businesses require data to be stored in different regions and fault recovery time, the two-place and three-center architecture adds a standby center on the basis of disaster recovery in the same city, but there are still several defects, that is, the cold backup center does not work and dare not cut at the critical moment; the cold backup center does not work and the cost is wasted; in essence, the data is still written in a single point, and the database bottleneck cannot be solved. Defects that cannot be solved by resources, disaster recovery and expansion.

Later, there was a remote and multi-active architecture, which means that all centers provide business services, and the underlying data can be synchronized with each other, so there are many advantages, for example, all center work, switching is guaranteed; all center work, low cost; self-scaling, increase / reduce the number of centers; when failure independence causes the center to be unavailable, it only affects some users.

Product architecture

Cdn.com/ef66f12c2d1197bdc9b6225d0508d1960b998a58.jpeg ">

The architecture diagram of multi-live products in remote locations is shown in the figure above, which is composed of three parts: cloud database Redis instance, synchronization channel and channel manager. Because remote multi-activity is composed of multiple Redis instances, it can achieve real-time data synchronization between each sub-instance, final consistency of data for each sub-instance, and read and write for each sub-instance.

In the remote multi-activity architecture, the transformation of aof binlog adding oplog and CRDT strategy merge key to Redis is carried out, in which aof binlog adds gtid and logical clock information in oplog, which solves the problem of circular synchronization and Exactly-once Apply, and the problem of consistency is solved in CRDT strategy merge key.

Multi-live products in remote locations have the characteristics of high availability, high performance, consistent data and rich features. Details are as follows:

High availability

High availability means that the synchronization channel supports the continuation of the breakpoint, which can tolerate the partition at the day level at the highest level, and the data can continue to be synchronized at the breakpoint after the partition. At the same time, the synchronization channel can also adaptively handle sub-instance exceptions, such as master / slave switching, slave database relap, and so on.

High performance

High performance means that it has asynchronous replication synchronization and does not affect the read and write performance of Redis itself, because it itself has high performance, high throughput and low latency performance. High throughput means that it has a standard version of Redis that makes the one-way synchronous link up to 100000 TPS and the cluster version Redis which expands linearly with the number of Redis nodes. Low latency means that it takes only 100 milliseconds for intercontinental regions and, more importantly, only 1 second for intercontinental regions.

Final consistency

In order to solve the consistency problem caused by the logic of asynchronous synchronization in the past architecture, the CRDT (Conflict-Free Replicated Data Types) strategy is introduced, which can support the final consistency of data types such as String/Counter, Hash, Set, Zset, Geo, hyperloglog and so on.

Rich in function

New features have been added to support Redis instance types, synchronized sub-instances support modified specifications, and add and delete sub-instances. The supported Redis instance types include standard version, cluster version and read-write separate version.

Business design

Remote multi-live business has different business design requirements. It must allow multiple regions to modify the same data at the same time, such as global session, global PV, user favorites, shopping cart, geographic location information, favorites, historical search records, on-screen comments, and so on. At the same time, it also needs to do data segmentation, requiring that only one write point is allowed for a piece of data.

The key points of multi-active service design are self-inclusion, loose coupling and consistency of routing rules, that is, all calculation and data of multi-active service design must be completed in one center; service invocation can only be carried out between units. Database or other storage cannot be accessed directly; routing must be ingress route or micro-service invocation route.

Redis hybrid storage product

Redis hybrid storage instance is a hybrid storage product independently developed by Aliyun that is fully compatible with Redis protocols and features. By storing part of the cold data to disk, on the basis of ensuring that most of the access performance does not decline, the user cost is greatly reduced, and the memory limit on the amount of data of a single instance of Redis is broken.

Technical architecture

Its data type is to store hot data in memory and cold data in disk. As the name implies, hot data refers to frequently accessed data. Because all Redis will access Keys, relatively speaking, Keys is inherently much more accessible than Values, so Redis hybrid storage products store all Keys and frequently accessed Values in memory, while infrequently accessed Values is stored on disk. In a business scenario, Keys takes up only a dozen bytes, but Values accounts for hundreds or even thousands of bytes, so putting all the Keys in memory can greatly improve the overall performance.

The Redis hybrid storage architecture is shown in the figure above. From the business model, we divide the Redis hybrid storage architecture into three layers. The first layer is the computing layer, which contains all Redis business logic such as network connection, protocol parsing, timing tasks, command processing, expiration, phase-out, synchronization and so on. The second layer is the data layer, which contains hot data representation, cold and hot data exchange, cold data coding and decoding. The third layer is the storage layer, which contains the storage engine, file system, and hardware management.

Among them, the hot and cold exchange in the data layer is to ensure compatibility, because all the business logic of Redis is handled by the main thread, and all the actual IO is run by the background, which will not block the operation of the main thread. In the process of converting hot data to cold data, when the amount of data is less than memory, Redis hybrid storage will put all Keys and Values in memory, which can achieve the highest performance. When the amount of data becomes larger and larger, there will be no storage in memory. Some rarely accessed Values will be filtered according to the recent access frequency, and then the IO task will be generated by the main thread, and then the background IO thread will get these tasks and store them to disk. Finally, the main thread will release these Values. In the process of converting cold data into hot data, after receiving the user's request, first determine which Values will be accessed by the task request, and then see if the Values is all in memory. If part of the Values is not there, it will generate IO tasks for these Values, then the main thread will suspend the client, and then continue to process requests from other clients. When this thread gets these tasks, it will load the data from disk into memory. At the same time, the main thread is notified that after receiving these notifications, the main thread will wake up the suspended client to continue processing other user requests.

For the storage layer, storage on disk is a user-mode storage engine built with Alibaba's server development team, called FusionEngine. It is by the business to customize a RocksDB, and then through the underlying user solid file system to shorten the user's IO path, thus avoiding the kernel overhead. In business scenarios, the performance of FusionEngine is about 80% higher than that of file systems in the past, so the overall performance of Redis hybrid storage has also been effectively improved.

Product characteristics

The underlying solid line of Redis hybrid storage products supports arbitrary matching of hot and cold data, that is, it can arbitrarily match the amount of memory and disk occupied, so as to achieve a balance between performance and cost. In the application, the amount of data should not exceed the capacity of memory plus disk. This product is suitable for scenarios with large Values, because Values does not have a great impact on performance, so it is also suitable for scenarios where data access is uneven between hot and cold. At present, the available areas of hybrid storage are the availability zone D of North China 2 (Beijing), the availability zone E of East China 1 (Hangzhou), and the availability zone C of South China 1 (Shenzhen).

Application scenario

The scenarios of Redis hybrid storage product applications include e-commerce applications, live streaming applications and Internet applications. For e-commerce applications, its active commodity data is stored in memory, while unpopular product data is stored in disk. For live streaming applications, the data in its active live room and popular live room are stored in memory, and the data in offline live room and unpopular live room are stored in disk. For Internet applications, its home page and popular post data are stored in memory, and unpopular posts are stored on disk.

Redis multithreading performance Enhancement

The performance enhancement version of Redis multithreading breaks through the performance bottleneck of Redis single thread, and is 100% compatible with native Redis, and the business does not need to modify any code. By distributing command parsing, reading and writing, response and other events to multiple IO threads for concurrent processing, we can achieve a qualitative leap in processing performance.

Technical architecture

The native Redis is processed serially. When it receives a request, it will try to connect to read a part of the data and parse it. If it parses to a complete data, it will process the data. When the data is processed, a response to the data is generated and sent to the client. One drawback of native Redis is that it cannot achieve concurrency. Relatively speaking, a Master-Slave architecture done by Redis multithreading can achieve concurrency, which synchronizes the data to the Slave after processing the Master data.

As shown in the figure above, the Redis multithreaded performance enhancement is made up of the main thread, multiple IO threads, and worm threads, which are mainly responsible for accepting connections, creating client, and forwarding connections to IO threads. The IO thread handles the read and write events of the connection, parses the commands, forwards the complete parsed commands to the WORKER thread, sends response packets, and is responsible for deleting the connection, etc.; the worm thread is responsible for the processing of commands, the generation of client return packets, the execution of timer events, and so on.

During the exchange of inter-thread data, an IO thread starts to try to read the request on the connection after obtaining the connection, and then parses the request. If it is a complete request, it will put the request in the queue. Next, the IO thread notifies the WORKER thread that there is a new command to process, which is done through the pipeline. Finally, when the WORKER thread receives the command, it processes it, forms a response to the command, and puts the response into a queue, just as the WORKER thread notifies the IO thread.

Product characteristics

The more IO threads, the better the performance of Redis multithreads, but the performance of IO threads and Redis multithreads is not linear, when the number of IO threads reaches a certain number, WORKER will reach a bottleneck. Therefore, up to six IO threads are supported, and there is only one IO thread by default. In addition, it should be noted that the number of threads is bound to the specification, and once the selected instance is created, it cannot be modified dynamically. If you need to modify it, you need to upgrade the specification.

Redis multithreading is not applicable in all scenarios. Redis multithreading is only suitable when the master / slave version cannot meet the performance requirements, when the cluster shard node becomes a performance bottleneck, when the read-write separation version has hot-write bottles, and synchronization delay.

Application scenario

Redis multithreaded performance enhancements are mainly used in e-commerce applications and live streaming applications. For e-commerce applications, they are suitable for second kill scenarios and inventory counting. For live streaming applications, they are mainly suitable for live streaming of hot spots and big Vs.

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.