10分钟搞懂：亿级用户的分布式数据存储解决方案！

分布式数据库和分布式存储是分布式系统中难度最大、挑战最大，也是最容易出问题的地方。互联网公司只有解决分布式数据存储的问题，才能支撑更屡次亿级用户的涌入。

接下来，你将花费十分钟掌握如下三方面内容：

一、MySQL复制：包括主从复制和主主复制；

二、数据分片：数据分片的原理、分片的方案、分片数据库的扩容；

三、数据库分布式部署的几种方案。

1、MySQL复制

1.MySQL的主从复制

MySQL的主从复制，就是将MySQL主数据库中的数据复制到从数据库中去。

主要目的是实现数据库读写分离，写操做访问主数据库，读操做访问从数据库，从而使数据库具备更强大的访问负载能力，支撑更多的用户访问。

它的主要的复制原理是：当应用程序客户端发送一条更新命令到数据库的时候，数据库会把这条更新命令同步记录到Binlog中，而后由另一个线程从Binlog中读取这条日志，而后经过远程通信的方式将它复制到从服务器上面去，从服务器得到这条更新日志后，将其加入到本身的Relay log中，而后由另一个SQL执行线程从Relay log中读取这条新的日志，并把它在本地的数据库中从新执行一遍。

这样当客户端应用程序执行一个update命令的时候，这个命令会在主数据库和从数据库上同步执行，从而实现了主数据库向从数据库的复制，让从数据库和主数据库保持同样的数据。

2.MySQL的一主多从复制

MySQL的主从复制是一种数据同步机制，除了能够将一个主数据库中的数据同步复制到一个从数据库上，还能够将一个主数据库上的数据同步复制到多个从数据库上，也就是所谓的MySQL的一主多从复制。

多个从数据库关联到主数据库后，将主数据库上的Binlog日志同步地复制到了多个从数据库上。经过执行日志，让每一个从数据库的数据都和主数据库上的数据保持了一致。这里面的数据更新操做表示的是全部数据库的更新操做，除了不包括SELECT之类的查询读操做，其余的INSERT、DELETE、UPDATE这样的DML写操做，以及CREATE TABLE、DROPT ABLE、ALTER TABLE等DDL操做也均可以同步复制到从数据库上去。

3.一主多从复制的优势

一主多从复制有四大优势，分别是分摊负载、专机专用、便于冷备和高可用。

a.分摊负载

将只读操做分布在多个从数据库上，从而将负载分摊到多台服务器上。

b.专机专用

能够针对不一样类型的查询，使用不一样的从服务器。

c.便于进行冷备

即便数据库进行了一主多从的复制，在一些极端的状况下。也可能会致使整个数据中心的数据服务器都丢失。因此一般说来不少公司会对数据作冷备，可是进行冷备的时候有一个困难点在于，数据库若是正在进行写操做，冷备的数据就可能不完整，数据文件可能处于损坏状态。使用一主多从的复制就就能够实现零停机时间的备份。只须要关闭数据的数据复制进程，文件就处于关闭状态了，而后进行数据文件拷贝，拷贝完成后再从新打开数据复制就能够了。

d.高可用

若是一台服务器宕机了，只要不发请求给这台服务器就不会出问题。当这台服务器恢复的时候，从新发请求到这台服务器。因此，在一主多从的状况下，某一台从服务器宕机不可用，对整个系统的影响是很是小的。

4.MySQL的主主复制

可是一主多从只可以实现从服务器上的这些优势，当主数据库宕机不可用的时候，数据依然是不可以写入的，由于数据不可以写入到从服务器上面去，从服务器是只读的。

为了解决主服务器的可用性问题，咱们可使用MySQL的主主复制方案。所谓的主主复制方案是指两台服务器都看成主服务器，任何一台服务器上收到的写操做都会复制到另外一台服务器上。

如上主主复制原理图，当客户端程序对主服务器A进行数据更新操做的时候，主服务器A会把更新操做写入到Binlog日志中。而后Binlog会将数据日志同步到主服务器B，写入到主服务器的Relay log中，而后执Relay log，得到Relay log中的更新日志，执行SQL操做写入到数据库服务器B的本地数据库中。B服务器上的更新也一样经过Binlog复制到了服务器A的Relay log中，而后经过Relay log将数据更新到服务器A中。

经过这种方式，服务器A或者B任何一台服务器收到了数据的写的操做都会同步更新到另外一台服务器，实现了数据库主主复制。主主复制能够提升系统的写可用，实现写操做的高可用。

5.MySQL的主主失效恢复

使用MySQL服务器实现主主复制时，数据库服务器失效该如何应对？

正常状况下用户会写入到主服务器A中，而后数据从A复制到主服务器B上。当主服务器A失效的时候，写操做会被发送到主服务器B中去，数据从B服务器复制到A服务器。

主主失效的维护过程以下：

最开始的时候，全部的主服务器均可以正常使用，当主服务器A失效的时候，进入故障状态，应用程序检测到主服务器A失效，检测到这个失效可能须要几秒钟或者几分钟的时间，而后应用程序须要进行失效转移，将写操做发送到备份主服务器B上面去，将读操做发送到B服务器对应的从服务器上面去。

一段时间后故障结束，A服务器须要重建失效期间丢失的数据，也就是把本身看成从服务器从B服务器上面去同步数据。同步完成后系统才能恢复正常。这个时候B服务器是用户的主要访问服务器，A服务器看成备份服务器。

5.MySQL复制注意事项

使用MySQL进行主主复制的时候须要注意的事项以下：

a.不要对两个数据库同时进行数据写操做，由于这种状况会致使数据冲突。

b.复制只是增长了数据的读并发处理能力，并无增长写并发的能力和系统存储能力。

c.更新数据表的结构会致使巨大的同步延迟。

须要更新表结构的操做，不要写入到到Binlog中，要关闭更新表结构的Binlog。若是要对表结构进行更新，应该由运维工程师DBA对全部主从数据库分别手工进行数据表结构的更新操做。

2、数据分片

数据复制只能提升数据读并发操做能力，并不能提升数据写操做并发的能力以及数据整个的存储容量，也就是并不能提升数据库总存储记录数。若是咱们数据库的写操做也有大量的并发请求须要知足，或者是咱们的数据表特别大，单一的服务器甚至连一张表都没法存储。解决方案就是数据分片。

1.数据分片介绍

a.主要目标：将一张数据表切分红较小的片，不一样的片存储到不一样的服务器上面去，经过分片的方式使用多台服务器存储一张数据表，避免一台服务器记录存储处理整张数据表带来的存储及访问压力。

b.主要特色：数据库服务器之间互相独立，不共享任何信息，即便有部分服务器故障，也不影响整个系统的可用性。第二个特色是经过分片键定位分片，也就是说一个分片存储到哪一个服务器上面去，到哪一个服服务器上面去查找，是经过分片键进行路由分区算法计算出来的。在SQL语句里面，只要包含分片键，就能够访问特定的服务器，而不须要链接全部的服务器，跟其余的服务器进行通讯。

c.主要原理：将数据以某种方式进行切分，一般就是用刚才提到的分片键的路由算法。经过分片键，根据某种路由算法进行计算，使每台服务器都只存储一部分数据。

2.硬编码实现数据分片

如图例子，经过应用程序硬编码的方式实现数据分片。假设咱们的数据库将数据表根据用户ID进行分片，分片的逻辑是用户ID为奇数的数据存储在服务器2中，用户ID为偶数的数据存储在服务器1中。那么，应用程序在编码的时候，就能够直接经过用户ID进行哈希计算，一般是余数计算。若是余数为奇数就链接到服务器2上，若是余数为偶数，就链接到服务器1上，这样就实现了一张用户表分片在两个服务器上。

这种硬编码主要的缺点在于，数据库的分片逻辑是应用程序自身实现的，应用程序须要耦合数据库分片逻辑，不利于应用程序的维护和扩展。一个简单的解决办法就是将映射关系存储在外面。

3.映射表外部存储

应用程序在链接数据库进行SQL操做的时候，经过查找外部的数据存储查询本身应该链接到哪台服务器上面去，而后根据返回的服务器的编号，链接对应的服务器执行相应的操做。在这个例子中，用户ID=33查找服务器是2，用户ID=94查找服务器也是2，它们根据查找到的用户服务器的编号，链接对应的服务器，将数据写入到对应的服务器分片中。

4.数据分片的挑战及解决方案

数据库分片面临如图的挑战：

如今有一些专门的分布式数据库中间件来解决上述这些问题，比较知名的有Mycat。Mycat是一个专门的分布式数据库中间件，应用程序像链接数据库同样的链接Mycat，而数据分片的操做彻底交给了Mycat去完成。

以下这个例子中，有3个分片数据库服务器，数据库服务器dn一、dn2和dn3，它们的分片规则是根据prov字段进行分片。那么，当咱们执行一个查询操做”select * from orders where prov=‘wuhan’“的时候，Mycat会根据分片规则将这条SQL操做路由到dn1这个服务器节点上。dn1执行数据查询操做返回结果后，Mycat再返回给应用程序。经过使用Mycat这样的分布式数据库中间件，应用程序能够透明的无感知的使用分片数据库。同时，Mycat还必定程度上支持分片数据库的联合join查询以及数据库事务。

5.分片数据库扩容伸缩

一开始，数据量还不是太多，两个数据库服务器就够了。可是随着数据的不断增加，可能须要增长第三个第四个第五个甚至更多的服务器。在增长服务器的过程当中，分片规则须要改变。分片规则改变后，之前写入到原来的数据库中的数据，根据新的分片规则，可能要访问新的服务器，因此还须要进行数据迁移。

不论是更改分片的路由算法规则，仍是进行数据迁移，都是一些比较麻烦和复杂的事情。所以在实践中一般的作法是数据分片使用逻辑数据库，也就是说一开始虽然只须要两个服务器就能够完成数据分片存储，可是依然在逻辑上把它切分红多个逻辑数据库。具体的操做办法，本文不用大篇幅进行阐述了。

3、数据库部署方案

1.单一服务和单一数据库

这是最简单的部署方案。应用服务器可能有多个，可是它们完成的功能是单一的功能。多个完成单一功能的服务器，经过负载均衡对外提供服务。它们只连一台单一数据库服务器，这是应用系统早期用户量比较低的时候的一种架构方法。

2.主从复制实现伸缩

若是对系统的可用性和对数据库的访问性能提出更高要求的时候，就能够经过数据库的主从复制进行初步的伸缩。经过主从复制，实现一主多从。应用服务器的写操做链接主数据库，读操做从从服务器上进行读取。

3.两个Web服务及两个数据库

随着业务更加复杂，为了提供更高的数据库处理能力，能够进行数据的业务分库。数据的业务分库是一种逻辑上的，是基于功能的一种分割，将不一样用途的数据表存储在不一样的物理数据库上面去。

在这个例子中，有产品类目服务和用户服务，两个应用服务器集群，对应的也将数据库也拆分红两个，一个叫作类目数据库，一个叫作用户数据库。每一个数据库依然使用主从复制。经过业务分库的方式，在同一个系统中，提供了更多的数据库存储，同时也就提供了更强大的数据访问能力，同时也使系统变得更加简单，系统的耦合变得更低。

4.综合部署方案

根据不一样数据的访问特色，使用不一样的解决方案进行应对。好比说类目数据库，也许经过主从复制就可以知足全部的访问要求。可是若是用户量特别大，进行主从复制或主主复制，仍是不可以知足数据存储以及写操做的访问压力，这时候就就能够对用户数据库进行数据分片存储了。同时每一个分片数据库也使用主从复制的方式进行部署。

以上为分布式数据库的部署方案，若是你的应用不是非要使用关系数据库的话，你还能够选择NoSQL数据库，NoSQL数据库会提供更强大的数据存储能力和并发读写能力。可是NoSQL数据库由于CAP原理的约束可能会遇到数据不一致的问题。解决数据不一致的问题，能够经过时间戳合并、客户端判断以及投票这样的几种机制解决，实现最终一致性。

——THE END——

以上内容摘取自拉勾《阿里前辈的架构经》 第04讲（分布式数据存储）

主讲人：李智慧，前阿里巴巴技术专家

更多关于数据库分布式部署的方案详细讲解，以及NoSQL中的CAP原理、分布式系统的最终一致性及其实现方案，李智慧老师将在这里讲懂讲透。详情戳这

也可添加拉勾求职导师微信：kaiwubzr3，领取独家技术礼包