专注于Java范畴优质技术，欢送关注 来自：编程无界 散布式数据库和散布式存储是散布式系统中难度最大、应战最大，也是最容易出问题的中央。互联网公司只需处置散布式数据存储的问题，才干支撑更多次亿级用户的涌入。 接下来，你将破费十分钟控制以下三方面内容： 1、MySQL复制：包含主从复制和主主复制； 2、数据分片：数据分片的原理、分片的计划、分片数据库的扩容； 3、数据库散布式部署的几种计划。 一、MySQL复制1.1、MySQL的主从复制 MySQL的主从复制，就是将MySQL主数据库中的数据复制到从数据库中去。  主要目的是完成数据库读写分别，写操作访问主数据库，读操作访问从数据库，从而使数据库具有更强大的访问负载才干，支撑更多的用户访问。 它的主要的复制原理是：当应用程序客户端发送一条更新命令到数据库的时分，数据库会把这条更新命令同步记载到Binlog中，然后由另外一个线程从Binlog中读取这条日志，然后经过远程通讯的方式将它复制到从效劳器上面去，从效劳器取得这条更新日志后，将其参与到自己的Relay log中，然后由另外一个SQL执行线程从Relay log中读取这条新的日志，并把它在本地的数据库中重新执行一遍。 这样当客户端应用程序执行一个update命令的时分，这个命令会在主数据库和从数据库上同步执行，从而完成了主数据库向从数据库的复制，让从数据库和主数据库坚持一样的数据。 1.2、MySQL的一主多从复制 MySQL的主从复制是一种数据同步机制，除了能够将一个主数据库中的数据同步复制到一个从数据库上，还能够将一个主数据库上的数据同步复制到多个从数据库上，也就是所谓的MySQL的一主多从复制。  多个从数据库关联到主数据库后，将主数据库上的Binlog日志同步地复制到了多个从数据库上。经过执行日志，让每个从数据库的数据都和主数据库上的数据坚持了分歧。这里面的数据更新操作表示的是一切数据库的更新操作，除了不包含SELECT之类的查询读操作，其他的INSERT、DELETE、UPDATE这样的DML写操作，以及CREATE TABLE、DROPT ABLE、ALTER TABLE等DDL操作也都能够同步复制到从数据库上去。 1.3、一主多从复制的优点 一主多从复制有四大优点，分别是分摊负载、专机专用、便于冷备和高可用。 a.分摊负载 将只读操作散布在多个从数据库上，从而将负载分摊到多台效劳器上。 b.专机专用 能够针对不同类型的查询，运用不同的从效劳器。 c.便于中止冷备 即便数据库中止了一主多从的复制，在一些极端的状况下。也可能会招致整个数据中心的数据效劳器都丧失。所以通常说来很多公司会对数据做冷备，但是中止冷备的时分有一个艰难点在于，数据库假如正在中止写操作，冷备的数据就可能不完好，数据文件可能处于损坏状态。运用一主多从的复制就就能够完成零停机时间的备份。只需求关闭数据的数据复制进程，文件就处于关闭状态了，然后中止数据文件拷贝，拷贝完成后再重新翻开数据复制就能够了。 d.高可用 假如一台效劳器宕机了，只需不发央求给这台效劳器就不会出问题。当这台效劳器恢复的时分，重新发央求到这台效劳器。所以，在一主多从的状况下，某一台从效劳器宕机不可用，对整个系统的影响是十分小的。 1.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任何一台效劳器收到了数据的写的操作都会同步更新到另一台效劳器，完成了数据库主主复制。主主复制能够进步系统的写可用，完成写操作的高可用。 1.5、MySQL的主主失效恢复 运用MySQL效劳器完成主主复制时，数据库效劳器失效该如何应对？  正常状况下用户会写入到主效劳器A中，然后数据从A复制到主效劳器B上。当主效劳器A失效的时分，写操作会被发送到主效劳器B中去，数据从B效劳器复制到A效劳器。 主主失效的维护过程如下：  最开端的时分，一切的主效劳器都能够正常运用，当主效劳器A失效的时分，进入毛病状态，应用程序检测到主效劳器A失效，检测到这个失效可能需求几秒钟或者几分钟的时间，然后应用程序需求中止失效转移，将写操作发送到备份主效劳器B上面去，将读操作发送到B效劳器对应的从效劳器上面去。 一段时间后毛病终了，A效劳器需求重建失效期间丧失的数据，也就是把自己当作从效劳器从B效劳器上面去同步数据。同步完成后系统才干恢复正常。这个时分B效劳器是用户的主要访问效劳器，A效劳器当作备份效劳器。 1.6、MySQL复制留意事项 运用MySQL中止主主复制的时分需求留意的事项如下： a.不要对两个数据库同时中止数据写操作，由于这种状况会招致数据抵触。 b.复制只是增加了数据的读并发处置才干，并没有增加写并发的才干和系统存储才干。 c.更新数据表的结构会招致庞大的同步延迟。 需求更新表结构的操作，不要写入到到Binlog中，要关闭更新表结构的Binlog。假如要对表结构中止更新，应该由运维工程师DBA对一切主从数据库分别手工中止数据表结构的更新操作。 二、数据分片数据复制只能进步数据读并发操作才干，并不能进步数据写操作并发的才干以及数据整个的存储容量，也就是并不能进步数据库总存储记载数。假如我们数据库的写操作也有大量的并发央求需求满足，或者是我们的数据表特别大，单一的效劳器以至连一张表都无法存储。处置计划就是数据分片。 2.1、数据分片引见
2.2、硬编码完成数据分片  如图例子，经过应用程序硬编码的方式完成数据分片。假定我们的数据库将数据表依据用户ID中止分片，分片的逻辑是用户ID为奇数的数据存储在效劳器2中，用户ID为偶数的数据存储在效劳器1中。那么，应用程序在编码的时分，就能够直接经过用户ID中止哈希计算，通常是余数计算。假如余数为奇数就衔接到效劳器2上，假如余数为偶数，就衔接到效劳器1上，这样就完成了一张用户表分片在两个效劳器上。 这种硬编码主要的缺陷在于，数据库的分片逻辑是应用程序自身完成的，应用程序需求耦合数据库分片逻辑，不利于应用程序的维护和扩展。一个简单的处置措施就是将映射关系存储在外面。 2.3、映射表外部存储  应用程序在衔接数据库中止SQL操作的时分，经过查找外部的数据存储查询自己应该衔接到哪台效劳器上面去，然后依据返回的效劳器的编号，衔接对应的效劳器执行相应的操作。在这个例子中，用户ID=33查找效劳器是2，用户ID=94查找效劳器也是2，它们依据查找到的用户效劳器的编号，衔接对应的效劳器，将数据写入到对应的效劳器分片中。 2.4、数据分片的应战及处置计划 数据库分片面临如图的应战：  往常有一些特地的散布式数据库中间件来处置上述这些问题，比较知名的有Mycat。Mycat是一个特地的散布式数据库中间件，应用程序像衔接数据库一样的衔接Mycat，而数据分片的操作完整交给了Mycat去完成。 如下这个例子中，有3个分片数据库效劳器，数据库效劳器dn1、dn2和dn3，它们的分片规则是依据prov字段中止分片。那么，当我们执行一个查询操作”select * from orders where prov=‘wuhan’“的时分，Mycat会依据分片规则将这条SQL操作路由到dn1这个效劳器节点上。dn1执行数据查询操作返回结果后，Mycat再返回给应用程序。经过运用Mycat这样的散布式数据库中间件，应用程序能够透明的无感知的运用分片数据库。同时，Mycat还一定水平上支持分片数据库的分离join查询以及数据库事务。  2.5、分片数据库扩容伸缩 一开端，数据量还不是太多，两个数据库效劳器就够了。但是随着数据的不时增长，可能需求增加第三个第四个第五个以至更多的效劳器。在增加效劳器的过程中，分片规则需求改动。分片规则改动后，以前写入到原来的数据库中的数据，依据新的分片规则，可能要访问新的效劳器，所以还需求中止数据迁移。 不论是更改分片的路由算法规则，还是中止数据迁移，都是一些比较省事和复杂的事情。因而在理论中通常的做法是数据分片运用逻辑数据库，也就是说一开端固然只需求两个效劳器就能够完成数据分片存储，但是依然在逻辑上把它切分红多个逻辑数据库。细致的操作措施，本文不用大篇幅中止论述了。 三、数据库部署计划3.1、单一效劳和单一数据库  这是最简单的部署计划。应用效劳器可能有多个，但是它们完成的功用是单一的功用。多个完成单一功用的效劳器，经过负载均衡对外提供效劳。它们只连一台单一数据库效劳器，这是应用系统早期用户量比较低的时分的一种架构措施。 3.2、主从复制完成伸缩  假如对系统的可用性和对数据库的访问性能提出更高请求的时分，就能够经过数据库的主从复制中止初步的伸缩。经过主从复制，完成一主多从。应用效劳器的写操作衔接主数据库，读操作从从效劳器上中止读取。 3.3、两个Web效劳及两个数据库  随着业务愈加复杂，为了提供更高的数据库处置才干，能够中止数据的业务分库。数据的业务分库是一种逻辑上的，是基于功用的一种分割，将不同用处的数据表存储在不同的物理数据库上面去。 在这个例子中，有产品类目效劳和用户效劳，两个应用效劳器集群，对应的也将数据库也拆分红两个，一个叫做类目数据库，一个叫做用户数据库。每个数据库依然运用主从复制。经过业务分库的方式，在同一个系统中，提供了更多的数据库存储，同时也就提供了更强大的数据访问才干，同时也使系统变得愈加简单，系统的耦合变得更低。 3.4、综合部署计划  依据不同数据的访问特性，运用不同的处置计划中止应对。好比说类目数据库，或许经过主从复制就能够满足一切的访问请求。但是假如用户量特别大，中止主从复制或主主复制，还是不能够满足数据存储以及写操作的访问压力，这时分就就能够对用户数据库中止数据分片存储了。同时每个分片数据库也运用主从复制的方式中止部署。 以上为散布式数据库的部署计划，假如你的应用不是非要运用关系数据库的话，你还能够选择NoSQL数据库，NoSQL数据库会提供更强大的数据存储才干和并发读写才干。但是NoSQL数据库由于CAP原理的约束可能会遇到数据不分歧的问题。处置数据不分歧的问题，能够经过时间戳兼并、客户端判别以及投票这样的几种机制处置，完成最终分歧性。 原文：https://segmentfault.com/a/1190000019460946 |
万奢网手机版
官网微博：万奢网服务平台
