| 失效链接处理 |
|
万能架构设计：ES+Redis+MySQL PDF 下载
本站整理下载：
相关截图：
主要内容：
1. ES 双中心主备集群架构
同程和艺龙两家公司融合后，全平台所有体系的会员总量是十多亿。在这么大的数
据体量下，业务线的查询维度也比较复杂。有的业务线基于手机号，有的基于微信
unionid，也有的基于艺龙卡号等查询会员信息。这么大的数据量，又有这么多的查
询维度，基于此，我们选择 ES 用来存储统一会员关系。ES 集群在整个会员系统架
构中非常重要，那么如何保证 ES 的高可用呢？
首先我们知道，ES 集群本身就是保证高可用的，如下图所示：
当 ES 集群有一个节点宕机了，会将其他节点对应的 Replica Shard 升级为 Primary
Shard，继续提供服务。但即使是这样，还远远不够。例如 ES 集群都部署在机房 A，
现在机房 A 突然断电了，怎么办？例如服务器硬件故障，ES 集群大部分机器宕机
了，怎么办？或者突然有个非常热门的抢购秒杀活动，带来了一波非常大的流量，
直接把 ES 集群打死了，怎么办？面对这些情况，让运维兄弟冲到机房去解决？这
个非常不现实，因为会员系统直接影响全公司所有业务线的下单主流程，故障恢复
的时间必须非常短，如果需要运维兄弟人工介入，那这个时间就太长了，是绝对不
能容忍的。那 ES 的高可用如何做呢？我们的方案是 ES 双中心主备集群架构。
我们有两个机房，分别是机房 A 和机房 B。我们把 ES 主集群部署在机房 A，把 ES
备集群部署在机房 B。会员系统的读写都在 ES 主集群，通过 MQ 将数据同步到 ES
备集群。此时，如果 ES 主集群崩了，通过统一配置，将会员系统的读写切到机房 B
的 ES 备集群上，这样即使 ES 主集群挂了，也能在很短的时间内实现故障转移，确
保会员系统的稳定运行。最后，等 ES 主集群故障恢复后，打开开关，将故障期间的
数据同步到 ES 主集群，等数据同步一致后，再将会员系统的读写切到 ES 主集群
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
