First, Redis distributed structure interpretation

First of all, the understanding that Redis adopts decentralized design is not in place. The distributed mode of Redis has two types: master-slave and cluster. The cluster scheme of Redis Community, Redis Cluster, adopts decentralized design. Let’s take a look at the evolution of Redis:

The figure above shows the standard Redis master-slave mode. Only the Master receives write requests and copies the data to one or more slaves. This creates a good read/write separation mechanism, and multiple slaves can share read operations. Therefore, Redis is a standard distributed and centralized idea.

Since most of the application scenarios of REDis are extremely concurrent MEMORY I/O, in the master-slave mode shown in the figure above, the Master has to undertake both writing and replication of internal nodes. The resource consumption of the Master is very high, and this problem becomes more and more obvious as the number of slave nodes increases. Therefore, REDis also forms a variant form of the master-slave mode:

The diagram above shows a tree structure of the Master/slave topology of Redis. The advantage of this topology is that the Master does not need to copy data to countless slave nodes and hand it to the slave nodes at the next level. This takes as much of the Master’s work out of replication as possible.

The problem is that in high-concurrency business scenarios like this one, the Master is always a concern because it takes on all the writes and if it crashes, the cluster as a whole becomes unusable without an HA solution. Therefore, the redis community launched the cluster solution, in fact, to solve the master pressure, naturally considering the use of cluster distributed agnocentric mode.

In the figure above, the central mode of the cluster is shown on the left and the non-central mode used by Redis Cluster is shown on the right.

Redis Cluster: Redis center USES the concept of virtual channel, it is independent of the physical nodes, often easily put this confusion, virtual slot with 0 ~ 16383, the redis data, the hash key (specific formula online a lot), determining the data which is into the slot, and physical node is responsible for which virtual slot, which is specified by us.

Such as: When the data of 1 G is written into the Redis cluster according to one key record, each node of the cluster calculates which slot and which node the record should belong to as long as it receives the data, writes the data mapped to the slot to the local node, and gives feedback to the node that the client really needs to write to if it does not belong to itself. The client then initiates a second request to the node where the record belongs, which completes the fragmentation of 1 GIGAByte of data in the cluster.

Regardless of the advantages and disadvantages of Redis cluster, we can see the evolution process of the master-slave structure of Redis to cluster from the above evolution. In fact, it is a process of de-centralization, which is to make the concurrency performance of multi-client multi-business requests get better load. In addition, for high HA reliability, each node can be deployed in master/slave mode. Even if the master node goes down, Salve will take over. The disadvantage of HA is that it doubles the number of nodes.

The biggest difference between Redis and RocketMQ is that redis is more focused on the high-concurrency processing of online services, which is the heavy reception and consumption of massive backlogged data streams. Therefore, the purpose of choosing distributed architecture is different. Of course, this does not mean that centralization is not suitable for high concurrency. For example, Oceanbase represented by LSM-Tree, as a centralized processing feature, can well achieve high concurrent writing of online business and high-speed hot data (latest time) search.

In addition, because every node in redis cluster is equal in distributed mode, there will definitely be the risk of consistency in cluster management. Because all kinds of abnormal situations are very special in production environment, different nodes will lead to inconsistent recognition status of cluster. Therefore, manual intervention to adjust the state of each node in the cluster will increase.

Distributed interpretation of Kafka and RocketMQ

Let’s take a look at Kafka, better known than RocketMQ, and explain the distributed nature of The Kafka cluster.

Kafka’s cluster management comes from the ZooKeeper cluster. Broker registration is found. Broker Controller elections are assisted by ZooKeeper, but the Controller does not actually do anything during message processing. Just take the lead on other nodes in creating partitions, rebalancing partitions, and so on.

What Kafka really does is use the partition leader and partition follower. For example, if a topic is divided into four partitions and three copies, then 4*3=12 copies of the partition. If there are four brokers, each broker will be evenly distributed in the form of one primary and two secondary partitions.

The partition relationship in Kafka is the communication form shown above. The producer (Product) gets Meta information from any node, finds a copy of the leader partition in the broker, and writes the assigned data to it. The leader copies the assigned data to the follower partition copies of other brokers in the cluster.

Under this partitioned structure, each broker actually has the Master capability of topic partition data request access and replication. So you asked me if Kafka is central.

Take a look at Kafka’s Ali brothers, RocketMQ

Rocketmq’s architecture has been discovered without using the ZooKeeper cluster as a registry of services

The RocketMQ Queue pattern is very similar to Kafka, but has its own characteristics in the details of operation. It is more suitable for high-concurrency, more topic, and sequential business message processing. For example, topics are divided into multiple fragments, and partitions are divided into multiple queues. Each Queue corresponds to only one consumer to achieve load balancing on the consumer side with higher concurrency. I won’t bore you with the details. Let’s focus on the distributed nature of RocketMQ.

A NameServer is a registry of brokers. A newly registered broker or an abnormal exit broker reports to or is aware of the corresponding NameSever. Nameservers share information by locking their registries. NameServer adds/deletes brokers to the registry and periodically reads the latest information about all brokers in the cluster.

The Producet connects to a NameServer and obtains the desired brokers for sending partitioned data. Similarly, the process of sending and consuming data is similar to that of Kafka operation topic, but more detailed to the level of queue under topic.

Another feature of RocketMQ is that each Borker can be subdivided into a master/slave mode, with the master performing queue operations and the slave performing data synchronization and waiting for the master to fail.

Rocketmq’s Namesever has a simpler structure than ZooKeeper. Producer and consumer access to brokers and partitions must come from Namesever, even though the Namesever cluster itself is centrless. However, the entire RocketMQ brokers are centrally managed by Namesever. However, the product, consumer, and brokers clusters as a whole are not highly dependent on this centralized management and only provide simple broker meta-information services. The actual flow of data is left to the individual brokers themselves.

Kafka’s broker partition information is distributed in the meta cache of each broker. Producers and consumers can obtain the leader partition information needed to operate on any borker. Kafka is somewhat de-centric. However, the meta cache information is essentially from ZooKeeper, which must be relied upon, so Kafka is still centrally managed.

Oceanbase Distributed architecture

Oceanbase is a typical implementation of LSM-tree. For LSM-tree, you can see my other answer to TiDB, which mainly describes the characteristics of RocksDB’s LSM-tree: Why do distributed databases like to use KV Store so much?

As the Oceanbase architecture, I won’t say too much this time, but just to summarize, oceanBase architecture is very cleverly integrated into the idea of Lambda architecture, but the Lambda architecture is different from the Lambda architecture. Lambda architecture focuses on computing, whereas OceanBase is storage.

Oceanbase usually deploys the rootServer and updateServer on the same node and functions as a distributed center.

RootServer is used to manage the cluster.Copy the code

UpdateServer is used for incremental data updates, which are performed in memory as much as possible, resulting in the most efficient query for recent incremental data, usually the current day data.

ChunkServer is used to store baseline data, which is usually historical data every other day.

MergeServer accepts SQL from the client for interpretation, and merges query results of updateServer and query results of different chunkServer nodes, usually querying and merging the incremental data of the current day and historical data of the next day.

This is very similar to the speed layer, batch layer, and service layer ideas of the Lambda architecture. When the customer sends a query and statistics request, updateServer meets the real-time query and statistics of the incremental data of the day, and the chunkServer node provides the distributed query of the baseline data. Finally, mergeServer merges the updateServer data of the day and the baseline data of each chunkServer. Feedback to the client, oceanBase architecture design is a work of art.

conclusion

This article mainly introduces the architecture features of decentralized management of Redis Cluster, Kafka and RocketMQ in distributed mode, and incidentally mentions some architectural features of Oceanbase.

Message queue architectures rely very little on centralized patterns, and RocketMQ simply uses Nameserver for broker registration discovery. I think Kafka could do away with ZooKeeper in future designs and take a more decentralized approach to registration and discovery.

In contrast, the most mature scheme of Redis is still master-slave. The performance advantages brought by Redis Cluster cannot offset the immature and unreliable problems brought by decentralization, resulting in the complexity and difficulty of human operation and maintenance. So use Redis Cluster with caution!

Oceanbase’s architecture is very elegant and artistic. Take time to understand and practice and write an article. Oceanbase is similar to Google’s Bigtable and Hadoop’s Hbase, but it integrates the idea of Lambda architecture on it. Make the system more responsive to actual needs and more flexible and reliable. But clusters require a lot of resources.

I’m a “Read Bytes” creator who delves into big data technology and interprets distributed architectures

Head over to Byte Read Zhihu — learn more about big data

Public id Read-byte “Read bytes” Distributed, big data, depth of software architecture, professional interpretation