Extensible database (I)

The extension of the database layer is the fourth layer of the five layer architecture of a typical cloud application , And the most complicated layer （ Some people think that scalable storage systems are more complex , I think , It depends on the business application mode . For applications with complex transaction processing types , The challenge of its database layer implementation is obviously higher ; For simple massive data and simple event processing applications , The database tier doesn't even need to exist , The implementation of cloud storage layer is more complex ）.

There are four types of solutions for database expansion ：

·Scale-Up

·Master-Slaves（ One master and many servants ） Read agent mode

·Master-Master Pattern

·Sharding Pattern

（1）Scale-Up： Vertical expansion

In addition to upgrading the hardware configuration, the vertical expansion method can improve the throughput of the database system , At the software level, it mainly optimizes the table structure , For example, reasonable use of indexes , Avoid multi table Association queries （ Such as multiple tables join）. This kind of method is regarded as typical in the application of the second platform “ Expand ” Pattern . In the cloud application of the third platform , such Scale-up only Obviously, it can not achieve high enough scalability .

（2） Master servant read agent mode

The level of the database layer is scalable （Scale-Out） There are many ways , Among them, the most basic （ concise ） Yes. Master-Slave（ Lord - Servant ） Pattern , Pictured 4-3 Shown . It's usually made up of Master The node is responsible for reading and writing , And by one or more Slave The node is responsible for read-only operations . Such a design is equivalent to improving the data reading performance several times （ And write performance because Master The load of nodes decreases relatively and increases correspondingly ）. We know that most database systems have far more read operations than write operations （ If changed 、 Delete 、 add to ）, Therefore, the acceleration of read operations can effectively solve the performance bottleneck of such systems .

chart ： Implementation of database extension Read-Proxy

Lord - A key point of the slave database design is that only a single node performs write operations , This design can avoid data synchronization caused by multi-point data writing 、 The complexity of replication . Of course ,Master The node is still responsible for synchronizing the updated data sets 、 Copy to all read-only nodes . therefore , In the main - High bandwidth is usually required between slave nodes 、 Low latency to avoid data read / write inconsistencies caused by untimely data replication .

Usually , In the main - In the slave database architecture, we need to add load balancing components to ensure that the application server layer can make full use of Slave Nodes improve the efficiency of read operations . It's important to point out that , The load balancing operation at this layer usually works in TCP/UDP layer , And most of them are customized database operation communication protocols , Not on the application layer LB The standard of layers HTTP/S agreement .

（3）Master-Master Pattern

Ahead Master-Slave Pattern solves the problem of system read scalability , So is there a way to solve the scalability of write operations ？ The answer is yes , Yes . But the complexity will be much higher . Review what we discussed in the previous chapter CAP theory , A strongly consistent database system （ACID System ） emphasize CAP Data consistency in （Consistency）, While multiple nodes support concurrent read and write operations at the same time, it is very easy to cause data inconsistency between nodes . therefore , The biggest challenge of such a system is how to ensure the architecture design adopted by each node to achieve data consistency .

The following is an example ,MySQL The database supports multiple Master Node mode , The data synchronization between them is circular replication （Circular Replication）. in other words , In three database server clusters , In the first cluster Master Node to the corresponding node of the second cluster （Slave） Synchronous data , The node of the second cluster is represented by Master The identity of the node to the third cluster Slave Nodes transmit synchronous data , Finally, the node of the third cluster synchronizes data to the same node of the first cluster . The main reason for this design is to avoid time-order conflict（ timing violation ）, That is, when two or more nodes send an update data set to another node at the same time , When a dataset exists overlapping（ intersection ） when , It is very easy to cause inconsistency in the final data .

chart ：MySQL Ring data replication among multiple master nodes of database （ Sync ）

Avoid in many places Master The solution of data consistency conflict in node database system is nothing more than 4 strip

· Avoid multi node write operations completely （ So it's back Master-Slaves Pattern ）

· Strictly distinguish the differences in the application layer logic Master The write area of the node , Make sure there is no intersection between （ for example , Do not change the same row at the same time ）

· Guarantee different Master Nodes operate on the same region in non overlapping time periods

· Synchronous replication （Synchronous Replication）, Write operations are performed simultaneously on all nodes , And when all nodes are successfully completed , The whole operation will return . This mode obviously requires very high network bandwidth , And in order to meet the data consistency （C）, At the expense of usability （Availability）