本文围绕同程艺龙会员系统展开，介绍其业务场景及高并发挑战。阐述了异构存储架构，包括MySQL和ES集群方案，以及Redis缓存方案。还提及了系统的高可用架构、平滑迁移方案、ES优化策略，最后展望了更精细化的流控和降级策略。
目录
任何一个系统，都不能保证百分之一百不出问题，所以团队要有面向失败的设计，那就是更精细化的流控和降级策略。
同程艺龙会员系统的业务场景
同程艺龙是同程旅游集团旗下的同程网络与艺龙旅行网在2017年12月29日共同成立的公司，新公司将整合双方的交通、酒店等优势资源，打造更为领先的旅行服务平台。
2018年6月21日，同程艺龙在港交所提交招股书，联席保荐人为摩根士丹利、摩根大通、招银国际。
2018年11月26日，同程艺龙正式在港交所挂牌。
同程艺龙为机场、酒店、目的地等旅行行业产业链上下游提供技术赋能，加速产业数智化进程。终端用户应用包括：
-
同程APP
-
艺龙APP
-
同程微信小程序
-
艺龙微信小程序
2021年第三季度，同程艺龙平均月活达到2.77亿人，同比增长12.7%；平均月付费用户达到3360万人，同比增长12.8%。
截至2021年9月30日的12个月里，同程艺龙付费用户同比增加29.6%至1.96亿人。
在同程艺龙内部，会员系统是一种基础系统。
这种基础系统，跟公司所有业务线的下单主流程密切相关。
在同程艺龙平台的内部，如果会员系统出故障，会导致用户无法下单。
也就是说，如果会员系统出故障，影响范围不仅仅是会员系统本身，而是全公司所有业务线。
所以，会员系统必须保证高性能、高可用、高并发，为大的业务平台，提供稳定、高效的基础服务。
随着同程和艺龙两家公司的合并，越来越多的系统需要打通同程APP、艺龙APP、同程微信小程序、艺龙微信小程序等多平台会员体系。
例如微信小程序的交叉营销，用户买了一张火车票，此时想给他发酒店红包，这就需要查询该用户的统一会员关系。
因为火车票用的是同程会员体系，酒店用的是艺龙会员体系，只有查到对应的艺龙会员卡号后，才能将红包挂载到该会员账号。
除了了 交叉营销 场景之外，还有许多、许多的业务场景需要查询统一会员关系。
例如订单中心、会员等级、里程、红包、常旅、实名，以及各类营销活动等等。
所以，会员系统的请求量越来越大，并发量越来越高。
2022年五一小长假的秒并发TPS甚至超过2万多。
在如此大流量的冲击下，会员系统是如何做到高性能和高可用的呢？
会员数据异构存储架构方案
同程艺龙内部，会员系统采用的是 mysql集群+ES集群结合的 异构存储架构
具体如下图所示
-
为什么使用mysql 目前最火的关系型数据库，支持事务， 支持B+树结构高性能索引，数据低延迟（写入即可查）
但是有两大缺点：
-
（1）不宜全文搜索，如果非索引全文搜索，会出现全表搜索， 性能低
-
（2）使用mysql 需要分库分表，这种时候，没法做全表关联
-
-
为什么使用elsaticsearch es在搜索方面天生具有优势，
-
（1）倒排索引，天生的全文检索
-
（2）支持大表、宽表、非结构数据。不像关系型数据库那样一个简单的搜索就需要跨表联表、跨库关联
-
-
mysql+elasticsearch的好处
以mysql存取数据，es作为搜索引擎，保证性能
MySQL会员主库的：高可用+高并发架构
上述讲到，全平台会员的绑定关系数据存在ES，而会员的注册明细数据存在关系型数据库。
最早，会员使用的数据库是SQL Server，
直到有一天，单台SQL Server数据库已经存储了十多亿的会员数据，服务器已达到物理极限，不能再扩展了。
按照当然的增长趋势，过不了多久，整个SQL Server数据库就崩了。
大家想想，SQL Server数据库崩了，那是一种什么样的灾难场景：
会员数据库崩了，会员系统就崩了；
会员系统崩了，全公司所有业务线就崩了。
想想就不寒而栗，酸爽无比，同城艺龙团队 立刻开启了迁移DB的工作。
MySQL双中心Partition集群方案
经过调研，团队选择了双中心分库分表的MySQL集群方案，
mysql分表架构
会员一共有十多亿的数据，团队把会员主库分了1000多个分片。
从单个分片的维度来说，平分到每个分片大概百万的量级，单个分片不到千万级，足够使用了。
mysql主从架构
整个MySQL集群采用1主3从的架构。
主库放在机房A，从库放在机房B，两个机房之间通过专线同步数据，延迟在1毫秒内。
mysql流量路由架构
-
写入的路由：写数据都路由到master节点所在的机房A，
-
读取的路由：读数据都路由到本地机房，就近访问，减少网络延迟。
会员系统通过DBRoute读写数据，DBRoute 是一个统一的数据库访问sdk 组件，可以根据流量开关，进行流量的切流。
具体的架构图，如下图所示：
这样，采用双中心的MySQL集群架构，极大提高了可用性，即使机房A整体都崩了，还可以将机房B的Slave升级为Master，继续提供服务。
双中心MySQL集群搭建好后，团队进行了压测，测试下来，秒并发能达到2万多，平均耗时在10毫秒内，性能达标。
会员主库平滑迁移方案
接下来的工作，就是把会员系统的底层存储从SQL Server切到MySQL上，这是个风险极高的工作，主要有以下几个难点：
-
会员系统是一刻都不能停机的，要在不停机的情况下完成SQL Server到MySQL的切换，就像是在给高速行驶的汽车换轮子。
-
会员系统是由很多个系统和接口组成的，毕竟发展了10多年，由于历史原因，遗留了大量老接口，逻辑错综复杂。这么多系统，必须一个不落的全部梳理清楚，DAL层代码必须重写，而且不能出任何问题，否则将是灾难性的。
-
数据的迁移要做到无缝迁移，不仅是存量10多亿数据的迁移，实时产生的数据也
最低0.47元/天 解锁文章
扫一扫
3050
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
