上一期,基于异地多活架构设计复杂度最高的“跨城异地”,我结合自己的经验总结了异地多活设计的4个技巧及其核心思想,我认为掌握这些技巧是进入具体设计步骤的前提。
今天,在掌握这4大技巧的基础上,我来讲讲跨城异地多活架构设计的4个步骤。
按照一定的标准将业务进行分级,挑选出核心的业务,只为核心业务设计异地多活,降低方案整体复杂度和实现成本。
常见的分级标准有下面几种:
以用户管理系统为例,业务包括登录、注册、用户信息管理,其中登录的访问量肯定是最大的。
以QQ为例,QQ的主场景是聊天,QQ空间虽然也是重要业务,但和聊天相比,重要性就会低一些,如果要从聊天和QQ空间两个业务里面挑选一个做异地多活,那明显聊天要更重要(当然,此类公司如腾讯,应该是两个都实现了异地多活的)。
同样以QQ为例,聊天可能很难为腾讯带来收益,因为聊天没法插入广告;而QQ空间反而可能带来更多收益,因为QQ空间可以插入很多广告,因此如果从收入的角度来看,QQ空间做异地多活的优先级反而高于QQ聊天了。
以我们一直在举例的用户管理系统为例,“登录”业务符合“访问量大的业务”和“核心业务”这两条标准,因此我们将登录业务作为核心业务。
挑选出核心业务后,需要对核心业务相关的数据进一步分析,目的在于识别所有的数据及数据特征,这些数据特征会影响后面的方案设计。
常见的数据特征分析维度有:
这里的数据量包括总的数据量和新增、修改、删除的量。对异地多活架构来说,新增、修改、删除的数据就是可能要同步的数据,数据量越大,同步延迟的几率越高,同步方案需要考虑相应的解决方案。
唯一性指数据是否要求多个异地机房产生的同类数据必须保证唯一。例如用户ID,如果两个机房的两个不同用户注册后生成了一样的用户ID,这样业务上就出错了。
数据的唯一性影响业务的多活设计,如果数据不需要唯一,那就说明两个地方都产生同类数据是可能的;如果数据要求必须唯一,要么只能一个中心点产生数据,要么需要设计一个数据唯一生成的算法。
实时性指如果在A机房修改了数据,要求多长时间必须同步到B机房,实时性要求越高,对同步的要求越高,方案越复杂。
可丢失性指数据是否可以丢失。例如,写入A机房的数据还没有同步到B机房,此时A机房机器宕机会导致数据丢失,那这部分丢失的数据是否对业务会产生重大影响。
例如,登录过程中产生的session数据就是可丢失的,因为用户只要重新登录就可以生成新的session;而用户ID数据是不可丢失的,丢失后用户就会失去所有和用户ID相关的数据,例如用户的好友、用户的钱等。
可恢复性指数据丢失后,是否可以通过某种手段进行恢复,如果数据可以恢复,至少说明对业务的影响不会那么大,这样可以相应地降低异地多活架构设计的复杂度。
例如,用户的微博丢失后,用户重新发一篇一模一样的微博,这个就是可恢复的;或者用户密码丢失,用户可以通过找回密码来重新设置一个新密码,这也算是可以恢复的;而用户账号如果丢失,用户无法登录系统,系统也无法通过其他途径来恢复这个账号,这就是不可恢复的数据。
我们同样以用户管理系统的登录业务为例,简单分析如下表所示。
确定数据的特点后,我们可以根据不同的数据设计不同的同步方案。常见的数据同步方案有:
这是最常用也是最简单的同步方式。例如,使用MySQL的数据主从数据同步、主主数据同步。
这类数据同步的优点是使用简单,因为几乎主流的存储系统都会有自己的同步方案;缺点是这类同步方案都是通用的,无法针对业务数据特点做定制化的控制。例如,无论需要同步的数据量有多大,MySQL都只有一个同步通道。因为要保证事务性,一旦数据量比较大,或者网络有延迟,则同步延迟就会比较严重。
采用独立消息队列进行数据同步,常见的消息队列有Kafka、ActiveMQ、RocketMQ等。
消息队列同步适合无事务性或者无时序性要求的数据。例如,用户账号,两个用户先后注册了账号A和B,如果同步时先把B同步到异地机房,再同步A到异地机房,业务上是没有问题的。而如果是用户密码,用户先改了密码为m,然后改了密码为n,同步时必须先保证同步m到异地机房,再同步n到异地机房;如果反过来,同步后用户的密码就不对了。因此,对于新注册的用户账号,我们可以采用消息队列同步了;而对于用户密码,就不能采用消息队列同步了。
数据不同步到异地机房,每个机房都可以生成数据,这个方案适合于可以重复生成的数据。例如,登录产生的cookie、session数据、缓存数据等。
我们同样以用户管理系统的登录业务为例,针对不同的数据特点设计不同的同步方案,如下表所示。
无论数据同步方案如何设计,一旦出现极端异常的情况,总是会有部分数据出现异常的。例如,同步延迟、数据丢失、数据不一致等。异常处理就是假设在出现这些问题时,系统将采取什么措施来应对。异常处理主要有以下几个目的:
常见的异常处理措施有这几类:
1.多通道同步
多通道同步的含义是采取多种方式来进行数据同步,其中某条通道故障的情况下,系统可以通过其他方式来进行同步,这种方式可以应对同步通道处故障的情况。
以用户管理系统中的用户账号数据为例,我们的设计方案一开始挑选了消息队列的方式进行同步,考虑异常情况下,消息队列同步通道可能中断,也可能延迟很严重;为了保证新注册账号能够快速同步到异地机房,我们再增加一种MySQL同步这种方式作为备份。这样针对用户账号数据同步,系统就有两种同步方式:MySQL主从同步和消息队列同步。除非两个通道同时故障,否则用户账号数据在其中一个通道异常的情况下,能够通过另外一个通道继续同步到异地机房,如下图所示。
多通道同步设计的方案关键点有:
2.同步和访问结合
这里的访问指异地机房通过系统的接口来进行数据访问。例如业务部署在异地两个机房A和B,B机房的业务系统通过接口来访问A机房的系统获取账号信息,如下图所示。
同步和访问结合方案的设计关键点有:
3.日志记录
日志记录主要用于用户故障恢复后对数据进行恢复,其主要方式是每个关键操作前后都记录相关一条日志,然后将日志保存在一个独立的地方,当故障恢复后,拿出日志跟数据进行对比,对数据进行修复。
为了应对不同级别的故障,日志保存的要求也不一样,常见的日志保存方式有:
上面不同的日志保存方式,应对的故障越严重,方案本身的复杂度和成本就会越高,实际选择时需要综合考虑成本和收益情况。
4.用户补偿
无论采用什么样的异常处理措施,都只能最大限度地降低受到影响的范围和程度,无法完全做到没有任何影响。例如,双同步通道有可能同时出现故障、日志记录方案本身日志也可能丢失。因此,无论多么完美的方案,故障的场景下总是可能有一小部分用户业务上出问题,系统无法弥补这部分用户的损失。但我们可以采用人工的方式对用户进行补偿,弥补用户损失,培养用户的忠诚度。简单来说,系统的方案是为了保证99.99%的用户在故障的场景下业务不受影响,人工的补偿是为了弥补0.01%的用户的损失。
常见的补偿措施有送用户代金券、礼包、礼品、红包等,有时为了赢得用户口碑,付出的成本可能还会比较大,但综合最终的收益来看还是很值得的。例如暴雪《炉石传说》2017年回档故障,暴雪给每个用户大约价值人民币200元的补偿,结果玩家都求暴雪再来一次回档,形象地说明了玩家对暴雪补偿的充分认可。
只要在2017年1月18日18点之前登录过国服《炉石传说》的玩家,均可获得与25卡牌包等值的补偿,具体如下: 1000游戏金币; 15个卡牌包:经典卡牌包x5、上古之神的低语卡牌包x5、龙争虎斗加基森卡牌包x5。
今天我为你讲了异地多活设计的具体步骤,分别是业务分级、数据分类、数据同步和异常处理,希望对你有所帮助。
这就是今天的全部内容,留一道思考题给你吧,业务分级讨论的时候,产品说A也很重要,因为影响用户使用;B也很重要,因为影响公司收入;C也很重要,因为会导致客户投诉……这种情况下我们该如何处理业务分级?
© 2019 - 2023 Liangliang Lee. Powered by gin and hexo-theme-book.