认识达内从这里开始

随着互联网的不断发展，越来越多的互联网企业都把自己的数据信息上传到云空间进行存储。而这些存储空间就是我们新的数据中心。今天，我们就一起来了解一下这些全新的数据存储方法的优势。

什么是异地多活

异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。冷备份的主要问题是成本高，不跑业务，当主机房出问题的时候，也不一定能成功把业务接管过来。

CAP原则

分布式架构设计无论怎样都绕不开CAP原则，C一致性A可用性P分区容错性，分区容错性是必不可少的，没有分区容错性就相当于退化成了单机系统，所以实际上架构设计是在一致性和可用性一个天平上的两端做衡量。为什么强一致性和高可用性是不能同时满足?假如需要满足强一致性，就需要写入一条数据的时候，扩散到分布式系统里面的每一台机器，每一台机器都回复ACK确认后再给客户端确认，这就是强一致性。如果集群任何一台机器故障了，都回滚数据，对客户端返回失败，因此影响了可用性。如果只满足高可用性，任何一台机器写入成功都返回成功，那么有可能中途因为网络抖动或者其他原因造成了数据不同步，部分客户端独到的仍然是旧数据，因此，无法满足强一致性。

异地多活的挑战

延迟异地多活面临的主要挑战是网络延迟，以北京到上海1468公里，即使是光速传输，一个来回也需要接近10ms，在实际测试的过程中，发现上海到北京的网络延迟，一般是30ms。

一致性用户在任何一个机房写入的数据，是否能在任何一个机房读取的时候返回的值是一致性的。

误区

所有业务都要异地多活

以用户中心为例，注册是没必要做异地多活的，假如用户在A机房注册了，在数据没有向外同步的时候，A机房网络中断，这个时候如果让用户切换到B机房注册，就有可能发生数据不一致，出现两个基本相同的账号，这是不可容忍的。但是相对应的来说，用户登录这种是关键核心业务，就有必要做到异地多活了，用户在A机房登录不了，那就让用户在B机房登录。虽然有极端的情况，用户在A机房修改了密码，但是出现网络中断，B机房的用户仍然保存的是旧密码，但是相对于不可登录来说，这种情况是可容忍的。同时有些业务仍然是无法实现异地多活的，比如涉及到金钱的业务，加入有一个用户有100块，消费了50块，A机房发生异常，数据没有同步出去，这时候用户在B机房登录后发现自己还有100块，可以继续消费，就会对业务造成严重的影响。

必须做到实时一致性

受限于物理条件，跨地域的网速一定会存在延迟，一般是几十毫秒，如果遇上网络抖动，延迟超过几秒甚至几十秒都有可能。解决方法只能是减少需要同步的数据和只保证数据的终一致性，有时候用户在A机房修改了一条数据，业务上实际上是能容忍数据的短时间不一致的，即使其他用户在B机房读到的是旧数据，实际上对业务也没有任何影响。

只使用存储系统的同步功能

大部分场景下，MySQLRedis自带的同步功能已经足以满足需求了，但是在某些极端情况下，可能就不合适了，MySQL的单线程复制可能会产生较大的延迟，Redis可能会有全量复制，所以系统要灵活使用各种解决方案。

用消息队列把数据广播到各个数据中心

回源读取，当A机房发现没有这条数据的时候，根据路由规则去B机房去读取该数据

重新生成数据，A机房登录后生成session数据，这时候A机房挂了，可以把用户切换到B机房，重新生成session数据。

实现全部的高可用

全部的高可用是无法保证的，硬件的损坏，软件的BUG，光纤传输等太多不可控的因素，而且也要在成本上做一个权衡，尤其是对于强一致性业务，C和A只能取一个平衡，容忍短时间的不可用来保证数据的完全一致性。

节选：博客园

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!