单机房一旦死机，断电、维护根本无法挽回整个数据，想离线读取等都不行。当一个机房不可用，所有的业务就都不可用。荔枝FM要求业务离用户最近，南方的用户连南方的机房，北方的用户连北方的机房，国外的用户连国外的机房。大陆的网络和国外的网络有一定的隔离性，如果没有做多机房的连通性，数据的传输和实时性就会有问题。

跨机房的作用是为了备份，一个机房的数据放在另一个机房是异地多活。上面是数据容灾，下面的是业务容灾，第三个是让服务离用户最近。这是荔枝FM做跨机房的原因。

做过数据备份的各位一定知道CAP理论。年加州伯克利大学认为分布式系统有一致性，所有节点在任何时间都可以访问到最新的数据副本；每个请求都能收到一个响应，无论是成功还是失败，必须有服务器的响应，而不是TCP超时、TCP断开等；其中一个区挂了，不影响其他分区。

这三个特性无法共存，只能取两点，牺牲另一点。

AC模型，可用性+强一致性，牺牲了分区容忍性。比如MySQLCluster集群，内部还是可以用的，MySQL集群提供两阶段提交事务方式，保证各节点数据强一致性。MySQL的集群无法忍受脱离集群独立工作，一旦和集群脱离了心跳，节点出问题，导致分布式事务操作到那个节点后，整个就会失败，这是MySQL的牺牲。

CP模型，一致性+分区容忍，牺牲了可用性。Redis客户端Hash和Twemproxy集群，各Redis节点无共享数据，所以不存在节点间的数据不一致问题。其中节点大了，都会影响整个Redis集群的工作。当Redis某节点失效后，这个节点里的所有数据都无法访问。如果使用3.0RedisCluster，它有中心管理节点负责做数据路由。

AP模型，可用性+分区容忍性，牺牲了强一致性。荔枝FM用Cassandra集群时，数据可以访问，数据能备份到各个节点之间，其中一个节点失效的话，数据还是可以出来的。而分布式事务的各个节点更新了提交了只是其中一部分节点，底层继续同步，这是AP模型。

AC是高可用性和高强制性，所有的关系型数据库、PG等都是强一致性，牺牲了分区容忍性。MongoDB和BerkeleyDB的可用性比较差。AP模型缺少了强一致性。

互联网行业模型。不同的业务类型要求不同的CAP模型，CA适用于支付、交易、票务等强一致性的行业，宁愿业务不可用，也不能容忍脏数据。互联网业务对于强一致性不高，发个帖子要审核，没人看到无所谓。发一个音频要进行编码审核才能看到。

Base模型是什么？eBay工程师提出大规模分布式系统的实践总结，在ACM上发表文章提出Bash理论是基本可用、软状态和最终一致性。不要求实时一致性，但一定要实现最后一点。

基本可用（BasicallyAvailable）。分布式系统在故障时允许损失可用性，保证核心业务可用。音频直播或是做活动时，当业务量非常大的时候可以降级。做游戏也是，在战斗的时候最关心数值的增长，看了多少人都无所谓，缓解核心内容的压力。

软状态（SoftState）。允许系统中出现的中间状态，中间状态不会耽误可用性。在写代码、编程业务的设计上，必须容忍有一定的临时数据同步，考虑到全局锁和数据多版本的对比，把各个节点的相关数据都上锁，这是一个悲观锁，一旦写任务，其他人都能改我的数据，这是比较悲观的心态。

而数据多版本，类似于乐观锁，导致其他人和我方数据冲突的机会并不是那么多，只要在提交的时候发现版本不一样，更新一下，汇总数据就可以了。做好业务上的隔离，多数情况都属于多版本，技术都能解决，不一定要把所有的东西都锁死。允许有一定的临时数据。最终一致性，在临时上的数据不一样，数据同步也是要花时间的。

随着时间的迁移，不同节点的数据总是向同一个方向有一个相同的变化，这是Base模型。这种模型非常适合互联网业务的发展。

数据一致性模型。允许窗口期数据不一致，互相关联的数据要同步。序列一致性，全局按照序列顺序来做。线性一致性，每一个时间的时钟要同步，时间序列是严格的，按顺序的。最后是强一致性，一个时间只能实行一个任务。这比较适合于互联网，所以荔枝FM选择了最终一致性。

简单介绍下荔枝FM的系统架构。客户端接入代理，往上到服务器。服务器专门对手机进行业务处理，后面是数据中心，数据中心后面是存储，有Redis、MySQL和Memcached，这是一个简要的结构。变成一个分层的结构，分层结构和大家的业务差不多，首先是接入层，接入层负责连接管理、Socket代理、Nginx，Socket代理专门对连接状态进行管理。业务层，比如手机服务、网站服务、后台以及各种各样的业务层。下面有服务总线，接下来是数据层，专门对数据逻辑进行管理。最下面的是存储层，比如有数据库、Bash、Memcached、Redis。

业务数据分析。荔枝FM要求跨机房同步，一是资源文件，向用户上传的音频、图象、头像、图片，数据量非常大。数据量一旦不同步，用户会反应比较强烈。比如用户发表评论，发表完不见了，用户会很紧张，会不停的刷，想找出是软件问题还是网络问题。因此这点的优先级非常高。荔枝FM用了机房专线，它的故障率比较低，响应时间也比较低。后备限制公网，用两种策略进行传输。

荔枝FM有两大IDC机房，一是绿色的机房专线，这是高速通道，二是红色的公网，类似于国道，比较便宜，这里有两个机房，为了离用户更近，因此选择用智能DNS看用户的机房。

系统架构方面。两个业务数据之间怎么进行管理？我们设置了一个主机房，Master和Slave，所有的业务都是读自己机房内部的，都会往Master方向写，然后同步在同一个机房，了解读业务比写业务高几个数量级。主机房在北京，北方的用户直接写在自己的本机，然后回应。南方会把请求发到北京机房，异步传输回来同步到南方的机房里。

机房内部怎么做？我们提供了数据访问层API，封装了下面所有同步，程序员和开发人员不用担心，下面都有DataStore接管。代理服务器可以根据你的类型往本地的存储性能去读。它会区分用户写、数据库写还是好友写，分发到不同的DS服务端，处理完成告诉用户OK了。另一步进行分发，到另一个机房同步，是读写分离的系统架构。

接入层、客户端，通过代理往DS服务端写数据，资源分发同步。失效怎么办？左边的Master是主的，由DS代理进行检测，如果没响应，马上切换到另一个机房，穿到另一个机房里，把数据写到Slave，等到这个机房的数据恢复后，再手动切换回来，这是主失效。

从失效的话，会将它缓存起来放在文件里，等恢复后，再推送数据缓存过去。最麻烦的是老链问题，两头是活的，中间链断了，南北之间IDC链路，不管是专线还是公网都有可能会抽风，心跳检测出问题后，两边会独立写。DS代理认为这边服挂了，Slave认为主挂了，直接把数据往这边写。当线路恢复时，两边同步数据，要尽量避免数据冲突，这时候系统监控到底是哪一个链路出问题，果断关闭，减少数据冲突的风险。

由于配置服务器把所有配置发放到服务器里，监控、报警、数据报告会通过邮件、







































广州治白癜风最好的医院
白癜风治疗医院

转载请注明原文网址：http://www.4006677657.com/lzjg/10755.html