在部署 Redis Cluster 时，支持手动指定集群拓扑

[slowtech]

痛点：

1. 在使用云主机部署 Redis 时，通常一个实例会部署一个Redis节点。假如我有 6 台云主机，想部署一个三主三从的 Redis Cluster，目前的实现方式是没办法做到的。
2. 在使用云主机部署 Redis 时，希望同一个分片的主从节点会分布在两个不同的可用区，目前自动生成没办法识别这些信息。 基于上述痛点，希望支持手动指定集群拓扑这种方式。

实现的方式：

1. 将部署页面“部署信息预览”设置为可编辑。
2. 将“部署信息预览”中指定的集群拓扑信息通过 appDeployInfo 传递给后端，同时 redisMachines 会基于 appDeployInfo 生成，不再是通过选定的Redis机器。
3. InstancePortServiceImpl.java 中会基于 appDeployInfo 指定的信息来生成实际的集群拓扑，不再是基于 redisMachines 和 masterPerMachine。
4. 兼容之前的部署方式，因为通过点击 “生成部署预览” 生成集群拓扑对应的接口（generateInstanceInfo）内容没有改变。

[githubname1024]

你好，目前的代码逻辑是考虑充分利用服务器资源，一般会多节点部署。 且如果考虑跨机房的问题，一般建议部署两个集群，否则可能会存在一定的网络延迟，甚至某种恶劣情况集群节点本身通讯出问题，故障时不能正常的主从切换等。 当然，上述两点并不普适所有场景，具体看使用方自己的环境及使用场景。 目前这种多节点部署逻辑需要保留，我看pr中对其进行了删除，这个目前不满足所有场景，请予以兼容。如不便兼容，后期我们评估后再进行添加。

[slowtech]

感谢回复。

1. 关于跨机房网络延迟的问题，其实我们只是模拟Redis PAAS 服务的部署方式，他们一般是跨多个可用区（AZ）部署的。
2. 修改后的代码其实完全兼容之前的多节点部署逻辑，因为生成部署预览这个接口（generateInstanceInfo）的内容没有发生变化，这个接口生成的集群拓扑跟多节点方案部署时生成的集群拓扑逻辑是一样的，所以只要是通过点击 “生成部署预览” 生成的集群拓扑实际上就是之前的多节点部署方案生成的拓扑。 关于这一点，您抽空可以测试一下。 public List<DeployInfo> generateInstanceInfo(List<String> machinelist, int type, int appType, int instanceNum, int maxMemory, int hasSalve, List<DeployInfo> deployInfoList) { if (!CollectionUtils.isEmpty(machinelist)) { for (int index = 0; index < instanceNum; index++) { DeployInfo deployInfo = null; if (DeployInfo.isRedisNode(type)) { deployInfo = hasSalve == 1 ? DeployInfo.getRedisInfo(appType, machinelist.get(index % machinelist.size()), maxMemory, machinelist.get((index + 1) % machinelist.size())) : DeployInfo.getRedisInfo(appType, machinelist.get(index % machinelist.size()), maxMemory, null); } else { deployInfo = hasSalve == 1 ? DeployInfo.getPikaInfo(appType, machinelist.get(index % machinelist.size()), maxMemory, machinelist.get((index + 1) % machinelist.size())) : DeployInfo.getPikaInfo(appType, machinelist.get(index % machinelist.size()), maxMemory, null); } if (deployInfo != null) { deployInfoList.add(deployInfo); } } } return deployInfoList; }

[githubname1024]

好的，我确认一下端口生成问题能不能兼容。

[githubname1024]

@slowtech 感谢提交，已经合并到main分支，后边将考虑在此基础上提供更灵活配置。