一、概述
为了避免单点故障,通常的做法是将数据库复制到多个副本以部署到不同的服务器上,这样即使一台服务器出现故障,其他服务器依然可以继续提供服务。为此redis提供了复制功能,以实现当一台数据库中的数据更新后,自动将更新的数据同步到其他数据库上。
二、配置
在复制的概念中,数据库分为两类,一类是主数据库(master),一类是从数据库(slave)。主数据库可以进行读写操作,当读写操作导致数据变化时自动将数据同步给从数据库。而从数据库一般是只读的,并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库,而一个数据库只能拥有一个主数据库。
在redis中使用复制功能非常容易,只需要在从数据库的配置文件中加入“slaveof 主数据库地址 主数据库端口号“即可,主数据库无需进行任何配置。
默认情况下,从数据库是只读的,如果直接修改从数据库的数据会出现错误。可以通过设置从数据库的配置文件中的slave-read-only 为no 以使从数据可写,但是因为对从数据库的任何更改不会同步给任何其他数据库,并且一旦主数据中更新了对应的数据就会覆盖从数据库中的改动,所以通常场景下不应该设置从数据库可写,以免导致易被忽略的潜在应用逻辑错误。可以使用slaveof no one 命令来使当前数据库停止接收其他数据库的同步并转换成主数据库。
三、原理
当一个从数据库启动后,会向主数据库发出sync命令。同时主数据库接收到sync命令后会开始在后台保存快照(即RBD持久化过程),并将保存快照期间接收到的命令缓存起来。当快照完成后,redis会快照文件和所有缓存的命令发送给从数据库。从数据库接收到后,会载入快照文件并执行收到的缓存命令。以上过程称为复制初始化。复制初始化结束后,主数据库每当收到命令时就会将命令同步给数据库,从而保证主从数据库数据一致。
当主从数据库之间的连接断开重连后,redis2.6以及之前的版本会重新进行复制初始化(即主数据库重新保存快照并传送给从数据库),即使从数据库可能仅有几条命令没有收到,主数据库也必须将数据库里所有数据重新传给从数据库。这使得主从数据库断线重连后的数据恢复过程效率低下,在网络环境不好的时候这一问题尤其明显。redis2.8版本的一个重要改进就是断线重连能够支持有条件的增量数据传输,当从数据库重新连接上主数据库后,主数据库只需将断线期间执行的命令传送给从数据库,从而大大提高redis复制的实用性。
乐观复制:redis采用了乐观复制(optimistic replication)的复制策略,容忍一定时间内主从数据库的内容是不同的,但两者的数据最终会同步。具体来说,redis在主从数据库之间复制数据的过程本身是异步的,这意味着,主数据库执行完客户端请求的命令后会立即将命令在主数据库的执行结果返回给客户端,并异步地将命令同步给从数据库,而不会等待从数据库接收到该命令后再返回给客户端。这一特性保证了启用复制后主数据库的性能不受影响,但另一方面也会产生一个主从数据库数据不一致的时间窗口,当主数据库执行了一条写命令后,主数据库的数据已经发生了变动,然而在主数据库将命令传送给从数据库之前,如果两个数据库之间的网络断开了,此时二者之间的数据就会不一致。
四、读写分离与一致性
通过复制可以实现读写分离,提高服务器的负载能力。在常见的场景中(如电子商务网站),读的频率大于写,当单机的redis无法应对大量的读请求时可以通过复制功能建立多个从数据库节点,主数据库只进行写操作,而从数据库负责读操作。这种一主多从的结构很适合读多写少的场景,而单个主数据库不能满足要求时,就需要进行集群了。
网友评论