vlambda博客
学习文章列表

分布式系统咋做同步?虐死人!

分布式系统,通过数据冗余,来保证数据的安全。要写一个分布式系统,一道绕不过去的坎,那就是数据同步。

同步,这两个字,折磨死了很多人。

是同步,还是异步?是push,还是pull?谁是master,谁是slave?下线会怎样,上线了又会怎样?中心化,or对等节点?

这些问题,无一不拷打者分布式系统的设计者。

下面,我们将看一下主流的几个存储服务,是如何解决数据同步问题的。

MySQL如何做主从同步?

mysql的主服务器叫做master,从服务器叫做slave。

主服务器将变更记录在binlog中,slave将通过独立的线程拷贝这些记录,然后重放。

binlog的格式分为statement、row、mixed三种。

  • statement 将变更的sql语句写入到binlog中,在准确性方面会有一定影响
  • row 将每一条记录的变化,写入到binlog中
  • mixed 上面两种的结合。MySQL会判断什么时候有用statement,什么时候用row

由于是异步线程去拷贝,slave很容易会出现延迟。当master不幸宕机,将会造成延迟的数据丢失。

分布式系统咋做同步?虐死人!


为了解决异步复制的问题,5.5版本之后,MySQL引入了半同步复制(semi  sync)的概念。半同步处于异步和全量同步之间,master执行完事务之后,并不直接返回,而是要等待至少一个slave写入成功才返回。由于需要与至少一个slave进行交互,性能相比较异步复制肯定是有不少折损的。

全复制模式当然是要等待所有的slave节点复制完成,这种安全性最高,但是效率也最低。从概念上来讲,只有一个slave的半复制就是全复制。

5.7之后,mysql实现了组复制(group replication)协议。它支持单主模式和多主模式,但在同一个group内,不允许同时存在。听起还好像很神奇,其实它还是通过paxos协议去实现的。

Kafka如何做的副本同步?

kafka由于是一个消息队列,所以不需要考虑随机删除和随机更新的问题,它只关注写入问题即可。从结构上来说,kafka的同步单元是非常分散的:kafka有多个topic,每个topic又分为多个partition,副本就是基于partiton去做的。

主分区叫做leader,1-n个副本叫做follower。生产者在发送消息的时候,需要先找到该分区的leader,然后将数据发送给它。follower只是作为一个备份存在,以便在主分区发生问题时能够顶上去。

分布式系统咋做同步?虐死人!

kafka的主从同步,叫做ISR(In Sync Replica)机制。

那什么时候消息算是发送成功呢?这还要看ack的发送级别。

  • 0 表示异步发送,消息发送完毕就算是成功了
  • 1 leader主副本写入完成,就算是发送成功了
  • -1 leader发送完成,并且ISR中的副本都需要回复ack

0和1的情况下,kafka都有丢失消息的可能。在-1的情况下,也需要保证至少有一个follower commit成功才能保证消息安全。如果follower都不能追赶上leader,则会被移除出 ISR列表。没错,是直接移除。当ISR为空,则kafka的分区和单机是没有区别的,所以kafka提供了min.insync.replicas参数规定了最小ISR。

  • 当ISR不满足的时候怎么办?kafka当然是不会丢失消息了,因为此时生产者的提交是失败的,消息根本进不了系统里来
  • 当所有副本都不可用怎么办?此时,该partition将永不可用

副本之间的数据复制,是通过follower pull的方式,也就是拉取的方式去获取的。

Redis的主从复制

redis是内存kv数据库,速度上远超其他数据库,理论上主从同步更容易。但在高流量和高QPS下,主从复制依然会发生问题。

redis的slave连接上之后,首先会进行一次全量同步。它会发送psync命令到master,然后master执行bgsave生成一个rdb文件。全量同步就是复制这个rdb快照文件到slave。

那在全量复制中间出现的数据怎么办呢?肯定是要缓存起来的。master会开启一个buffer,然后记录全量复制过程中产生的新数据,在全量同步完成之后再补齐增量数据。

slave断线之后也不需要每次都执行全量同步,为了配合增量,还引入了复制偏移量(offset)、复制积压缓冲区(replication backlog buffer)和运行 ID (run_id)三个概念。可以看出它都是为了标识slave,以及它的复制位置和缓冲区用的。


之后的同步,就可以一直使用psync去复制。依然是异步复制。

可以看出redis的主从复制一致性大量依赖内存,级别是非常弱的。但是它快。快能解决很多问题,所以应用场景是不同的。

ElasticSearch主从复制

es是基于lucene的搜索引擎,数据节点会包含多个索引(index)。每个索引包含多个分片(shard),每个分片又包含多个replica(副本)。

从上面的描述来看,这些概念是与kafka高度雷同的,es的复制单元是分片。

es的数据依然是先写master,它同样维护了一个同步中的slave列表(InSyncAllocationIds),处于yellow和red状态的副本当然是不在这个列表中的。

master需要等待所有这些正常的副本写入完成后,才返回给客户端,所以一致性级别是比较高的,因为它的slave节点是要参与读操作的,它是一个近实时系统。

由于它是一个数据库,所以依然会有删除和更新操作。Translog相当于wal日志,保证了断电的数据安全,这和其他rdbms的套路是一致的。

Cassandra集群模式

cassandra是一个非常有名的CAP理论实践数据库,更多的像一个AP数据库,目前在db-engines.com依然有较高的排名。

数据存储是表的概念,一个表可以存储在多台机器上。它的分区,是通过partition key来设计的,数据分布非常依赖于hash函数。如果某个节点出现问题怎么办?那就需要一致性hash的支持。

cassandra非常有意思,它的复制(replicas)并不像其他的主备数据一样,它更像是多份master数据,这些数据都是同时向外提供服务的。当掉一个检点,并不需要主备切换。


为什么可以做到这种程度呢?因为cassandra追求的是最终一致性。分布式系统由于副本的存在,不可避免的要异步或者同步复制。那到底复制到什么程度才算是合适的呢?QuorumR+W就是一个权衡策略。

quorum = (sum_of_replication_factors / 2) + 1

什么意思呢?考虑到你有5个抽屉,然后随机放入W个球,求需要多少次R,才能拿出一个球。假如你向里面放了1个球,你需要打开5次,才能每次都有正确的判断,此时R=5、W=1;当你放了2个球,则你只需要打开4次就可以了;假如你放入了5个球,那就只需要读一次。

当R+W>N的时候,属于强一致性;当R+W<=N的时候,属于最终一致性。

有意思的是,cassandra中的集群信息,即meta信息,使用gossip(push-pull-gossip)进行传递。

MongoDB主从复制

mongodb有三种数据冗余方式。一种是master-slave(不推荐使用),一种是replica set,一种是 sharding模式。

mongodb的副本集主从,就是标准的故障自动转移实现方式,不需要人工介入。master节点当掉之后,会通过选举从副本集中找出新的master节点,然后引导其他节点连接到这个master。

mongodb的选举算法,采用的是bully。

主节点的变更,会存放在特定的系统表中。slave会定时拉取这些变更,并应用。从这种描述中也可以看出,mongodb在同步延迟或者单节点出问题的时候,会有丢失数据的可能。

总结

分布式是为了解决单机的容量问题,但它引入了一个新的问题,那就是数据同步。

数据同步要关注一致性,故障恢复以及时效性。

主要有两种数据需要同步。

  • 元数据信息
  • 真正的数据

对于元数据信息,目前比较主流的做法,可以参考使用raft协议进行数据分发。到了真正的数据同步方面,raft协议的效率还是有些低的,所以会普遍采用异步复制的方式。

在这种情况下,异步复制列表,就成了关键的元数据信息,集群需要维护这些节点的状态。最坏的情况下,异步复制节点全部不可用,master会自己运行在非常不可信的环境下。

为了增加数据分配的灵活性,这些复制单元多会针对于sharding分片进行操作,由此带来的,就是meta信息的爆炸。

分布式系统这么多,但并没有一个能够统一的模式。有意思的是,即使是最低效的分布式系统,也有大批的追随者。不信?看看BTC的走势就知道了。

推荐阅读:



3. 
4. 
5. 
6.