对增加数据中心／机房配置项的探讨

[fengpeiyuan]

不好意思，我用中文表达了啊，不同意见互相交流下。
问题描述：redis在集群工作时，一个从节点发现自己的主节点进入下线状态时将进行故障转移。故障转移即是发生故障主节点的所有从节点进行选主（Raft算法领头选举）。您是觉得对于部署在和主节点不同机房的从节点被选中后跨机房通信会对性能有影响,所以增加了datacenter-id这个配置项。
我的理解：我觉得这个问题只是一个使用过程中的具体问题，如果用数据中心／机房做配置项，再来一个需求：一个机房内部不同交换机／子网之间有没有必要再增加配置项（这个例子可能不恰当，毕竟机房内部延迟足够小），我的意思是redis作为一个软件产品需要抽象具体需求来给出解决方案，所以代码层面有数据中心（机房）类似的代码是有些狭义了
延伸：其实我觉得redis cluster对于用户来说最大的问题是运维问题，过于“自动化”，对人工干预不友好，这也是好多用户不敢用的原因。我觉得在所有从节点进行Raft算法选主前应该先判断一下有没有被人工干预指定为主节点的配置项（配置信息所有从节点信息是经过同步一致的），如果有配置信息，则此从节点单独参选主节点，所有从节点都没有则大家一起参选。
用途：1.解决跨机房节点被选主带来性能问题
2.人为干预，可以平移整个集群到另一个机房（实现集群的平移）
3.使得不同机房的从（备）节点更加有实际意义

[TimothyZhang023]

问题描述：redis在集群工作时，一个从节点发现自己的主节点进入下线状态时将进行故障转移。故障转移即是发生故障主节点的所有从节点进行选主（Raft算法领头选举）。您是觉得对于部署在和主节点不同机房的从节点被选中后跨机房通信会对性能有影响是吧。

对于这个问题一个方面是避免跨机房的节点发起选举，另一方面，跨机房部署cluster可能会有潜在不稳定因素(比如机房间网络波动)导致集群发生不正确的跨机房切换。
所以dc-id的最大作用是防止自动的机房切换，做到一种隔离或者说剥夺了发起选举的权利，个人觉得dc-id只是一个不是特别抽象名字。

---

延伸：其实我觉得redis cluster对于用户来说最大的问题是运维问题，过于“自动化”，对人工干预不友好，这也是好多用户不敢用的原因。

我持相反观点，对于上规模的环境来说，自动化可以大大减轻运维压力，很多人害怕自动化，可能是缺少足够的了解，redis cluster中对于人工干预几乎都可以使用命令来实现，你在用途中提到

人为干预转移整个集群到另一个机房（实现集群的平移）

如果只是搬迁集群的话我们只需要 ：

1. 跨机房添加从节点
2. 手动在需要成为新主节点的node上执行failover命令
3. 切换完，删除之前机房节点

这个步骤中其实没有依赖dc_id功能，需要dc_id的主要是机房切换，这个是公司决策需要(因为某种原因，需要立即切走) ，所以跨机房部署本身只是一种容灾。

---

回到前面的问题。

对人工干预不友好

这个我觉得并不存在，前面也提到可以手动failover。
实际上cluster 自动failover流程主要几步

1. slave发现master pfail->fail
2. 发起投票
3. 赢得选举，成为新master

手动failover 其实就是直接开始介入 step 2，并没有特别神秘的地方
确实相比于其他一些（也许更加暴力）的切换方式来说，操作者可能缺少信心
redis自带机制可以让master将尚未复制到slave上的log复制完成之后在开始切换，恰恰保证了数据安全。

---

写在最后
其实多机房只是一个功能，背后其实问题在于失效判定。
redis cluster的失效判定和redis sentinel 其实很近。他的正确性取决于支撑的理论基础和工程实现正确性。很多人看到这个会有种恐惧，从而选择一些 ‘土方子’ 来实现，但实际上很多实现其实是存在缺陷或者说并不可靠。
高度的自动化确实让人觉得无法把控，在多机房部署问题上确实存在，所以多数据中心标签功能算是一种对于现实的一种妥协，用手动代替自动，最终构成 机房内自动切换+机房间手动切换容灾 的功能。

以上仅代表个人观点，欢迎探讨~

手动at一下作者吧 @JingchengLi

[JingchengLi]

这块的实现是按照redis作者antirez的想法实现的，可以参考：
redis/redis#2458
相关的PR为：
redis/redis#3363

另外，datacenter-id中的datacenter只是一个名称而已，按你的例子，在实际配置时，也可以将相同交换机下面的机器配置为相同的datacenter-id。

实际上，这个多机房支持的功能要解决的问题就是redis cluster“过于”自动化的问题，因为机房间的脑裂问题一旦发生，那结果可能是灾难性的。通过这个PR，就可以实现A机房节点提供服务，而B机房节点只作为从节点进行实时同步，并且B机房节点不参与自动failover。只在有必要时(A机房维护/断电)，才通过运维组件将服务切换到B机房。

[fengpeiyuan]

@zts1993 相同观点的略过了哈

1. 人工干预是否友好问题

回到前面的问题。

对人工干预不友好

这个我觉得并不存在，前面也提到可以手动failover。

这个观点不赞同，可以手动failover不代表就“友好”了，此项目增加配置项datacenter-id就是解决人工干预不友好的一个例子么？当然“友好”也没有什么标准，仁者见仁吧，只是表达一下看法而已。
2. redis cluster是否应该给用户进行人工干预的更多选项（配置）问题

我持相反观点，对于上规模的环境来说，自动化可以大大减轻运维压力，很多人害怕自动化，可能是缺少足够的了解，redis cluster中对于人工干预几乎都可以使用命令来实现
redis cluster的失效判定和redis sentinel 其实很近。他的正确性取决于支撑的理论基础和工程实现正确性。很多人看到这个会有种恐惧，从而选择一些 ‘土方子’ 来实现，但实际上很多实现其实是存在缺陷或者说并不可靠。

你的这些意见我都不太赞同，其实用户不是害怕自动化，而是害怕不可靠的自动化，用户也不是不了解，而是由于缺少进行人工干预选项而使得用户不放心而害怕。redis cluster如果不深入分析用户的需求和痛点而一概说用户不足够了解，会在“开始”就被“恐惧”的用户所抛弃。自动化运维好处众多，也需要一步一步过度，拔苗助长会适得其反。用户也有既可以使用“人工干预”也可以使用“自动化”的权利。

个人观点，期待反馈～

[TimothyZhang023]

此项目增加配置项datacenter-id就是解决人工干预不友好的一个例
用户也有既可以使用“人工干预”也可以使用“自动化”的权利。

我觉现在就是可以使用“人工干预”也可以使用“自动化”的，但是我感觉您的意思是： cluster 既要支持自动切换也要可以同时支持完全手动切换？ (或者说手动切换在特殊情况下作为一种降级模式)？

可以展开说下人工干预友好可以举个例子么？
或者说，人工干预=类似手动模式，不知道这个理解有没有偏差？