荔枝FM异地多活IDC机房架构.docxVIP

荔枝FM异地多活IDC机房架构 刘耀华 2021-01-16 多机房架构存在的缘由 单机房一旦死机，断电、维护根本无法挽回整个数据，想离线读取等都不行。当一个机房不行用，全部的业务就都不行用。荔枝 FM 要求业务离用户最近，南方的用户连南方的机房，北方的用户连北方的机房，国外的用户连国外的机房。大陆的网络和国外的网络有肯定的隔离性，假如没有做多机房的连通性，数据的传输和实时性就会有问题。 跨机房的作用是为了备份，一个机房的数据放在另一个机房是异地多活。上面是数据容灾，下面的是业务容灾，第三个是让服务离用户最近。这是荔枝FM做跨机房的缘由。 做过数据备份的各位肯定晓得CAP理论。2000年加州伯克利高校认为分布式系统有全都性，全部节点在任何时间都可以访问到最新的数据副本；每个恳求都能收到一个响应，无论是成功还是失败，必需有服务器的响应，而不是TCP超时、TCP断开等；其中一个区挂了，不影响其他分区。 这三个特性无法共存，只能取两点，牺牲另一点。 AC模型，可用性+强全都性，牺牲了分区容忍性。比如MySQL Cluster集群，内部还是可以用的，MySQL集群供应两阶段提交事务方式，保证各节点数据强全都性。MySQL的集群无法忍耐脱离集群独立工作，一旦和集群脱离了心跳，节点出问题，导致分布式事务操作到那个节点后，整个就会失败，这是MySQL的牺牲。 CP模型，全都性+分区容忍，牺牲了可用性。Redis客户端Hash和Twemproxy集群，各Redis节点无共享数据，所以不存在节点间的数据不全都问题。其中节点大了，都会影响整个Redis集群的工作。当Redis某节点失效后，这个节点里的全部数据都无法访问。假如使用3.0 Redis Cluster，它有中心管理节点担任做数据路由。 AP模型，可用性+分区容忍性，牺牲了强全都性。荔枝 FM用Cassandra集群时，数据可以访问，数据能备份到各个节点之间，其中一个节点失效的话，数据还是可以出来的。而分布式事务的各个节点更新了提交了只是其中一部分节点，底层连续同步，这是AP模型。 AC是高可用性和高强制性，全部的关系型数据库、PG等都是强全都性，牺牲了分区容忍性。MongoDB和BerkeleyDB的可用性比较差。AP模型缺少了强全都性。 互联网行业模型。不同的业务类型要求不同的CAP模型，CA适用于领取、买卖、票务等强全都性的行业，宁愿业务不行用，也不能容忍脏数据。互联网业务对于强全都性不高，发个帖子要审核，没人看到无所谓。发一个音频要进行编码审核才能看到。 Base模型是什么？eBay工程师提出大规模分布式系统的实践总结，在ACM上发表文章提出 Bash 理论是基本可用、软形态和最终全都性。不要求实时全都性，但肯定要实现最终一点。 基本可用（Basically Available）。分布式系统在毛病时允许损失可用性，保证核心业务可用。音频直播或是做活动时，当业务量格外大的时候可以降级。做玩耍也是，在战役的时候最关怀数值的增长，看了多少人都无所谓，缓解核心内容的压力。 软形态（Soft State）。允许系统中消灭的两头形态，两头形态不会耽搁可用性。在写代码、编程业务的设计上，必需容忍有肯定的临时数据同步，考虑到全局锁和数据多版本的对比，把各个节点的相关数据都上锁，这是一个悲观锁，一旦写任务，其他人都能改我的数据，这是比较悲观的心态。 而数据多版本，类似于乐观锁，导致其他人和我方数据冲突的机会并不是那么多，只需在提交的时候发觉版本不一样，更新一下，汇总数据就可以了。做好业务上的隔 离，多数情况都属于多版本，技术都能处理，不肯定要把全部的东西都锁死。允许有肯定的临时数据。最终全都性，在临时上的数据不一样，数据同步也是要花时间 的。 随着时间的迁移，不同节点的数据总是向同一个方向有一个相同的变化，这是Base模型。这种模型格外适合互联网业务的进展。 数据全都性模型。允许窗口期数据不全都，相互关联的数据要同步。序列全都性，全局依据序列挨次来做。线性全都性，每一个时间的时钟要同步，时间序列是严格的，按挨次的。最终是强全都性，一个时间只能实行一个任务。这比较适合于互联网，所以荔枝 FM 选择了最终全都性。 系统业务调研 简约引见下荔枝FM的系统架构。客户端接入代理，往上到服务器。服务器特地对手机进行业务处理，后面是数据中心，数据中心后面是存储，有Redis、 MySQL和Memcached，这是一个简要的结构。变成一个分层的结构，分层结构和大家的业务差不多，首先是接入层，接入层担任连接管理、 Socket代理、Nginx，Socket代理特地对连接形态进行管理。业务层，比如手机服务、网站服务、后台以及各种各样的业务层。下面有服务总线， 接下来是数据层，特地对数据规律进行管理。最下