会员系统是一种基础系统，跟公司所有业务线的下单主流程密切相关。如果会
员系统出故障，会导致用户无法下单，影响范围是全公司所有业务线。所以，
会员系统必须保证高性能、高可用，提供稳定、高效的基础服务。
随着同程和艺龙两家公司的合并，越来越多的系统需要打通同程 APP、艺龙
APP、同程微信小程序、艺龙微信小程序等多平台会员体系。
例如微信小程序的交叉营销，用户买了一张火车票，此时想给他发酒店红包，
这就需要查询该用户的统一会员关系。
因为火车票用的是同程会员体系，酒店用的是艺龙会员体系，只有查到对应的
艺龙会员卡号后，才能将红包挂载到该会员账号。
除了上述讲的交叉营销，还有许多场景需要查询统一会员关系，例如订单中心
、会员等级、里程、红包、常旅、实名，以及各类营销活动等等。
所以，会员系统的请求量越来越大，并发量越来越高，今年清明小长假的秒并
发 tps 甚至超过 2 万多。
在如此大流量的冲击下，会员系统是如何做到高性能和高可用的呢？这就是本
文着重要讲述的内容。
ES 高可用方案
| 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 主集群。
| ES 流量隔离三集群架构
