异地多活实际可行性有多强？支付宝故障引热议

bbjmmj

stay_sun 发表于 2015-06-02 12:46
回复 58# bbjmmj

你得看下   cap 理论了    很简单  前端代理的话  分发给不同的数据库  在mysql 是有的 ...

不用非得强迫保持一致，只要不发生错误就可以了。没有任何电脑系统不能容忍停机，但不能容忍数据丢失却很常见，不能为了稳定就把一切都压倒。 不是理论错了，而是我们用错了理论，CAP是集中式系统理论，不适用分布式系统。
我说的代理MYSQL上是没有的，它是前端服务器上跑的东西，它把请求调度到不同的服务器，不会要求其它服务器同时记录或者处理这些请求，任何数据都是在局部处理，不对全局产生影响，因此不需要一致性，这也是双活和多活有天壤之别的原因所在，它俩完全不是一个东西，不可同日而语。

stay_sun

回复 62# bbjmmj


    你说的 只不过是分发 直接拿lb  做转发可好  可是数据 怎么办  这个范围太大了   只不过是一个想法  落地太难了   

stay_sun

回复 62# bbjmmj


    感觉你考虑的 东西也太少了   基本上的想法 就是阿里的  分布式 mysql 数据库  drds

bbjmmj

stay_sun 发表于 2015-06-02 13:32
回复 62# bbjmmj

你说互联网会要求所有电脑一致么？这就是分布式系统和集中式系统的区别所在。现实中的一致性都是有条件的，局部的，个别的，那么数据库一致性为什么要违背人伦呢？？？
问题的关键是对分布式的理解，国内没有分布式系统概念，他们的思维仍然停留在集中式系统里。
想得不在多少，而是看想没想对地方，想错了地方就会永远在错误里绕圈子。

niao5929

得罪领导的话不好。呵呵回复 58# bbjmmj


   

bbjmmj

回复 66# niao5929


   

如果把全局一致降低为局部一致，多活就可以实现了，比如对用户ID进行HASH，HASH到不同的数据库节点，这样同一个用户的数据就不用存得到处都是，这里没有全局的一致，就是众多的局部一致。
多活的难题在管理，多个数据中心就得配多个领导班子，吃闲饭的太多了，多活要求企业管理先实现扁平化，很多领导饭碗都会被……嗯~嗯~
不是技术问题，是行政问题，这是我最终的看法。

stay_sun

回复 67# bbjmmj


    你做了哈希桶  最后没有分布式  你这个只是做了分库分表  如果你把 这样的  数据库 放在不同机房中  你访问 时候 跨机房 跨地域  这个延迟  系统一般接受不了  对于容灾也没有
阿里的挖光纤  你怎么解决  

bbjmmj

stay_sun 发表于 2015-06-02 15:30
回复 67# bbjmmj

首先，WEB用户对延迟不敏感，他们能容忍秒级延迟。
第二，同一个WEB用户同一时间段内发起的交易数量非常有限。
第三，可以在WEB用户发起第一个交易的时候，从远端把用户数据整块捞取到当地服务器上，本地服务器上指定时间内数据不变，再把数据迁出到远端。

只要不是强一致性依赖，延迟就不是问题。

bbjmmj

stay_sun 发表于 2015-06-02 15:30
回复 67# bbjmmj

量化分析更能说清楚问题。
淘宝双十一完成一亿笔订单，我们可以据此计算出它需要的最大吞吐能力大约是每秒一万笔订单，如果由十台数据库服务器处理，每台平均每秒一千笔订单，我认为普通X86服务器足可胜任这样的负荷，分库之后，负荷问题也就解决了。
临时的数据迁移并不需要迁移到每个地级市，迁移到每个省就可以了，数据迁移的范围和数量非常有限，核心系统有能力承载，尤其是分库之后。

fengzhanhai

回复 50# lemoncandy
不是罚款的问题，要看影响面有多大，更多负面影响是对金融机构的商誉和客户信心的重大打击~其实对于金融机构来讲，若发生此类事件，更多的压力来自监管机构和储户，若发生数据丢失，严重的可能会导致停业整顿甚至破产~
当然破产此类问题，目前在国内的金融行业不太可能发生，因为每一家银行都是由政府背景的，包括所谓的民营银行~~