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

stay_sun

回复 58# bbjmmj

你得看下   cap 理论了    很简单  前端代理的话  分发给不同的数据库  在mysql 是有的  而且 阿里已经对他进行了二次开发  用在淘宝网数据库
但是一致性达不到要求。 你分发到不同的数据库  俩条语句提交都成功了  还是提交到一个 数据库算事务完成。 当你多个数据库成功后才算提交完成。
你的性能又如何。当你去修改数据   数据库不一致  你的效率会很低的。 这种架构适合的是单机房的部署。不能做多活的
阿里既然有了分布式 drds 可以做到  多活  光纤断了  淘宝没有问题  就是因为这个
淘宝可以  2000 库存 卖出 3000件  补货被  大不了退款  
但是支付宝呢
   

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服务器足可胜任这样的负荷，分库之后，负荷问题也就解决了。
临时的数据迁移并不需要迁移到每个地级市，迁移到每个省就可以了，数据迁移的范围和数量非常有限，核心系统有能力承载，尤其是分库之后。