分布式系统技术难题--异地多活

什么是异地多活？

为了保证系统可以对机房级别的故障进行容错,不会使系统不可用,这就须要在机房级别对系统进行冗余处理。而这就须要在架构上进行良好的设计。来面对多机房场景下的技术挑战。事实上，异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络广泛延迟的状况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。

异地多活常见的解决方案有哪些？

1. 请求如何路由,如何实现会话保持?

对于请求路由问题,其设计目标在于,让特定用户访问特定的机房,而且能够实现流量分发策略控制,根据IP会话保持。而在于特定业务中,能够根据制定更加复杂的路由规则,利用前端传递来的标签，作路由策略转发。让特定的一些用户在同一个机房中,例如饿了吗，基于附近地区的业务场景，用户,骑手,商家都是在同一个地区。咱们经过区分哪些用户在同一个地区,机房按地区进行业务划分。这样商家，用户,骑手的整个核心业务流程会在一个机房中完成，避免了跨机房调用形成延迟,用户下单几分钟,商家才接到订单,骑手接单到派送时间被延长。因此实现一个机房外的路由组件是颇有必要的,在机房级别添加一个路由网关。常见的作法就是基于用户ID进行HASH的方式将用户固定在一个机房处理该用户相关的全部业务逻辑。

2. 数据存储服务如何同步?

对于数据存储问题是网络延迟形成最大影响的地方。在常见的解决方案中有多机房单集群,和多机房多集群部署两种.数据的同步能够分为，数据库,缓存,消息队列,session等。在多机房单集群中如何部署？ 及整个系统中存储服务是惟一的一个集群,只有一个master节点.作读写分离设计,全部机房上的服务只能向数据存储集群上的master节点提交写请求,而在读数据时向本身机房上的salve节点提交请求。数据的同步委托给基础组件完成,能够利用数据自己的数据同步方案，但一般没法结合业务特性进行优化提升性能，redis 自己的数据同步在master同步salve时会致使salve不可用，mysql自身的同步方案性能和稳定性都比较差。这时须要团队亲自制定化数据同步组件。来保证多个机房上的数据全量同步。还能够基于消息队列来实现数据同步，但这会致使额外的带宽占用,更能够搭建专用网络线路解决。不管任何的同步方式,在业务端须要对访问数据库的客户端进行重构使其可以支持读写分离。而且为了防止网络延迟，咱们能够在客户端作不少事情,第一,双写:多个机房下容许出现多个Master,那么客户端进行封装在底层将写请求发送给多个Master上。第二:双读或回源读,当读取本机房数据没有读到时,去主机房读取或者根据用户请求解析出数据源在哪一个机房而后去读取。

3. 是否能够跨机房服务调用？延迟提升,占据更多的网络带宽怎么办？

内部RPC等禁止跨主机调用,这样能够防止数据被依赖。避免对专用网络占用更多的带宽。而且当一个机房不可用后不会影响可用机房的业务运行。

4. 当某个机房不可用时,需将该机房的流量切入另外一个机房,那么每一个机房要预留多少存储与计算资源？

通常通过测试评估,每一个机房预留S级服务承载的流量资源。

5. 一些devops组件如何支持跨机房部署环境？

监控系统,部署系统等如何汇总全部机房的数据,仍是将其区分开？ 通常来讲,devops组件须要对多机房部署进行升级,增长机房选项。在多机房部署中,日志数据可汇总到统一的数据区处理，日志记录一般异步进行便可。

6. 对于强一致性业务如何保证？

对于强一致数据,应创建多机房单集群的部署模式,使用双读策略。多机房多集群模式,采用双写策略。

7. 如何拆分业务,保证最大限度的避免跨机房延迟

将业务按照，流量大的业务,核心业务,产生收入的业务进行拆分,优先保证核心业务的多机房部署。将这些业务的总体流程逻辑放在一个机房内处理。列如饿了吗按照 地域信息进行流量切分,将用户下单，卖家接单,骑手接单配送这个核心流程尽可能放在一台服务器处理。阿里就按用户ID路由,大型网游可能按照服务区对用户处理流程限定在某个特定机房中。