多数据中心状态同步两地三中心的理论.docxVIP

PAGE 1 PAGE 1 多数据中心状态同步两地三中心的理论  本文共享了跨数据中心状态同步两地三中心的理论技术，涉及数据库相关，其中会交代“如何去做”，以及会让大家理解“为什么要这么去做”。  本文共享了跨数据中心状态同步两地三中心的理论技术，涉及数据库相关，其中会交代“如何去做”，以及会让大家理解“为什么要这么去做”。  分布式协议/概念  关于分布式协议的概念。以今年的“双十一”阿里的创造的惊人交易额为例，它的技术团队出来做技术共享时提到一点，就是支付宝交易每秒钟到了8.5万笔，这其中有许多东西可可供分析。  这其中就包含分布式协议。全球范围内真正能够实现分布式全都性算法的只有两个：一个是Paxos，另一个是Raft。Paxos拥有很长的历史，它最早是谷歌实现的。2012年，有两位教授发表了一篇论文叫做Raft，特别值得去学习。论文中有一个组建使用的也是Paxos的算法。要真正实现分布式数据状态协议的话，一般会选择Paxos和Raft。从简单实现的角度考虑的话，就采用Raft。  远距离跨机房同步问题  途牛最初的系统都在南京，但为了照看用户体验，公司就将网站迁到了北京。原因是技术团队进行了调用，发觉其中存在许多问题，包括远距离跨机房同步问题，以及专线稳定性对服务质量的影响。一般的系统网络都是4个9或以上，还有宽带挤占、各个系统调用等，还有下面要详细讲的数据库同步延时。  途牛的后台系统允许客户注册，在网站上注册可以选择南京或北京。技术团队选择南京，是因为更多的用户集中在南京这边。假如注册时到北京去，我们读的就是北京数据库。而一旦出现延时就无法登录，这样用户体验是特别糟糕的。除此之外，就是不能做强全都性高可用。假如在两地做，万一出问题需要切换，数据可能会丢失，这需要极力避免。  CAP中，我们的选择  关于“CAP”，许多人都了解它的含义，就是全都性、可用性、分区容错性。但这三者不可兼得，因此分区是必定的。对电商来说，它对数据的要求比较高，所以选择Consistency（全都性）。  上图中的重合区域只有一个“小三角”，它说明这个数据很难落地，三者的优点很难兼顾。因此看上去CAP能够满意需求的，而实际状况并不是这样。  上文提到，途牛的选择是针对当前的这种开源，或者是技术实现。技术团队现在用开源数据库，来实现：  1.主从复制、做高可用；  2.防止丢失数据；  3.只牺牲一定的性能，等待数据被同步。  但远距离机房延时太大，从而影响了系统吞吐量，所以打算做了机房搬迁。今年公司把整个北京机房搬迁到了南京，与主要系统合为一处。  数据的传输  上面的图片，相信许多人都见过。途牛的应用是先向数据库发起事务，这个事务完成后，它会写到日志里面，然后返回应用。  这种专线最终落地是什么？就是光纤传输。可以算一下它的传输性能：真空中光速30万千米/S，光纤材质折射率1.45左右，全反射传输，路径大于光纤长度，折算下来小于20KM/0.1MS，假如算同城的话，是1000ms/0.2ms=5000（TPS）。可以通过技术提升这个速度，这与业务详细架构相关。  南京到北京，距离近千公里，光纤不会是直线布置，中间会包含许多的弯和网络设备。在这种状况下，南北传输，可以达到1000MS/50MS=20（TPS）水平。  基于HA的数据中心系统构建  之前途牛会员系统的后台并不完善。有时会被用户刷会员，甚至被刷坏掉。当时系统支持的事务量很小，这个状况跟创业公司有点类似：在高速发展阶段，团队整体的效率没那么高，但为了降低成本，可能会让一个功能快速上线，但中间如何优化、如何实现都没有考虑过。这样的系统，经过多年累积，其中就会出现了许多问题。后来，技术团队使用了异步的方式解决了这个问题。  双十一阿里如何做到8万5千笔/秒的交易频率的？最早从腾讯开始，通过QQ号取模的方式，其中道理是一样的。一个整体，假如是串行，它的分布量是比较有限的。前文提到的0.2毫秒，而理论上只能达到5千每秒，如何去提升呢？在编程上面要作调整，当性能发展到一定规模后，需要提升整个系统吞吐量，就必需考虑低层的架构，哪怕谷歌也是一样：曾经谷歌发觉这里面数据库识别越来越多，各种不可用，谷歌就把系统迁移到自己开发。这么大的数据量怎么去做？如下图中所述。  HA组建及双中心HA缺陷。这里面有heartbeat、keepalived等，也是一样的，但是缺少第三方仲裁，会导致“脑裂”，特殊在偶数的下面。假如两部分都正常，可能