到现在有关Redis Sentinel的配置和部署方法相信读者已经基本掌握了，
但在实际生产环境中都有哪些部署的技巧？本节将总结一下。
1）Sentinel节点不应该部署在一台物理“机器”上。
这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较 流行的容器，它们虽然有不同的IP地址，但实际上它们都是同一台物理机， 同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到 影响，为了实现Sentinel节点集合真正的高可用，请勿将Sentinel节点部署在同一台物理机器上。
2）部署至少三个且奇数个的Sentinel节点。
3个以上是通过增加Sentinel节点的个数提高对于故障判定的准确性，因 为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。有关Sentinel节点如何判断节点失败，如何选举出一个 Sentinel节点进行故障转移将在实现原理小节9.5节进行介绍。
4）只有一套Sentinel，还是每个主节点配置一套Sentinel？
Sentinel节点集合可以只监控一个主节点，也可以监控多个主节点，也 就意味着部署拓扑可能是如下两种情况。
那么在实际生产环境中更偏向于哪一种部署方式呢，下面分别分析两种 方案的优缺点。
方案一：一套Sentinel，很明显这种方案在一定程度上降低了维护成 本，因为只需要维护固定个数的Sentinel节点，集中对多个Redis数据节点进 行管理就可以了。但是这同时也是它的缺点，如果这套Sentinel节点集合出 现异常，可能会对多个Redis数据节点造成影响。还有如果监控的Redis数据 节点较多，会造成Sentinel节点产生过多的网络连接，也会有一定的影响。
方案二：多套Sentinel，显然这种方案的优点和缺点和上面是相反的， 每个Redis主节点都有自己的Sentinel节点集合，会造成资源浪费。但是优点 也很明显，每套Redis Sentinel都是彼此隔离的。
如果Sentinel节点集合监控的是同一个业务的多个主节点集合，那么使用方案一、否则一般建议采用方案二。