Chinaunix
标题: 异地多活实际可行性有多强？支付宝故障引热议 [打印本页]
作者: stay_sun 时间: 2015-05-28 09:08
标题: 异地多活实际可行性有多强？支付宝故障引热议
获奖名单已公布：http://bbs.chinaunix.net/thread-4180416-1-1.html
话题背景
支付宝昨天的杭州数据中心网络中断，支付宝紧急切换用户数据中心，关于支付宝的异地多活受到了大家的热议。
对于中间件层的异地多活，前边的数据监控流量分发等，做好监控分发就好；支付宝应对双11的能力我们也是有目共睹的。下面我们就支付宝自己开发的数据库oceanbase展开讨论。
首先说说银行和运营商，基本上银行和运营商用的是oracle，用存储层的复制技术或者oracle的复制技术达到强一致性，切换的风险很大。当你达到强一致性的情况下，你就得消耗性能，也就是钱。银行对这样的投资不在乎。但阿里肯定不会这样去做。所以就出现了阿里自己开发的oceanbase。
oceanbase 架构
客户端：用户使用OceanBase的方式和Mysql数据库完全相同，支持JDBC、C客户端访问，等等。基于Mysql数据库开发的应用程序、工具能够直接迁移到OceanBase。
RootServer：管理集群中的所有服务器，tablet数据分布以及副本管理。RootServer一般为一主一备，主备之间数据强同步。
UpdateServer：存储OceanBase系统的增量更新数据。UpdateServer一般为一主一备，主备之间可以配置不同的同步模式。部署时，UpdateServer进程和RootServer进程往往共用物理服务器。
ChunkServer：存储OceanBase系统的基准数据。基准数据一般存储两份或者三份，可配置。
MergeServer：接收并解析用户的SQL请求，经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者UpdateServer。如果请求的数据分布在多台ChunkServer上，MergeServer还需要对多台ChunkServer返回的结果进行合并。客户端和MergeServer之间采用原生的Mysql通信协议，Mysql客户端可以直接访问MergeServer。
OceanBase支持部署多个机房，每个机房部署一个包含RootServer、 MergeServer 、ChunkServer以及UpdateServer的完整OceanBase集群，每个集群由各自的RootServer负责数据划分、负载均衡，集群服务器管理等操作，集群之间数据同步通过主集群的主UpdateServer往备集群同步增量更新操作日志实现。客户端配置了多个集群的RootServer地址列表，使用者可以设置每个集群的流量分配比例，客户端根据这个比例将读写操作发往不同的集群。
讨论话题
1、支付宝如何在技术层面完成的异地多活？
2、异地多活的技术难点在哪里？
3、异地多活在生产环境中 你知道哪里在使用？
4、异地多活的风险性在哪里？
讨论时间
2015-05-28至2015-06-20
活动奖励
活动结束后将选取4名讨论精彩的童鞋，每人赠送《淘宝技术这十年》图书一本作为奖励。
奖品简介
作者： 子柳
出版社：电子工业出版社
出版日期：2013 年5月
开本：32开
页码：239
版次：1-1
内容简介
任何网站的发展都不是一蹴而就的。它在发展过程中会遇到各种各样的问题和业务带来的压力。正是这些问题和压力推动着技术的进步和发展，而技术的发展反过来又会促进业务的更大提升。如今淘宝网的流量排名已是全球前15名、国内前3名，其系统服务器也从一台发展到万台以上。
《淘宝技术这十年》从工程师的角度讲述淘宝这个超大规模互联网系统的成长历程，及其所有主动和被动的技术变革的前因后果。书中有幕后故事、产品经验、架构演进、技术启蒙，也有大牛成长、业内八卦、失败案例、励志故事。全书文风流畅，有技术人员特有的幽默感；内容积极正面，有现场感，全部是作者亲身经历。
样章试读
http://wenku.it168.com/d_001583162.shtml
购买链接
http://item.jd.com/11236743.html
关注CU官方微信“ChinaUnix”微博“ChinaUnix官方微博”
我们会及时为您公布最近活动的获奖名单以及最新的活动资讯，更多精彩内容，敬请期待。
作者: niao5929 时间: 2015-05-28 09:36
Ding顶起来吧，目前双活和多活属于高大上的玩意，相关技术细节比较少，不过数据中心肯定会向这个方向进化，这次支付宝的问题已经让我们看到了这种分布式系统带来的优点
作者: 刺客阿地 时间: 2015-05-28 11:14
好高端的话题。我来顶下，只求送图书徽章一枚。哈哈
作者: kooleon 时间: 2015-05-28 11:14
嗯，好活动。只是我不会啊 
作者: little_angel 时间: 2015-05-28 11:21
顶下哈~~~~~~~~~~~~~~~~~~~
作者: niao5929 时间: 2015-05-28 11:46
1，基础网络的建设问题
2，应用的热在线迁移问题
3，内部数据交换问题
4，数据一致性问题
个人觉得这些是数据中心网格化都需要考虑的
目前相关涉及到的技术个人觉得应该包括open stack docker SDN 以及网络在逻辑上的双螺旋结构研究
作者: ylky_2000 时间: 2015-05-28 11:46
这是个对 其中一条光缆中断后技术提升的一个机会。
什么多链路都失效了，之前腾讯也出现过类似问题。
那么问题来了，是腾讯和阿里的技术太差了？那么多的ccie和hcie搞不定这个在国内系统集成商口中很简单的问题？
作者: qingduo04 时间: 2015-05-28 11:46
雁过留音、支持一下...........
作者: ylky_2000 时间: 2015-05-28 11:48
就支付宝昨天断网事件，跟数据库无关。
解决链路冗余的问题就解决了，但是多链路又是那么好解决的吗？多拉了几根线就是多链路了吗？
作者: stay_sun 时间: 2015-05-28 11:52
回复 9# ylky_2000
这个东西不靠谱 你肯定要买运营商的光纤 你能保证这个东西 从哪里走的 成本 也接收不了 不可能走专线的
作者: ylky_2000 时间: 2015-05-28 11:58
stay_sun 发表于 2015-05-28 11:52 
回复 9# ylky_2000
这个东西不靠谱 你肯定要买运营商的光纤 你能保证这个东西 从哪里走的 成本 也接收 ...
不是可以多买几个运营商的吗？
买三个运营商的。
作者: stay_sun 时间: 2015-05-28 12:30
回复 11# ylky_2000
你是买了 运营商的 或者专网 但是管道 都是走在一起的 一挖掘机下去 就全断了
作者: zsszss0000 时间: 2015-05-28 12:47
这个问题，过于高大上了，帮顶。。。。。
作者: ylky_2000 时间: 2015-05-28 12:55
stay_sun 发表于 2015-05-28 12:30
回复 11# ylky_2000
运营商的管道是分开的。
作者: reyleon 时间: 2015-05-28 12:58
听都没听过, 凹凸了 
作者: forgaoqiang 时间: 2015-05-28 14:25
嗯 图书已经买了 也积极参与下吧
作者: heguangwu 时间: 2015-05-28 14:32
1、支付宝如何在技术层面完成的异地多活？
这我哪能知道，支付宝的人才知道啊，从公开的论文来看，估计和Google的方案一样
2、异地多活的技术难点在哪里？
技术层面异地双活方案这东西说难也难，说不难也不难，主要是既要时延和性能保证，又要数据安全保证，我能想到的就是Paxos算法实现
3、异地多活在生产环境中 你知道哪里在使用？
不清楚啊
4、异地多活的风险性在哪里？
数据不一致
作者: 我是歌手吗 时间: 2015-05-28 15:44
1、支付宝如何在技术层面完成的异地多活？
技术层面？不清楚，保证用户一次操作请求的数据中心一致性，保证各数据中心的数据同步的一致性，保证各数据中心互相备份的一致性。。主要就保证这几点的一致性吧，另外还有各数据中心骨干线路多元化吧。。
2、异地多活的技术难点在哪里？
数据同步？还有用户的路由问题吧 ，如何才能保证用户请求都分发到同一节点，前端分发？如果分发器都挂了呢。只能只能dns来做？
3、异地多活在生产环境中 你知道哪里在使用？
生产环境混迹小公司，异地多活不知道哪里在用。。。。
4、异地多活的风险性在哪里？
什么东西风险肯定有，比如数据一致性了，数据的写入正确性。。
。。
作者: wsysx 时间: 2015-05-28 16:14
只能说世界变化太快了，上午还都在议论支付宝的事，下午就被携程抢了风头
反正最后的结论就是管你什么互联网+，在蓝翔面前都只是战5渣
作者: hsxhost 时间: 2015-05-28 16:29
作为新手，重在学习
作者: hsxhost 时间: 2015-05-28 16:33
一般如果同城双中心，考虑双活或者叫连续可用性多一点，灾备的意义不大，特别是对于重大地域性灾害。
如果是双中心位于异地远距离，一般考虑灾备多一点，很少做双活，因为数据复制很难做到同步。
作者: hexilanlan 时间: 2015-05-28 18:17
顶起 ，围观
作者: lyhabc 时间: 2015-05-28 21:08
本帖最后由 lyhabc 于 2015-05-28 21:15 编辑
1、支付宝如何在技术层面完成的异地多活？
2、异地多活的技术难点在哪里？
3、异地多活在生产环境中 你知道哪里在使用？
4、异地多活的风险性在哪里？
一句话：摆设
还有，我十分不喜欢 阿里巴巴经常吹牛逼，BAT中A最喜欢吹牛逼
作者: niao5929 时间: 2015-05-28 23:18
这还没讨论结束，携程又出事了，比支付宝严重多了，运维面临很多新的挑战呐
作者: niao5929 时间: 2015-05-28 23:22
Google在美国可以自己到处拉光纤，天朝的政府允许某宝这么干嘛
作者: niao5929 时间: 2015-05-28 23:25
异地多活还是有意义的，故障期间部分客户受影响，携程可是直接挂掉了
作者: niao5929 时间: 2015-05-29 07:54
多活的概念应该不是仅限于数据中心层的，它应该成为计算细胞节点的基本功能，数据通路也应该进化为逻辑上的双螺旋结构
作者: action08 时间: 2015-05-29 08:56
送一本吧，这书比jd的要强一点
作者: skykufo 时间: 2015-05-29 09:17
自己发射卫星做物理多链路，看蓝翔还能不能搞它
作者: niao5929 时间: 2015-05-29 10:12
蓝翔可以把挖挖机开到月球上去
回复 29# skykufo
作者: heguangwu 时间: 2015-05-29 14:18
正所谓武功再高也怕菜刀，支付宝轻松被蓝翔干掉
作者: xkf01 时间: 2015-05-29 15:15
提示: 作者被禁止或删除 内容自动屏蔽
作者: ccfish86 时间: 2015-05-29 15:34
我觉得这东西，还是交给专业人士来搞，中小企业还是做好自己的业务。利用好公有云或私有云，还可以节省成本，降低技术风险。
作者: stay_sun 时间: 2015-05-29 15:47
这个技术都是大公司的核心技术你用云的话 他们也不会提供的
回复 33# ccfish86
作者: 蛮多肉 时间: 2015-05-29 16:25
在携程事件的帖子里看到楼主
一搜索,就发现这里也有贴,支付宝
作者: alanshen 时间: 2015-05-29 16:39
围观大牛们 。。。
作者: stay_sun 时间: 2015-05-29 17:00
回复 35# 蛮多肉
我就想蹭本书 我容易吗
作者: kingmuwp 时间: 2015-05-29 17:52
1、支付宝如何在技术层面完成的异地多活？
你问我，我问谁去。
2、异地多活的技术难点在哪里？
异地多活需要考虑2个层面的问题，一个是后端数据存储的异地多活，另一个是前端网络访问的异地多活。在非常大的数据交换前提下，保证数据一致性是一个极大的难点，不光要后端存储，服务器等硬件平台性能支撑，还要异地数据一致性的数据传输带宽足够大。淘宝这一次的所谓的蓝翔挖掘机直接就把业务搞瘫痪，只能说正好挖到负责网络转发的核心中间件的光缆了，并且该核心中间件可能没有冗余，也可能有（冗余心跳线缆也断了），切换出现异常。所有的用户访问都需要首先访问该核心网络中间件，然后负责分发到各地服务器、网络机房。
3、异地多活在生产环境中 你知道哪里在使用？
不差钱的四大行必然都使用了异地多活。
4、异地多活的风险性在哪里？
异地数据中心，数据出现一致性的问题导致数据库崩溃。
作者: bbjmmj 时间: 2015-05-29 21:59
回复 14# ylky_2000
楼上说得对，运营商的光缆都是在一起的，统一沿国道或者省道两侧埋设，如果国道拓宽，挖掘机野蛮操作，几个运营商的光缆会被同时切断。但同一条公路有正反两个走向，光缆也会因此有正反两个走向，同一座城市有多条公路，接入商选择合适的话，也就不用怕挖掘机了。
最好是租用光纤，自己用osfp搭建网格化去中心网络，这样就不用怕挖掘机了。阿里这次事故跟双活多活没关系，物理层的问题不应该影响到应用层，是它管理层有问题，电信光缆被挖了还有网通光缆，不应该切数据中心。
数据中心双活足矣，可以考虑无数据的网络多活。
作者: bbjmmj 时间: 2015-05-29 22:06
我老婆有三个结义姐妹，她们四个想凑到一起吃顿饭非常难，一年也就那么一两次机会，因为很难找到大家都有时间的时候，这就是强一致性的代价。多活需要强一致性，节点越多越难一致，尤其是异地远距离多节点的一致，光速是不可逾越的障碍。多活可行性不高，效能上远不如网络的链路冗余或者去中心的网格化拓扑结构。
作者: hx30067988 时间: 2015-05-31 06:19
本帖最后由 hx30067988 于 2015-05-31 10:16 编辑
二话不说先提取背景信息 oceanbase 架构
oceanbase 架构是一个数据库集群架构
由几个独立事物的角色服务器组成
客户端：前台应用服务器访问的工具，输出前台应用需求的SQL语句
RootServer：集群管理器，负责集群中管理问题，有主备，强同步，初步分析认为应为冷备份
UpdateServer：更新服务器，有主备，主备间可配置不同同步方式，认为应为热备份
ChunkServer：基准数据服务器，主查询用，两份，三份可配置及多负载模式
MergeServer：描述挺多，但核心作用应为高级负载均衡器，做分析调度。
集群之间数据同步通过主集群的主UpdateServer往备集群同步增量更新操作日志实现
在此感谢下华为，感谢前老板，2014年参加2014年华为云计算会议，了解并学习了双活数据中心方案并总结出以下双活要点。
双活数据中心状态主要有3种形式
正常状态：双方相互同步备份数据，负载，同时处理。
故障状态：错误出现，故障迁移，正在处理的未完成的数据回滚
恢复状态：重新同步，负载平衡数据
看淘宝故障问题
在这里我想感谢下运维2.0官方2号群里的伙伴们，谢谢你们的精彩分析,谢谢群主能让我加入群中学习
结合阿里的数据架构，以及我亲身的经历，我做一个比较大胆的推断
我作为淘宝ISV方的运维，亲历了阿里云这次故障，当故障发生时广东片区的用户出现了访问不了的情况，厦门本地是能够访问的，于是让让客户做路由跟踪，我方根据客户的IP地址做反向跟踪，发现问题节点出在杭州电信，当时的情况判定是电信的路由同步出现问题，丢失了广州地区的路由表。之后阿里云公布故障...
这次故障原因是因为光纤被挖断，物理链路层中断，导致电信路由表重新动态同步，路由表重新同步丢失大部分网段路由，去往广东链路大部分不通。
支付宝平台出现问题又没有快速修复，经过运维2.0官方2号群里的讨论学习，我认为问题出现在数据同步异常的可能性很大，由于集群间的数据同步不经过集群控制器，直接与集群间进行进行同步数据，而问题的实质是链路部分不通，导致故障问题被扩大化，简单的说就是半死不活的状态影响到了整个集群的使用，这个时候故障的问题就很纠结了。服务器不知道如何处理了，可能就按直接丢弃或什么方式处理掉了，导致部分用户使用不了支付宝业务。修复这个故障需要时间，所以这个问题一拖就是几小时，要么是平台出补丁，要么是电信修复缺失路由表，要么是恢复光纤。
回到问题
1、支付宝如何在技术层面完成的异地多活？
结合双活数据中心的三种状态，以及阿里oceanbase的特点分析，在技术层面上，阿里通过主控服务器，更新服务器，基准查询服务器，以及高级负载均衡器角色的划分，将数据处理的过程模块化，（这种模式的数据管理模式，很像配置管理的模式）通过不同的分工，把事物具体到专门的服务器上，服务器间通过消息协同处理完成整体的数据管理。
通过分布式系统间的消息同步，完成从正常状态-故障状态-恢复状态的转换，实现异地多活。
2、异地多活的技术难点在哪里？
异地多活的技术难点应该在数据同步问题上。
首先是同步的时效性，数据库同步需要低延迟的同步时效，延迟级别毫秒级，这是一个很总要的一个环节，华为异地多活地域公里数的限制就是在延迟上。
其次同步算法的处理上。这期间负载算法如何处理？如何将需求处理数据投递到正确的服务器上去。我认为这方面应该参考更多的路由算法，路由协议在这方面已经有很多成熟的方案成果了。
再次故障的隔离性，如何将故障进行隔离，保障故障不会因为一个小的问题影响到整体系统的使用。
最后通讯管道的高可活性，像这次情况如何建立除专线以外的高可用安全通道？保障数据同步安全。
3、异地多活在生产环境中 你知道哪里在使用？
目前我了解的情况不多，阿里平台是一个，其他的没有亲身经历过不好说，可以参见华为的双活数据中心案例
4、异地多活的风险性在哪里？
异地多活能解决故障后无处理的问题，从业务使用这个角度上说异地多活是百利而无一害的，但从安全和管理角度上看，异地多活增加了数据入侵点的风险，增加了事物处理的过程增加了管理难度，如果自动化不够成熟将导致人为错误的发生。
以上是近期阿里故障的一些思考总结，如有不正确的地方请严厉批评，我加以改进
作者: ylky_2000 时间: 2015-05-31 16:41
对一个总分机构，如何去中心化？重要服务器一般都集中在总部。
bbjmmj 发表于 2015-05-29 21:59
回复 14# ylky_2000
作者: hx30067988 时间: 2015-05-31 21:16
本帖最后由 hx30067988 于 2015-05-31 21:21 编辑
回复 43# ylky_2000
这个是不是应该要看公司的具体业务来定？如果公司认为有必要去中心化，那可以尝试NOSQL数据库，如果公司认为没必要，放在一起更安全那样的话一切都没有意义了...
作者: bbjmmj 时间: 2015-05-31 21:41
ylky_2000 发表于 2015-05-31 16:41
对一个总分机构，如何去中心化？重要服务器一般都集中在总部。
可以参考美国陆军战术网络的做法，虽然指挥系统在中心，但其网络却是无中心的，允许部分损坏。
网络切一下，用户刷新一下页面就过来了，但数据中心切一下，用户得等数据同步和路由表更新，两者效率有天壤之别。
作者: lemoncandy 时间: 2015-05-31 23:04
bbjmmj 发表于 2015-05-31 21:41
可以参考美国陆军战术网络的做法，虽然指挥系统在中心，但其网络却是无中心的，允许部分损坏。
网络切 ...
围观bbjmmj大神啊，最近闺女靠大学了吧？
作者: bbjmmj 时间: 2015-05-31 23:37
回复 46# lemoncandy
明年高考。
作者: fengzhanhai 时间: 2015-06-01 22:11
回复 1# stay_sun
异地多活的难点在于数据的同步，就单纯的web站点而讲没有任何技术性的问题，其实现起来也相对简单，但是对于实时交易系统而言就目前的技术而言还无法做到真正的异地多活，就像支付宝的这次事件也能佐证，阿里的技术的确很牛，但是也有水分在里面，淘宝的大牛们在外边吹的太大了，这次真是打到脸上了。若支付真的实现了多活，不会中断这么长时间的，最短也就是毫秒将线上用户引流到其他数据中心，但是让我失望的是支付宝我登录了1个小时都没登陆上。
就支付宝的交易系统而言如果真的实现了多活，是不可能有用户感知因某一机房的故障导致支付宝无法使用的，从此次事件也能看出，其实支付宝对于区域用户来讲就是一个单点系统而已
作者: niao5929 时间: 2015-06-01 23:06
我们设想的所有双机及集群系统都是基于一个整体的方案思考的，也就是从上到下模式思考的，这样的结构第一浪费了部分计算能力，二这个结构本身依然还是不确定的，总有一些问题是我们设计考虑不到的，因为我们无法在设计中包含未来所有的情况(那些情况只有在出现之后人们才能知道它的存在)。我们是否可以更换一个视角以从下到上的角度重新来思考集群以及网格计算呢，也许它能给我们不少帮助，最少它可以让我们对集群有一个新的思考/:
/:
作者: lemoncandy 时间: 2015-06-01 23:29
fengzhanhai 发表于 2015-06-01 22:11
回复 1# stay_sun
异地多活的难点在于数据的同步，就单纯的web站点而讲没有任何技术性的问题，其实现起来 ...
现在看来，互联网多活就是个笑话了吧？
要是银行出这样的故障，那是要被罚款很多的把？
作者: niao5929 时间: 2015-06-01 23:30
美军这种去中心网络好像只有报道说他们在研究，百度叫的网状网，也是基本的简述，仅此而已
作者: stay_sun 时间: 2015-06-02 09:24
回复 50# lemoncandy
阿里做的已经很牛逼了 银行俩个小时不一定恢复的
作者: beyondfly 时间: 2015-06-02 10:19
这本书看过了，还不错
作者: bbjmmj 时间: 2015-06-02 11:43
niao5929 发表于 2015-06-01 23:30
美军这种去中心网络好像只有报道说他们在研究，百度叫的网状网，也是基本的简述，仅此而已
晕～我看到的是二十年前的资料，美国陆军战术通信系统，好像叫MSE什么的，总参部编的，这种战术网络当时已经开始装备了。
作者: niao5929 时间: 2015-06-02 11:45
好像没有技术细节的讨论内容吧。呵呵回复 54# bbjmmj
作者: bbjmmj 时间: 2015-06-02 11:50
回复 55# niao5929
技术细节相当多，每个节点的配置、架设、人员配置，都讲得很详细，甚至连防空、吃饭这样的配套设施都讲了。
作者: niao5929 时间: 2015-06-02 11:59
回头让我参阅下吧。谢谢回复 56# bbjmmj
作者: bbjmmj 时间: 2015-06-02 12:06
异地多活跟异地双活是完全不同的技术。异地双活一般是基于存储复制和redo log的，切换风险很高。而异地多活是基于前端代理的，前端代理解析用户请求并把请求分发给后端数据库某些节点。
技术角度讲异地多活不仅可以实现，而且可靠性与异地双活相比有天壤之别，缺点也是很明显的，耗费人工比较多。
异地多活的实现，我认为最主要的障碍还是在傻逼管理层。维稳思维同样侵蚀着互联网企业，创新有风险，基层人员可能因为创新导致企业损失，谁会承担“责任”呢？当然他上面的领导不希望自己承担责任，创新的人有极高可能性因此丢掉饭碗。管理层抱着不求有功但求无过的态度会不断打压基层创新，为什么管理层惧怕创新呢？很明显创新会动很多人的饭碗，这是个很得罪人且容易丢饭碗的事。这些都是管理上而非技术上的问题。
国内缺乏创新，归根结底还是管理上太垃圾了，如果谁对这个说法不服，那我问你，贵公司怎么奖励创新？创新造成公司损失，贵司怎么处理？最后你会发现自己所在的公司根本就没打算激励创新，对创新都是清一色的打压。
作者: bbjmmj 时间: 2015-06-02 12:07
回复 50# lemoncandy
这种事如果发生在银行，只要数据不丢，不会有任何人被处罚。
作者: bbjmmj 时间: 2015-06-02 12:08
niao5929 发表于 2015-06-02 11:59
回头让我参阅下吧。谢谢回复 56# bbjmmj
我也很想再找到那本资料，也不知放哪去了。
作者: stay_sun 时间: 2015-06-02 12:46
回复 58# bbjmmj
你得看下 cap 理论了 很简单 前端代理的话 分发给不同的数据库 在mysql 是有的 而且 阿里已经对他进行了二次开发 用在淘宝网数据库
但是一致性达不到要求。 你分发到不同的数据库 俩条语句提交都成功了 还是提交到一个 数据库算事务完成。 当你多个数据库成功后才算提交完成。
你的性能又如何。当你去修改数据 数据库不一致 你的效率会很低的。 这种架构适合的是单机房的部署。不能做多活的
阿里既然有了分布式 drds 可以做到 多活 光纤断了 淘宝没有问题 就是因为这个
淘宝可以 2000 库存 卖出 3000件 补货被 大不了退款
但是支付宝呢
作者: bbjmmj 时间: 2015-06-02 13:19
stay_sun 发表于 2015-06-02 12:46
回复 58# bbjmmj
你得看下 cap 理论了 很简单 前端代理的话 分发给不同的数据库 在mysql 是有的 ...
不用非得强迫保持一致，只要不发生错误就可以了。没有任何电脑系统不能容忍停机，但不能容忍数据丢失却很常见，不能为了稳定就把一切都压倒。 不是理论错了，而是我们用错了理论，CAP是集中式系统理论，不适用分布式系统。
我说的代理MYSQL上是没有的，它是前端服务器上跑的东西，它把请求调度到不同的服务器，不会要求其它服务器同时记录或者处理这些请求，任何数据都是在局部处理，不对全局产生影响，因此不需要一致性，这也是双活和多活有天壤之别的原因所在，它俩完全不是一个东西，不可同日而语。
作者: stay_sun 时间: 2015-06-02 13:29
回复 62# bbjmmj
你说的 只不过是分发 直接拿lb 做转发可好 可是数据 怎么办 这个范围太大了 只不过是一个想法 落地太难了
作者: stay_sun 时间: 2015-06-02 13:32
回复 62# bbjmmj
感觉你考虑的 东西也太少了 基本上的想法 就是阿里的 分布式 mysql 数据库 drds
作者: bbjmmj 时间: 2015-06-02 14:01
stay_sun 发表于 2015-06-02 13:32
回复 62# bbjmmj
你说互联网会要求所有电脑一致么？这就是分布式系统和集中式系统的区别所在。现实中的一致性都是有条件的，局部的，个别的，那么数据库一致性为什么要违背人伦呢？？？
问题的关键是对分布式的理解，国内没有分布式系统概念，他们的思维仍然停留在集中式系统里。
想得不在多少，而是看想没想对地方，想错了地方就会永远在错误里绕圈子。
作者: niao5929 时间: 2015-06-02 14:21
得罪领导的话不好。呵呵回复 58# bbjmmj
作者: bbjmmj 时间: 2015-06-02 14:26
回复 66# niao5929
如果把全局一致降低为局部一致，多活就可以实现了，比如对用户ID进行HASH，HASH到不同的数据库节点，这样同一个用户的数据就不用存得到处都是，这里没有全局的一致，就是众多的局部一致。
多活的难题在管理，多个数据中心就得配多个领导班子，吃闲饭的太多了，多活要求企业管理先实现扁平化，很多领导饭碗都会被……嗯~嗯~
不是技术问题，是行政问题，这是我最终的看法。
作者: stay_sun 时间: 2015-06-02 15:30
回复 67# bbjmmj
你做了哈希桶 最后没有分布式 你这个只是做了分库分表 如果你把 这样的 数据库 放在不同机房中 你访问 时候 跨机房 跨地域 这个延迟 系统一般接受不了 对于容灾也没有
阿里的挖光纤 你怎么解决
作者: bbjmmj 时间: 2015-06-02 17:31
stay_sun 发表于 2015-06-02 15:30
回复 67# bbjmmj
首先，WEB用户对延迟不敏感，他们能容忍秒级延迟。
第二，同一个WEB用户同一时间段内发起的交易数量非常有限。
第三，可以在WEB用户发起第一个交易的时候，从远端把用户数据整块捞取到当地服务器上，本地服务器上指定时间内数据不变，再把数据迁出到远端。
只要不是强一致性依赖，延迟就不是问题。
作者: bbjmmj 时间: 2015-06-02 17:54
stay_sun 发表于 2015-06-02 15:30
回复 67# bbjmmj
量化分析更能说清楚问题。
淘宝双十一完成一亿笔订单，我们可以据此计算出它需要的最大吞吐能力大约是每秒一万笔订单，如果由十台数据库服务器处理，每台平均每秒一千笔订单，我认为普通X86服务器足可胜任这样的负荷，分库之后，负荷问题也就解决了。
临时的数据迁移并不需要迁移到每个地级市，迁移到每个省就可以了，数据迁移的范围和数量非常有限，核心系统有能力承载，尤其是分库之后。
作者: fengzhanhai 时间: 2015-06-03 09:13
回复 50# lemoncandy
不是罚款的问题，要看影响面有多大，更多负面影响是对金融机构的商誉和客户信心的重大打击~其实对于金融机构来讲，若发生此类事件，更多的压力来自监管机构和储户，若发生数据丢失，严重的可能会导致停业整顿甚至破产~
当然破产此类问题，目前在国内的金融行业不太可能发生，因为每一家银行都是由政府背景的，包括所谓的民营银行~~
作者: minicooperrrm 时间: 2015-06-03 10:08
好话题，顶一下
作者: stay_sun 时间: 2015-06-03 10:13
回复 70# bbjmmj
淘宝的秒杀 最后落库到 杭州数据库才算 完成交易
作者: mike79 时间: 2015-06-03 13:14
回复 64# stay_sun
不要和bj大神讨论技术问题，他是生活在异次元空间的。你所考虑的那些问题，在他的次元空间中是不存在的。
作者: bbjmmj 时间: 2015-06-03 14:14
回复 74# mike79
我的观点业界要三到五年以后才会认同，不是我先进，是大家天天接触高大上，而高大上为了“可靠”采用的都是落后的技术，所以，实际上你是活在过去而不是我活在未来。
作者: bbjmmj 时间: 2015-06-03 14:22
stay_sun 发表于 2015-06-03 10:13
回复 70# bbjmmj
没关系，WEB用户能容忍秒级延迟，1秒钟已经足够数据落户到国内任何数据中心了。
我在存储版发了个DRBD的帖子，如果采用并行传输，同步复制的距离即使拓展到一千公里，速度仍然足够满足多数服务器的需要。
估计国内做灾备的没人会想到并行传输，并行传输不是提高了光速，而是让操作系统的IO平均等待时间降低从而降低同步复制延迟。
我考虑并行复制的原因不是为了增加灾备距离，而是降低交易延迟，都是很简单的技术，新手不难掌握。
作者: stay_sun 时间: 2015-06-03 14:37
回复 74# mike79
我觉得也是 我去参加过阿里的座谈 跟沈荀 聊过他的分布式数据库。。 还是很牛逼 他们用了五年的时间 一个团队来开发这个东西 最后都觉得 不适合支付包的环境
异想天开的就觉得 自己设计一个模型可能吗
作者: bbjmmj 时间: 2015-06-03 16:39
stay_sun 发表于 2015-06-03 14:37
回复 74# mike79
呵呵，你知道异想天开和创新的区别吗？很容易混淆的。 如果异想天开是基于成熟的技术应用，那就是科技创新。
国内IT行业创新能力差得很，他们不敢创新都是同一个理由：别人没用，所以我们也不能用。典型羊群效应受害者。
作者: bbjmmj 时间: 2015-06-03 16:51
这次支付宝事故，据说是挖断光缆，导致路由表出了问题，最终迫使他们切换数据中心，此消息不知是否属实。我总觉得公网上断了一条光缆不至于迫使支付宝切换数据中心。
多活不同于双活，后者多数走裸光纤，前者恐怕要用到公网，公网上每一级路由/交换机上都会有延迟，而电信商又不肯给你高优先级，这个时候延迟就相当大了，同步会更困难。
作者: bbjmmj 时间: 2015-06-03 18:32
我有过一次不尽职。
当年学校要盖宿舍楼，校园里有联通井盖子，有几个井盖子连线直指宿舍楼施工地，最近的井盖子离宿舍楼仅十几米远，而且我看过联通的人在管道井里施工，井不深，半人深的样子，盖楼要挖地基，很大可能会挖断联通光缆，而我们用的正是联通光纤。我知道光缆可能会被挖断，但是这事不归我管，所以也就没有理会。直到有一天，领导打电话说断网了，问我是不是我服务器的问题，我说可能是光缆被挖断了，当时正是周日晚上，周一早上上班一看，果然光缆被挖断了。
作为支付宝的网管，他应该知道骨干光缆的走向，南下的走沿海大城市，一旦杭州、宁波、温州方向光缆被挖断，会有很大区域无法使用支付宝，这是可以预见的事故。个人认为省会城市之间应该至少有两条地理位置不同的光缆线路，他可以跟电信商协商让数据走两条线路，阿里是大企业，做这个公关不会有难度，所以我很难理解挖断一根光缆就造成那么大的影响。
作者: mike79 时间: 2015-06-03 22:04
本帖最后由 mike79 于 2015-06-03 22:06 编辑
回复 77# stay_sun
涉及到钱这些强一致性要求的场合，分布式不太适用
PS bj大神擅长把一些概念混杂在一起讲，很有“民科”的潜质。
作者: bbjmmj 时间: 2015-06-03 23:28
你理解的那个概念是分布式系统的一个特例，叫mesh网格，不是所有分布式系统都得做成mesh网格，包括跟钱有关系的系统。跟钱有关系的系统并不需要强一致，需要的是不丢数据，需要强一致的是你，因为你想不到别的办法确保数据不丢。你好好琢磨琢磨吧，你说的概念没错，但你可能用错了地方。
作者: bbjmmj 时间: 2015-06-03 23:42
概念是空洞的，还是结合实际吧。
银行灾备是不是你想象的强一致?我告诉你那不是强一致，只能叫弱一致，业务切换风险很大，切换的时候很容易丢数据，所幸操作系统和数据库系统都有纠错能力，多数时候都可以成功切换。理论上集中式系统就是个单点系统，不具备和其它系统强一致的能力。实现强一致必须得有仲裁系统才行，双活系统肯定不是强一致的。我怀疑你学的知识有问题。
作者: bbjmmj 时间: 2015-06-04 00:03
mike79 发表于 2015-06-03 22:04
回复 77# stay_sun
涉及到钱这些强一致性要求的场合，分布式不太适用
说到强一致，一个典型的例子就是RAID1，同一个数据块被分别写入两块硬盘，读的时候，由控制器决定采用哪块盘上的数据，这里面控制器就扮演着仲裁者的角色。强一致系统至少需要三个节点，所以双活系统肯定不是强一致。现实生产环境中经常能遇到“脑裂”，这就是双活系统无法保持强一致最有力的证明。
我前面说的代理要决定数据从哪个节点读，写到哪个节点，以及采用哪个节点的数据，此时代理相当于调度器+仲裁器，正是因为要实现强一致，才有必要采用分布式而非集中式结构。
脱离实际，概念就成了纸上谈兵。概念背对了却用错了地方，会害死一大群人的。
作者: stay_sun 时间: 2015-06-04 09:19
回复 81# mike79
人家是做理论的 考虑的东西不一样
作者: mike79 时间: 2015-06-04 11:41
回复 85# stay_sun
做理论的至少会懂得CAP。支付宝断网事件就是CAP发挥作用了。
作者: bbjmmj 时间: 2015-06-04 13:05
stay_sun 发表于 2015-06-04 09:19
回复 81# mike79
人家是做理论的 考虑的东西不一样
你一会说我概念混淆一会又说我是做理论的，从一个极端到另一个极端。
作者: bbjmmj 时间: 2015-06-04 13:08
mike79 发表于 2015-06-04 11:41
回复 85# stay_sun
做理论的至少会懂得CAP。支付宝断网事件就是CAP发挥作用了。
算了吧，吹CAP这么多年，事故还少吗？从911到国内各大银行，出了多少事？
作者: wwwsq 时间: 2015-06-04 17:09
bbjmmj 发表于 2015-06-04 13:08
算了吧，吹CAP这么多年，事故还少吗？从911到国内各大银行，出了多少事？
CAP没什么用。整天抱着CAP的话，日子也不要过了。如何折衷裁剪才是重要的。CAP在理论上有点用处，在实践当中CAP理论没什么用。
CAP等于说‘便宜没好货’，但这是一句废话。我们需要知道的是如何花恰当的钱，用恰当的方法，达到最好的效果。
作者: bbjmmj 时间: 2015-06-05 10:04
言归正传吧，我觉得支付宝搞OCEANBASE是一条错路，正路是开发中间层，前端通过中间层提供的接口操作后端数据库，中间层提供调度、一致性和容错保障。
最好是能做到前端代码和后端数据库厂家无关，这种接口开发一次能用几十年。
建议OCEANBASE开发人员用用微软的VB，二十年前开始流行的一种很不上档次的编程工具，通过这个工具，很容易认识到中间层的好处：不依赖特定数据库。依赖本身就是一种不可靠。
作者: bbjmmj 时间: 2015-06-05 12:15
多活的可行性可以从现实层面考虑。
想象一个巨大的批发市场，几十万个不同卖家经营的柜台，几千个收银台，这种情况下，因为资金在不停地流转，甚至很多资金处于流转的途中，还没有来得及转到财务部门手中，就不能进行即时处理，如果集中管理这些资金的话，还得需要一个非常庞大得财务部门，这就是支付宝的难处，所以集中是很困难的。
分布反而可以使得交易资金管理更容易。收银台负责收银，收银后通知柜台给客户拿货，客户拿到货通知收银台，收银台再把钱转给柜台。这种交易根本就不需要支付宝，有网银就足够了，收银台之间不需要一致，甚至批发市场的财务部门不需要知道收银台收了多少现金，没有全局一致性的麻烦，但是……
客户支付费用后不会马上给柜台，而是先在收银台存几天，然后再支付给柜台，这样就会形成一个资金池，收银台、客户、柜台都很多的时候，会形成一个巨大稳定的资金池，支付宝的这个资金池可能有数额高达千亿元的资金，这么多的资金可以拿去做金融业务再赚一笔钱，而收银台还可以收取柜台的手续费，所以支付宝必须得存在，它是个很赚钱的东西，是阿里的主要获利工具。
收银台存太多的现金是没用的，它需要把现金交给批发市场的财务部门进行管理，或者存入批发市场的金库，支付宝实际上是用来操纵这些代为保管的现金的，并不需要参与客户与卖家之间的交易。
淘宝的业务先天就是个分布式的业务，只要在用户申请ID的时候把用户分配到指定的收银台即可实现分布式交易，收银台的数量可以很大，地理上可以分散到全国很多地方，或者同一个数据中心的多台服务器上，整个交易系统有很强的吞吐能力。因为并不需要全局性的一致，收银台不需要了解支付宝资金情况，而支付宝也不需要干预每一笔交易。
大道至简。
作者: bbjmmj 时间: 2015-06-06 00:16
ylky_2000 发表于 2015-05-28 11:46
那么问题来了，是腾讯和阿里的技术太差了？那么多的ccie和hcie搞不定这个在国内系统集成商口中很简单的问题？.
什么IE都用不着，骨干网络用INFINIBAND，杭州、宁波、温州三地，放三台INFINIBAND交换机，用裸光纤两两相连就不怕刨光缆了，基本上是零设置。数据中心可以放在任何一座城市，如果是双活的，选两个城市安置数据中心就可以了。
双活也好，多活也好，想同步，最好别让数据走IP网络，设备延迟实在太高了，同步时间会很久。数据同步用多数据流并行复制可以大大降低海量数据同步时间，因为操作系统等待数据块IO的平均时间降低了。
作者: bbjmmj 时间: 2015-06-07 17:32
个人认为支付宝异地多活只能用INFINIBAND+裸光纤+Mysql半同步复制+DRBD的方案，其它方案似乎都不太可行。不是钱的问题，其它手段效能不如这个方案。也不是技术问题，这些都是阿里技术人员玩烂的东西。我觉得最后还是管理层问题，技术主管有没有魄力上这个东西，别人没有用，你敢不敢用，你敢不敢冒做不成羊的风险去做狼。
作者: lemoncandy 时间: 2015-06-07 22:14
bbjmmj 发表于 2015-06-06 00:16
什么IE都用不着，骨干网络用INFINIBAND，杭州、宁波、温州三地，放三台INFINIBAND交换机，用裸光纤两两相 ...
大神，我就是来拜拜你！
作者: lemoncandy 时间: 2015-06-07 22:16
fengzhanhai 发表于 2015-06-03 09:13
回复 50# lemoncandy
不是罚款的问题，要看影响面有多大，更多负面影响是对金融机构的商誉和客户信心的重 ...
阿里的支付宝，也是有背景的吧
作者: fengzhanhai 时间: 2015-06-08 12:00
回复 93# bbjmmj
多活不是说仅仅靠两根裸光缆就能搞定的，目前来说多活还局限于当前的技术不够成熟，无法解决现有问题且底层链路因距离产生的传输延迟是最大的障碍~而对于一个交易性站点来讲，这也恰恰是其最亟需解决的问题之一~~抛开这一点去谈一个实时交易站点实现了异地多活感觉有点搞笑~ 问问阿里是否真的能实现亚洲和欧洲的数据中心异地多活
作者: fengzhanhai 时间: 2015-06-08 12:08
回复 62# bbjmmj
感觉你说的不对，对于整个淘宝来讲它的确要求的是最终一致性，但对于支付宝来讲他要求的是强一致性和实时性，对于这一点我支持@stay_sun的观点，不知道你考虑过如果没有强一致性，支付宝将会发生什么
作者: fengzhanhai 时间: 2015-06-08 12:10
回复 61# stay_sun
支持你的观点
bj理解有偏差
作者: bbjmmj 时间: 2015-06-08 12:12
fengzhanhai 发表于 2015-06-08 12:00
回复 93# bbjmmj
多活不是说仅仅靠两根裸光缆就能搞定的，目前来说多活还局限于当前的技术不够成熟，无法 ...
我在家PING百度差不多要30多毫秒，30多毫秒电磁波可以走一万公里，而我家离北京的距离才几百公里，延迟主要在IP交换机和路由器上，传输距离的影响是次要的。
距离远可以用中继的方式解决延迟问题，主要难题在于把核心网络改为二层传输。核心网络才是最大的瓶颈，距离不是。
作者: stay_sun 时间: 2015-06-08 12:19
回复 99# fengzhanhai
谢谢支持 我也是特意查了资料 看了阿里专家的意见
作者: bbjmmj 时间: 2015-06-08 12:24
fengzhanhai 发表于 2015-06-08 12:08
回复 62# bbjmmj
感觉你说的不对，对于整个淘宝来讲它的确要求的是最终一致性，但对于支付宝来讲他要求的 ...
两笔错误的交易，即使是强一致的，也是不被允许的。交易需要的是正确性，跟一致性没有必然联系。
| 欢迎光临 Chinaunix (http://bbs.chinaunix.net/) |
Powered by Discuz! X3.2 |