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

bbjmmj

如果能保证至少两个SLAVE达到同步，MASTER上的数据就不用落地了，可以整个数据库放在内存盘上跑。

bbjmmj

stay_sun 发表于 2015-06-08 12:19
回复 99# fengzhanhai

终于明白你们为什么做不到多活了，不是技术上做不到，是你们做不到，因为你们用错了理论。那个CAP理论实际上是个悖论，比如一件实体商品，放到多个数据库中交易，就变成了多件虚拟商品，实体商品件数和虚拟商品件数就产生了不一致，这是不可避免的。放到同一数据库中交易就可以一致了，但是我们讨论的CAP是分布式系统理论，你都已经集中了不分布了，那还聊什么分布式呢？CAP模型假定不同事务处于相同时空，它只是理论意义上的，不适合多活应用的现实环境。互联网覆盖范围大，传输延迟大，集中处理大范围业务，传输延时会导致用户体验变差，这个时候就得妥协，接受不一致的现实存在。电商不是银行，银行可以用排号机让用户等待，电商不能这么干。
理论决定模型，模型决定架构，而架构则要先满足用户而不是理论的需求，用户体验要好，操作速度要足够快，而你要解决好时空不一致带来的各种麻烦。从用户角度出发，才有可能实现多活，理论角度出发绝对是死路。

bbjmmj

int ReplSemiSyncMaster::readSlaveReply(NET *net, uint32 server_id,

赤裸裸的延时等待！如果是商用数据库，这样的代码，我们无能为力，所以多活一般无法实现，因为同步的延时实在太高了。
幸运的是，有开源我们还有机会，支付宝用的是MYSQL兼容数据库，有机会改源码，他们用的好像是Percona，我用的是mariadb，都差不多。
实现多活的前提是：你敢用开源吗？

lemoncandy

fengzhanhai 发表于 2015-06-08 11:44
回复 95# lemoncandy
其实所有的知名的、具备一定影响力的企业，不只是国有企业还包括所谓的民企，但是他 ...

也是，都是那种大到不能倒的公司啊，迟早会出问题的，个人观点

bbjmmj

就像没看过相对论的人把经典物理学奉为绝对真理，绝大多数人并不知道CAP理论是错的，CAP就好比在平面上讨论三维空间问题一样，时空概念的缺失让CAP变成了伪科学。我们还是来看看支付宝怎么交易吧。

先假定一个可实现的多活模型。支付宝在每个地级市设立一个分店，分店服务器里面保存了淘宝所有商品信息，这是很容易做到的。设立地级市分店的目的是提高下单速度，各城市到地级市的延迟是很低的，1毫秒左右，速度很快，买家可以获得更好的交易体验。

买家通过支付宝买了一件商品，本地服务器利用网银接口把钱打到当地支付宝账户（这样做不需要转账费），同时告诉所有城市的分店，我卖出了一件商品，请你们把这件商品的库存减1。可以用一个中心节点发放库存减少通知，而不是让一个分店去联络所有分店，这样做的好处是效率比较高，通过中心节点转发可以让网络传输距离之和达到最短。

好了，这里面是有单点的，假如中心节点宕机，怎么办？大不了大家不知道库存少了，买家还是照常下单，卖家补货或者退货。淘宝上都是小卖家，每天销售量非常有限，即使中心节点宕机一整天，对销售也不会有多大影响，只是效率降低了一些，而那些大卖家货源充足，更新库存数量的时间间隔可以容许很长时间，中心节点宕机一段时间对他们不会有任何影响。

再考虑一种情形，买家拍下商品并付了款，卖家没有收到订单，不发货，交易就无法完成，这次总该不一致了吧？你看看CAP理论还是对的！先别太早下结论，这个时候买家可以向淘宝申诉，退款，淘宝还会给买家赔点精神损失费，我老婆就遇到过这种情况，最终还是达到了一致性。

现实物质世界充满了各种不确定性，本身就是一个不一致的世界，如何要求它非得一致不可呢？所以CAP只能在理论上作为一个茶余饭后的谈资，没有现实意义。这里提到的这种架构，因为每个分店都保留了交易记录，中心节点恢复运作后可以进行数据核对，数据不会丢失，部分不一致最终可以通过其它手段协调解决，C、A、P三个条件同时满足，CAP认为只能有两个条件满足是错的。

一件商品从下单到最后的成交需要数日时间，你的应用环境是否允许这么大时间跨度的一致性呢？不能满足，你那个一致性就是假的。

支付宝不可以做跨境交易么？跨境交易的延迟更大，会面临更残酷的一致性挑战，难道生意就不做了么？异地多活不是可行不可行的事，而是必须要做到的事，中国是个大卖场，所有国家都想在这个市场里卖出自己的产品，很显然，为他们提供交易平台是件有利可图的事，如果你说异地多活没必要，那就等于说赚钱也没有必要了。

bbjmmj

看了下sql/log.cc，不清楚MYSQL内部流程，不知道该怎么改，只能靠猜。猜测应该是先把LOG写到缓存，再写到文件系统，然后启用复制，再调用半同步。写到文件系统以后，数据何时写到永久存储，那就要看文件系统咋处理了，这里面存在数据丢失的可能，除非日志能同步到永久存储，但这么做会受到存储系统写入延迟的限制，主机每秒处理的事务数可能会降至几百个甚至几十个，无法容忍。如果能在写入缓存之后发送日志，就可以避免数据丢失，不但提高了可靠性，性能也会大大提升。

fengzhanhai

回复 146# trafguy
Hello!trafguy~
       关于你的疑惑，我想再阐述一下我的观点，首先我们要明白双活的定义，双活就是在两个数据中心同时有两份相同的数据并保证数据实时的同步，但凡有一点点不一样，或者你说的sharding那都不叫双活~如果你不是这样理解双活的，咱们就没必要再聊什么双活了~因为你的双活和我的双活根本就是两码事，对吧~~
       所以对于真正的双活来说，任何数据中心挂掉都不会影响我们的业务，任何数据中心的灾难发生及数据丢失都不会影响我们的正常交易并能够保证资金的安全，这才是真正的双活，上周阿里的专家来我们公司交流，按照他们的说法是，他们没有完全实现双活，所以造成了业务中断~
       这也是我一直在和bbjmmj争论的原因所在，也是为什么我一直在坚持双活需要强一致性的原因~~ 如果不强一致，那还算是双活吗？ 比如在A数据中心我取了10W，我的数据不能实时同步到B数据中心，然后A数据中心挂了，那是否意味着我在B数据中心的账号里钱没有少一分钱，再取10W块出来呢？
       在这里我只希望大家能够真正的理解双活的概念，淘宝是牛逼，这里我并没有要诋毁谁的意思，但是我们也要从我们看到的实际情况出发去探讨问题，对吧？不能淘宝说自己双活就双活了吧~~
   

fengzhanhai

回复 148# trafguy
呵呵，感谢你的认同~共同学习探讨