分布式系统技术难题--异地多活
什么是异地多活？
为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。事实上，异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。
异地多活常见的解决方案有哪些？
- 请求如何路由,如何实现会话保持?
对于请求路由问题,其设计目标在于,让特定用户访问特定的机房,并且可以实现流量分发策略控制,根据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路由,大型网游可能按照服务区对用户处理流程限定在某个特定机房中。
---------------------------------------------------------
老钱点评：双机房就好比人的左右脑，机房之间的网络就是胼胝体。现在胼胝体坏了，还必须保证这个人能正常的生活，吃喝拉撒睡都还能干，这确实是一件非常不容易的事。