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

wwwsq

fengzhanhai 发表于 2015-06-08 17:28
回复 111# bbjmmj
你必须要承认一个问题，对于支付宝这个系统是一个实时性的OLTP系统，而非你说的最终一致 ...

消息队列总体上来说是个谎言，你以为它承诺了什么，其实它什么也没承诺。

bbjmmj

wwwsq 发表于 2015-06-10 13:18
阿里早就建了自己的骨干网。

但是它还没有胆量用INFINIBAND做骨干。
阿里的网管我们不能太高看他，断网就切数据中心么？有东西未必就能用得好。

bbjmmj

wwwsq 发表于 2015-06-10 13:06
我可以很肯定的说，支付宝没有实现强一致性。一定是裁剪过的相对一致性，在可以承受的范围内允许数据 ...

这个绝对可以肯定，淘宝秒杀，都能下单，但是最早付款成功的那个人才能买走那唯一一件商品。可以允许一定的不一致。
银行也不是强一致的，要不怎么有“冲账”这个活儿呢。
要看业务流程了。

bbjmmj

回复 130# wwwsq


    一致性不难实现，每种商品的数量就是个信号锁，下单的时候这个值减一再读出，如果大于等于零就可以提交订单，如果小于零就加一，等待若干毫秒再减一读出进行尝试，尝试三遍不成就放弃下单。好像可以不用任何锁。

stay_sun

回复 126# bbjmmj


    阿里的团队 哪里都有  杭州 只是一部分  马上阿里在 望京建了 一个大楼

wwwsq

bbjmmj 发表于 2015-06-10 14:08
回复 130# wwwsq

http://en.wikipedia.org/wiki/Consistency_model

取决于你说的是哪种一致性。如果是strict consistency那有点难吧？

bbjmmj

wwwsq 发表于 2015-06-10 17:53
http://en.wikipedia.org/wiki/Consistency_model

取决于你说的是哪种一致性。如果是strict consi ...

电子交易跟一致性没有必然联系，电子交易需要的是数据不丢不错，要求一致的是你，你没办法保证不丢不错，只能拿几份相同的数据糊弄，就像三人成虎。
理论是可以向现实妥协的，比如人们常说：理论上讲如何如何如何，其实理论上描述的场景在现实中根本就是不会存在的。
银行灾备都会丢数据，过度吹嘘理论是主因。

bbjmmj

wwwsq 发表于 2015-06-10 17:53
http://en.wikipedia.org/wiki/Consistency_model

取决于你说的是哪种一致性。如果是strict consi ...

其实根本不需要让技术去附庸理论，做过网站，就会明白电子交易原理。

bbjmmj

继续聊多活。
前面提到一个MYSQL半同步，半同步状态下，有一路SLAVE跟上了，MASTER就会继续后面的步骤，也就是去执行事务。我琢磨这么做不够完美，因为没有冗余，中间可能会出错，比如这个抢先同步的SLAVE出了故障，而其它SALVE却还没有来得及同步，这个时候就可能会丢数据，所以我翻了翻源码，觉得可以对半同步流程做点小改动。
我用的是MARIADB，CENTOS7上带的是5.5.41，我看的也是5.5.41源码。
用int ReplSemiSyncMaster::reportReplyBinlog函数里的can_release_threads做计数器，布尔型，改成初值为零的整形，后面if (cmp >= 0) can_release_threads = true改成if (cmp >= 0) can_release_threads++，然后判断can_release_threads 是不是大于等于2，是则wait_file_name_inited_ = false，再往后if (can_release_threads)改成if (can_release_threads >=2)，这个2就是达到同步的SLAVE数量，我觉得2路就够了，觉得不够可以改成3，或者更多。
我自己没试，只是说了一个想法。

涉及到的代码在mariadb-5.5.41/plugin/semisync/semisync_master.cc文件里。前面回帖说到一致性，来了点灵感，两份一样的数据比较让人放心。

bbjmmj

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