标签:异步 font 网络 参考 正在运行的服务 har 流程 代码 deb
Redis支持简单且易用的主从复制(master-slave replication)功能, 该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。以下是关于 Redis 复制功能的几个重要方面:
当配置Redis复制功能时,强烈建议打开主服务器的持久化功能。 否则的话,由于延迟等问题,部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性,参考一下以下会导致主从服务器数据全部丢失的例子:
在关闭主服务器上的持久化,并同时开启自动拉起进程的情况下,即便使用Sentinel来实现Redis的高可用性,也是非常危险的。 因为主服务器可能拉起得非常快,以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启,然后还是会执行上面的数据丢失的流程。无论何时,数据安全都是极其重要的,所以应该禁止主服务器关闭持久化的同时自动拉起。
无论是初次连接还是重新连接, 当建立一个从服务器时, 从服务器都将向主服务器发送一个SYNC命令。接到SYNC命令的主服务器将开始执行BGSAVE , 并在保存操作执行期间, 将所有新执行的写入命令都保存到一个缓冲区里面。当BGSAVE执行完毕后, 主服务器将执行保存操作所得的 .rdb文件发送给从服务器, 从服务器接收这个.rdb 文件, 并将文件中的数据载入到内存中。之后主服务器会以Redis命令协议的格式, 将写命令缓冲区中积累的所有内容都发送给从服务器。
你可以通过telnet命令来亲自验证这个同步过程: 首先连上一个正在处理命令请求的Redis服务器, 然后向它发送SYNC命令, 过一阵子, 你将看到 telnet 会话(session接收到服务器发来的大段数据(.rdb 文件), 之后还会看到, 所有在服务器执行过的写命令, 都会重新发送到 telnet会话来。
即使有多个从服务器同时向主服务器发送SYNC , 主服务器也只需执行一次BGSAVE命令, 就可以处理所有这些从服务器的同步请求。从服务器可以在主从服务器之间的连接断开时进行自动重连, 在Redis2.8版本之前, 断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作, 但是从Redis2.8版本开始, 从服务器可以根据主服务器的情况来选择执行完整重同步还是部分重同步(partial resynchronization)。
从Redis2.8开始, 在网络连接短暂性失效之后, 主从服务器可以尝试继续执行原有的复制进程(process), 而不一定要执行完整重同步操作。这个特性需要主服务器为被发送的复制流创建一个内存缓冲区(in-memory backlog), 并且主服务器和所有从服务器之间都记录一个复制偏移量(replication offset)和一个主服务器ID(master run id), 当出现网络连接断开时, 从服务器会重新连接, 并且向主服务器请求继续执行原来的复制进程:
Redis2.8的这个部分重同步特性会用到一个新增的PSYNC内部命令,而Redis 2.8以前的旧版本只有SYNC命令, 不过,只要从服务器是Redis 2.8或以上的版本, 它就会根据主服务器的版本来决定到底是使用PSYNC还是SYNC :
配置一个从服务器非常简单, 只要在配置文件中增加以下的这一行就可以了:
slaveof 192.168.1.1 6379
当然, 你需要将代码中的 192.168.1.1 和 6379 替换成你的主服务器的 IP 和端口号。另外一种方法是调用 SLAVEOF 命令, 输入主服务器的 IP 和端口, 然后同步就会开始:
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
从Redis2.6开始, 从服务器支持只读模式, 并且该模式为从服务器的默认模式。只读模式由redis.conf文件中的 slave-read-only 选项控制, 也可以通过CONFIG SET命令来开启或关闭这个模式。只读从服务器会拒绝执行任何写命令, 所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。即使从服务器是只读的, DEBUG和CONFIG等管理式命令仍然是可以使用的, 所以我们还是不应该将服务器暴露给互联网或者任何不可信网络。 不过, 使用 redis.conf 中的命令改名选项, 我们可以通过禁止执行某些命令来提升只读从服务器的安全性。
你可能会感到好奇, 既然从服务器上的写数据会被重同步数据覆盖, 也可能在从服务器重启时丢失, 那么为什么要让一个从服务器变得可写呢?原因是, 一些不重要的临时数据, 仍然是可以保存在从服务器上面的。 比如说, 客户端可以在从服务器上保存主服务器的可达性(reachability)信息, 从而实现故障转移(failover)策略。
如果主服务器通过 requirepass 选项设置了密码, 那么为了让从服务器的同步操作可以顺利进行, 我们也必须为从服务器进行相应的身份验证设置。对于一个正在运行的服务器, 可以使用客户端输入以下命令:
config set masterauth <password>
要永久地设置这个密码, 那么可以将它加入到配置文件中:
masterauth <password>
另外还有几个选项, 它们和主服务器执行部分重同步时所使用的复制流缓冲区有关, 详细的信息可以参考 Redis 源码中附带的 redis.conf 示例文件。
从 Redis 2.8 开始, 为了保证数据的安全性, 可以通过配置, 让主服务器只在有至少N个当前已连接从服务器的情况下, 才执行写命令。不过, 因为Redis使用异步复制, 所以主服务器发送的写数据并不一定会被从服务器接收到, 因此, 数据丢失的可能性仍然是存在的。以下是这个特性的运作原理:
如果至少有min-slaves-to-write个从服务器, 并且这些服务器的延迟值都少于min-slaves-max-lag秒, 那么主服务器就会执行客户端请求的写操作。你可以将这个特性看作CAP理论中的C的条件放宽版本: 尽管不能保证写操作的持久性, 但起码丢失数据的窗口会被严格限制在指定的秒数中。另一方面, 如果条件达不到min-slaves-to-write和min-slaves-max-lag所指定的条件, 那么写操作就不会被执行, 主服务器会向请求执行写操作的客户端返回一个错误。以下是这个特性的两个选项和它们所需的参数:
min-slaves-to-write <number of slaves> min-slaves-max-lag <number of seconds>
标签:异步 font 网络 参考 正在运行的服务 har 流程 代码 deb
原文地址:http://www.cnblogs.com/wxgblogs/p/6789314.html