fix

.gitignore

@@ -0,0 +1 @@
+*.swp

2-sentinel主逻辑函数.md

@@ -72,6 +72,7 @@ sentinelHandleRedisInstance里的每个函数都很有意思，后续章节会
     - sentinelSendPeriodicCommands
 
 ### **sentinelReconnectInstance**
+---------------------------------
 
 首先介绍一下由sentinel所产生的tcp连接，以及tcp连接重连的机制。
 
@@ -267,6 +268,7 @@ ri->flags & (SRI_MASTER|SRI_SLAVE)来说，是指cc或者pc中任意一个处于
 对于ri->flags & SRI_SENTINEL来讲,是指cc处于未响应的状态。
 
 ### **sentinelSendPeriodicCommands**
+------------------------------------
 
 相关常量定义如下：
 

3-sentinel failover过程的详细介绍.md

@@ -1119,13 +1119,16 @@ sentinelVoteLeader的细节后续会详细解释。现在可以稍微注意一
     首先是因为这个mismatch并不会被广播出去，再加上该redis instance是slave角色，所以这个角色更改在外部几乎是无法感知的，
     唯一可能的影响就是此时恰好有client连接这个instance并写入了data，这个data在稍后肯定会被丢掉。
 
-    后续sentinel可能会有两种处理，
+    上述config还未被upgrade的情况以及config upgrade发生了但是未广播出去的的情况，这两种情况下，如果slave都已经被提升为master了，
+    则后续sentinel可能会有两种处理，
 
     - 如果满足+convert-to-slave的条件，不管此处是否是由master down掉之后下次failover之前人工将master重启创造的条件,
-    还是此前的master down本来就是误判, 则此处promoted_slave instance会被fix再次降回到slave role的状态。
+    还是此前的master down本来就是误判, (即此时极有可能的是同一个bucket中的两个redis instance同时online，
+    同时也都报告自己是master role的情况), 则此处promoted_slave instance会被fix再次降回到slave role的状态。
 
     - 如果master sentinelRedisInstance确实是down掉的状态，并且一直持续直到后续的又一次在old master上发起的failover的发生。
-    则新的failover会承认promoted_slave instance的master地位,并广播出去。
+    则新的failover会再次提升promoted_slave承认promoted_slave instance的master地位,并广播出去,
+    或者选举另外一个slave，强制纠正此次的promoted_slave。
 
     所以从此看来，更需要监控+convert-to-slave这个message并尽量避免。
     这个问题最终会被自动修复。

4-sentinel failover重点细节.md

@@ -1321,10 +1321,10 @@ sentinel与redis instance之间都会有的交互方式，但是具体交互方
 
     - 此处master config_epoch upgrade之后，新的master config_epoch以及promoted slave的ip和port信息
     以及当前sentinel.current_epoch就会不断通过send hello msg从当前sentinel广播出去，
-    虽然当前sentinel都还未真正生效此变更，因为还不到当前sentinel变更的时候，
+    即使当前sentinel都还未真正生效此变更，因为还不到当前sentinel变更的时候，
 
     - 可以解释为，此举之后当前sentinel的failover行为是不可逆的，一定要成功，即使当前sentinel真的crash了，
-    那么这个upgrade config也由于广播出去了，会被其他sentinel最终fix生效。(之前提到过一个非常小可能性的此处的特例。)
+    那么这个upgrade config也由于广播出去了，会被其他sentinel最终fix生效。
     但是当前sentinel还需要在目前的视角上做一些事情，所以还不到变更的时机。
 
 - other sentinel收到hello msg的处理逻辑sentinelProcessHelloMessage

附录.md

@@ -0,0 +1,53 @@
+## 附录
+------
+
+此文件专门查缺补漏。
+
+### **报告的角色与当前sentinel的看法不匹配**
+--------------------------------------------
+
+此处主要是针对的master和slave role这两种角色，当前sentinel已有的记录在
+master或slave role的sentinelRedisInstance中的flags字段暴露的role信息与
+从对应的redis instance的info反馈的role信息吻合以及不吻合的情况的分类
+列举如下，可能每个大的分类下的具体分类里还会有不完整的情况，但是大的分类
+就基本只有四种。
+
+- **当前sentinelRedisInstance的role是master，相应的redis instance info报告的role也是master**
+
+    这是当前sentinel没有任何异议的情况
+
+- **当前sentinelRedisInstance的role是master，相应的redis instance info报告的role却是slave**
+
+    如果role是master，但是report的却是slave，并且mstime() - ri->role_reported_time >
+    (ri->down_after_period+SENTINEL_INFO_PERIOD*2),则会标记当前sentinelRedisInstance为+sdown,
+    如果经历了大多数的同意，则可能会走入failover的流程, 移交出自己的master地位。之前提过了。
+
+- **当前sentinelRedisInstance的role是slave，相应的redis instance info报告的role却是master**
+
+    - 如果是在failover in progress的情况以及当前sentinelRedisInstance就是failover的promoted_slave,
+    则此处正符合failover wait promotion的逻辑，failover进入下一个阶段, 此时当前sentinel有义务尽快将
+    此变更通知other sentinel,以避免被other sentinel按照下一种情况纠正处理了，这也就是下一种情况纠正
+    处理前的等待时间是SENTINEL_PUBLISH_PERIOD*4这样一个与publish period挂钩的时间的原因。
+
+    - 如果此处一个slave被提升为master，但又并不是我们期待的变更，则此处等待一定时间之后，会采取
+    convert-to-slave纠正这个不吻合的情况, 注意此处不会有任何other sentinel的参与也会直接执行，
+    因为此时当前sentinel持有的master config会被认为是一个稳定的config，会被直接生效, 即假设大家的配置都与
+    这个配置一致。
+
+- **当前sentinelRedisInstance的role是slave，相应的redis instance info报告的role也是slave**
+
+    如果role是slave，报告的role也是slave, 这种情况下还是可能有异议。
+
+    如果当前slave sentinelRedisInstance的master处于look sane的状态，但是slave instance的info报告的master host以及port
+    与记录的master并不匹配，则此时纠正当前slave instance slave of我们记录中的master instance。
+
+此处只是在一处汇总了上述所有情况，关于每种情况的细节，之前都已经提过了
+
+### **SRI_MASTER SRI_SLAVE ri->flags会在这两个状态之间切换么**
+--------------------------------------------------------------
+
+简单的回答，不会。ri->flags关于这两个状态的改变只有如下情况。
+
+- 在创建三种role的sentinelRedisInstance时，会给flags赋值成不同的状态，即三种不同的role。
+
+- 会在SentinelResetMaster时强制保证reset masterd的对象是SRI_MASTER状态, 其实不出意外的话，应该是没必要的.