doc: 阅读redis sentinel文档

中间件/redis/redis sentinel.md

@@ -0,0 +1,83 @@
+- [redis sentinel](#redis-sentinel)
+  - [sentinel as a distributed system](#sentinel-as-a-distributed-system)
+    - [sentinel部署要点](#sentinel部署要点)
+    - [sentinel配置](#sentinel配置)
+    - [sentinel monitor](#sentinel-monitor)
+    - [其他sentinel选项](#其他sentinel选项)
+      - [down-after-milliseconds](#down-after-milliseconds)
+      - [parallel-syncs](#parallel-syncs)
+
+
+# redis sentinel
+## sentinel as a distributed system
+redis sentinel是一个分布式系统，其设计旨在多个sentinel进程协同工作。
+
+redis sentinel的优势如下：
+- 当多个sentinel节点都一致认为master不再可访问时，将会触发故障检测机制。该机制能够有效的降低false positive几率
+- 即使并非所有sentinel进程都正常工作，sentinel机制仍然能够正常工作，确保整个sentinel机制拥有容错性
+  
+sentinels、redis实例、客户端共同构成了包含特定属性的更大分布式系统。
+
+sentinels默认会监听26379端口， sentinels实例之间会通过该端口进行通信。如果该端口未开放，那么sentinels之间将无法通信，也无法协商一致，failover将不会被执行。
+
+### sentinel部署要点
+- 对于一个具备鲁棒性的形同部署而言，至少需要三个sentinels进程实例
+- 三个sentinel实例应当被部署在独立故障的计算机/虚拟机中
+- sentinel + redis 分布式系统并不保证在发生故障时，对系统的`acked writes`不被丢失。
+  - 因为redis的replication是异步的，故而在发生故障时可能会丢失部分写入
+- clients需要sentinel支持，大部分client library中包含sentinel支持
+
+### sentinel配置
+redis包含一个名为`sentinel.conf`的文件，用于配置sentinel，典型的最小化配置如下：
+```redis
+sentinel monitor mymaster 127.0.0.1 6379 2
+sentinel down-after-milliseconds mymaster 60000
+sentinel failover-timeout mymaster 180000
+sentinel parallel-syncs mymaster 1
+
+sentinel monitor resque 192.168.1.3 6380 4
+sentinel down-after-milliseconds resque 10000
+sentinel failover-timeout resque 180000
+sentinel parallel-syncs resque 5
+```
+
+只需要指定监控的主节点，并为每个主节点指定不同的名称。无需手动指定replicas，系统会自动发现replicas。sentinel将会自动使用replicas的额外信息来更新配置。
+
+并且，发生故障转移replica被提升为主节点时/新sentinel被发现时，该配置文件也会被重写。
+
+在上述配置文件示例中，监控了两个redis实例集合，每个redis实例集合都由一个master和一系列replicas组成。上述，一个集合被称为`mymaster`，另一个集合被称为`resque`。
+
+### sentinel monitor
+```
+sentinel monitor <master-name> <ip> <port> <quorum>
+```
+上述是`sentinel monitor`的语法，其用于告知redis监控名为`mymaster`的master实例，并且其地址为`127.0.0.1`，端口号为`6379`，quorum为2。
+
+其中，quorum的含义如下：
+- quorm为需要达成`master不可访问`这一共识的sentinels数量，其将将master标记为失败，并且在条件允许的情况下启动failover
+- quorum仅用于检测失败。为了实际的执行故障转移，sentinels中的一个需要被选举为leader，这需要获取多数sentinel进程的投票后才能完成
+
+例如，假设有5个sentinel进程，并且给定master的quorum为2，那么：
+- 如果两个sentinels达成共识master不可访问，那么其中一个sentinel将会尝试开启故障转移
+- 只有当至少存在3个sentinels可访问时，故障转移才会被授权，并实际启动故障转移
+
+在实际应用中，少数派分区将永远不会在故障时触发故障转移。
+
+### 其他sentinel选项
+其他sentinel选项的格式集合都如下：
+```
+sentinel <option_name> <master_name> <option_value>
+```
+
+#### down-after-milliseconds
+`down-after-milliseconds`选项代表sentinel认为实例宕机的时间，在该段时间内实例应当是不可访问的
+
+#### parallel-syncs
+`parallel-syncs`代表故障转移时，replicas同时被重新配置的数量。replicas在故障转移时，会被重新配置并使用新的master节点。
+
+- 当`parallel-syncs`参数指定的值被降低时，故障转移过程耗费的时间将会增加
+- replication过程通常是非阻塞的，但是其间有一个时间段会中止并从master批量加载数据。此时，可能并不希望所有的replicas都不可用并从新master同步数据
+
+配置参数可以在运行时被修改，
+- 针对master的配置参数可以通过`SENTINEL SET`命令修改
+- 全局配置参数可以通过`SENTINEL CONFIG SET`命令来进行修改