查看: 10478|回复: 74
【话题讨论】如果让淘宝去卖火车票?——“双十一”背后的技术讨论
论坛徽章:25
获奖名单如下：
sheep_yang678
& &&&11.11光棍节已经过去了，各大电商的价格战接近尾声，作为一名技术人员，也见证了不同的架构在面对如此高并发的情况下的处理能力。在这种商战中，重点关注的是淘宝，今年也是公布去OIE以来的第一次面对如此大的访问量。
& && &双11一天时间，支付宝核心数据库集群处理了41亿个事务，执行285亿次SQL，生成15TB日志，访问1931亿次内存数据块，13亿个物理读。最核心的MySQL集群一天支持了20亿个事务。
& && &淘宝双11头一分钟内千万级别访问量，购物车和支付宝无法访问。可见一致性这个事在面对高并发时的困难。不过，淘宝通过调整服务器资源配置，通过throtle流量的方式（拒绝用户）让系统稳定，可见淘宝运维能力很强。系统运维是架构设计的重中之重。
& && &数据库又一次蛋定地顶住了，容量分析到位，预防措施到位，核心数据库顶住了每秒十万的事务，百万的SQL执行。
讨论话题：
& && &1、支付宝核心数据库集群如此的处理能力，作为技术人员，请谈谈自己的感想。
& && &2、淘宝已经开始转向开源系统了，而且已经经过了高并发的验证。在大数据时代下，是不是会有更多的互联网公司转向开源，在互联网行业准备做Oracle DBA的同学，是否意味着就业机会越来越少，该怎么办？
& && &3、在感概如此威猛的集群处理能力同时，不得不提起蛋疼的12306，在业务复杂性和巅峰时间的负载比淘宝大促低很多的情况下，12306每次都扛不住，支付宝订单数超过一亿，而12306最高一天出票量大约是166万。问题会出现在什么地方？
& && &4、你所负责的数据库，最高的事务数每秒达到多少？你是否考虑过如果一分钟内千万级别访问量压倒你所访问的数据库上，你如何去应对？是采用RAC还是采用mysql集群，还是用Oracle Exadata？
& && &5、 淘宝运维部门在这次突然爆发高并发的快速处理能力起到很重要的作用。作为DBA,我们自己的团队是不是也具备这种能力？你平时是如何去部署预期高并发的预案？
活动时间：——
活动奖励：针对以上任意一个问题跟帖回答，我们会在讨论结束后，随机抽选讨论最积极的3名网友赠送《Oracle DBA手记3：数据库性能优化与内部原理解析》这本书作为奖励。这本书的数量有限请大家抓住宝贵的机会哦~~~
求职 : 论坛徽章:10
本帖最后由 sheep_yang678 于
11:26 编辑
1、作为一个技术人员，面对强大的淘宝及支付宝系统数据库处理能力，我唯一的感想就是：教练，我想进去学习一下。2、这个得看oracle对mysql的收费情况了，目测鸭梨不大。
3、12306采用weblogic+oracle+hibernate的方式实现，但在设备选型上oracle的exadata、exalogic全面出局（好像是这样），另外系统以前还有SQL注入的BUG（某人在论坛上发的贴），说明开发以及系统集成上面经验不足架构设计以及开发能力肯定不过关。另外从设备选型方面看，钱肯定是被黑掉了很多，当然你也可以喷我说别的东西好。（这段请无视）
4、我负责的数据库？每天归档还没过T呢，小库，大型负载进行肯定不成，一个3节点的RAC肯定扛不住很高的访问，换exadata是我的首选。
5、我的团队？一个人也可以叫团队咩？
论坛徽章:25
sheep_yang678 发表于
先抢沙发再编辑
好同学 哈哈哈 &&感谢积极参与我们的活动哦
求职 : 论坛徽章:10
小豆呐呐 发表于
好同学 哈哈哈& &感谢积极参与我们的活动哦
认证徽章论坛徽章:86
sheep_yang678 发表于
1、作为一个技术人员，面对强大的淘宝及支付宝系统数据库处理能力，我唯一的感想就是：教练，我想进去学习一 ...
一个人的团队叫扛把子，台柱子
认证徽章论坛徽章:764
buptdream 发表于
一个人的团队叫扛把子，台柱子
感觉叫苦逼更合适
认证徽章论坛徽章:25
社会主义制度产生的12306怎么能比呢。那就是一个demo而已，根本不是什么系统。就一个垃圾。
论坛徽章:819
3、在感概如此威猛的集群处理能力同时，不得不提起蛋疼的12306，在业务复杂性和巅峰时间的负载比淘宝大促低很多的情况下，12306每次都扛不住，支付宝订单数超过一亿，而12306最高一天出票量大约是166万。问题会出现在什么地方？
最终的问题出在：淘宝出了问题，消费者就要跑别家买了，12306出了问题你就要排队去买票，始终还是得找铁道部买票。
论坛徽章:11
不管怎么样，要采购exadata了
论坛徽章:23
tom0732 发表于
3、在感概如此威猛的集群处理能力同时，不得不提起蛋疼的12306，在业务复杂性和巅峰时间的负载比淘宝大促低 ...
万恶的垄断！！！
itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：10　广播电视节目制作经营许可证：编号（京）字第1149号机制/并发控制
数据库并发控制并发控制指的是当多个用户同时更新运行时，用于保护的各种技术。并发机制不正确可能导致、幻读和等此类问题。并发控制的目的是保证一个用户的工作不会对另一个用户的工作产生不合理的影响。在某些情况下，这些措施保证了当用户和其他用户一起操作时，所得的结果和她单独操作时的结果是一样的。在另一些情况下，这表示用户的工作按预定的方式受其他用户的影响。
应用/并发控制
数据库管理系统中的并发控制（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。下面举例说明并发操作带来的问题：
现有两处火车票售票点，同时读取某一趟列车车票数据库中车票余额为X。两处售票点同时卖出一张车票，同时修改余额为X -1写回数据库，这样就造成了实际卖出两张火车票而数据库中的却记录只少了一张。产生这种情况的原因是因为两个事务读入同一数据并同时修改，其中一个事务提交的结果破坏了另一个事务提交的结果，导致其数据的修改被丢失，破坏了事务的隔离性。并发控制要解决的就是这类问题。封锁、时间戳、乐观并发控制和悲观并发控制是并发控制主要采用的技术手段。
&|&相关影像
互动百科的词条（含所附图片）系由网友上传，如果涉嫌侵权，请与客服联系，我们将按照法律之相关规定及时进行处理。未经许可，禁止商业网站等复制、抓取本站内容；合理使用者，请注明来源于www.baike.com。
登录后使用互动百科的服务，将会得到个性化的提示和帮助，还有机会和专业认证智愿者沟通。
此词条还可添加&
编辑次数：8次
参与编辑人数：5位
最近更新时间： 11:25:00
贡献光荣榜
扫码下载APP一张火车票卖18万？那些年我们扔了多少套房！一张火车票卖18万？那些年我们扔了多少套房！千秋历史百家号听说过老古董卖出上百万，邮票卖出几十万。一张小小的火车票，也能卖出十几万的价！你相信吗？1876年，中国大地上出现第一条营业性铁路——吴淞铁路，之后铁路飞速发展的同时也产生了各种铁路车票。一枚小小的火车票，不只是票证凭据，更是一段旅途的见证，它承载了一段回忆，也记录了我国铁路交通的发展和变迁，具有很高的收藏价值，一些老火车票近年逐渐在市场上走俏。下面让我们看一看哪些火车票正在被热藏。18万的老火车票据媒体报道，2007年，一张1983年从昆明—上海车票面值15元的火车票，被一位香港的收藏家以18万的高价入手。这是迄今为止，民间火车票收藏中价格最高的。呐价值18万的老火车票大约长这个样子！一张小小的火车票就能卖出如此的高价！小编瞬间感觉自己找到了一夜暴富的秘诀……那么，哪些火车票值得收藏，容易卖出高价呢？敲黑板，划重点了啊！中国“最早火车票”2010年，一套完整的清代龙马图邮票在香港亮相。当时创下880万港元（约合750多万人民币）的高价。有人疑惑了，不是说火车票吗，怎么变成邮票了？这套清代龙马图邮票的平生经历比较丰富，我们接着往下看。清·龙马图邮票，1888年，由清朝在台湾的第一任巡抚刘铭传委托下印制。图为台湾第一任巡抚刘铭传如果上图比较陌生的话，电视剧中的形象你应该比较熟悉 ：这套清代龙马图邮票发行后，并没有做邮票用途使用。反而在后来被改作火车票使用，不同的铁路公司加盖不同的公司标志。就成为了——中国“最早的火车票”。虽然是邮票改车票，但是相当具有纪念意义。图为拍卖出750多万人民币的清代龙马图邮票，中间就是加盖了公司印章，被当作火车票使用。“错”票任何普通的玩意儿一旦出现错点，往往立马身价十倍，邮票是这样！钱币是这样！火车票更是这样！“候车”变“猴车”2014年，贾先生乘坐高铁G666从河南新乡前往北京，车票上的“候车”字样却意外被打印成“猴车”。因为觉得错版车票有趣， 贾先生将车票放在朋友圈上拍卖。最终， 450元的过期车票拍出5000元的高价。图为 新乡东—北京西 的错票从“商丘”到“丘丘”河南商丘的刘先生曾买了一张“郑州 — 商丘”的火车票，取票后发现商丘印成了“丘丘”。这张萌萌哒的车票也被网友戏称为 “超萌错体火车站票”。对此，火车站给出的解释是，在自动售取机换取车票时，机器程序临时不稳定造成出现错别字。图为 郑州—商丘 的错票人工容易出错，话说机器也有出错的时候，所以错票就更显稀有。包括火车站的自助取票机，有时也会打个盹儿！所以取票时，千万睁大您的火眼金睛，万一就捡漏了呢？！特殊时期的火车票这种火车票不太容易集到，充满着浓浓的时代气息～看看就好，不过爷爷奶奶或者爸爸妈妈们可能会有哦～各个时期的车票均有其鲜明的时代烙印，如1966年—1976年，当时的车票大多印有“最高指示”或“工农兵”形象， 目前已存世不多，成为珍品。图为1966年和1969年车票特色车票郑州铁路局曾发行的站台票，26枚连起来是一幅完整的《清明上河图》，是一套收藏价值非常高的站台票。满满的都是情怀～图为部分《清明上河图》站台票纪念火车票难抢程度堪比春运！日，青藏铁路开通，这是具有极大历史意义的一天。因此在7月1日所有售出首发车火车票都加盖铁道部的纪念章，首日发车的车票一票难求。图为加盖了铁道部纪念章的青藏铁路首日车票上海铁路局在日为纪念周恩来诞辰100周年发行了一套纪念购票卡， 限额发行1万套，每套100元，受到很多车票藏家的重视。图为纪念周恩来诞辰100周年，发行的铁路购票磁卡奇葩火车站车票民间有很多收藏火车票的达人，除了纪念车票值得收藏，这些藏友还收藏了一些“奇葩”火车票。史上最牛火车票：“东方红-太阳升”；最有感火车票：从莺歌到燕舞的火车票，“莺歌”、“燕舞”都是站名；第一穿越票：“大庆-宋”，大庆，宋均为火车站名。图为“第一穿越票”集火车票有时候是一种淘金的爱好，收集的火车票能卖出上千上万的价格自然开心、有成就感！但火车票有时候也是一种情感的寄托和见证，不能以价格来衡量。例如，河南某网友曾发微博晒出186张火车票，与女友异地恋8年分手69次终成正果。这些火车票见证了他们热恋的最美时光，对他们来说，称之为无价之宝也不为过！图为网友微博晒出的186张火车票看了这么多五花八门的火车票和收藏火车票的诀窍，你是不是已经摩拳擦掌，准备大干一场？在此小编也要提醒一下有志于此的藏家们。火车票收藏目前仍属小众收藏，市场交易尚不稳定，如果您碰巧遇到这些值得收藏的火车票，恭喜您可以好好保存起来；如果遇到有关交易，特别是大额交易的机会，一定要谨慎小心，切勿急功近利。本文由百家号作者上传并发布，百家号仅提供信息发布平台。文章仅代表作者个人观点，不代表百度立场。未经作者许可，不得转载。千秋历史百家号最近更新：简介:用独特的视角观察历史作者最新文章相关文章社会化媒体
了解更多>>
桂ICP备 号
阅读下一篇
自媒体运营攻略
行业经验交流
Hi，在你登录以后，就可以永久免费的收藏任何您感兴趣的内容，关注感兴趣的作者！
手机注册或邮箱注册
点击按钮进行验证
请输入正确的邮箱
已有帐号请点击
帐号创建成功！
我们刚刚给你发送了一封验证邮件
请在48小时内查收邮件,并按照提示验证邮箱
感谢你对微口网的信任与支持
你输入的邮箱还未注册
还没有帐号请点击
点击按钮进行验证
你输入的邮箱还未注册
又想起来了？
你已成功重置密码，请妥善保管，以后使用新密码登录
邮件发送成功！
我们刚刚给你发送了一封邮件
请在5分钟内查收邮件,并按照提示重置密码
感谢你对微口网的信任与支持
对不起，你的帐号尚未验证
如果你没有收到邮件，请留意垃圾箱 或
意见与建议
请留下您的联系方式
* 留下您正确的联系方式，以便工作人员尽快与你取得联系
转藏至我的藏点数据库中的并发操作带来的一系列问题及解决方法
中常见的并发操作所带来的一致性问题包括：丢失的修改、不可重复读、读脏数据、幻影读（幻影读在一些资料中往往与不可重复读归为一类）。
下面我们先来看一个例子，说明并发操作带来的数据的不一致性问题。
考虑飞机订票中的一个活动序列:
甲售票点（甲事务）读出某航班的机票余额A,设A=16.
乙售票点（乙事务）读出同一航班的机票余额A,也为16.
甲售票点卖出一张机票,修改余额A&A-1.所以A为15,把A写回数据库.
乙售票点也卖出一张机票,修改余额A&A-1.所以A为15,把A写回数据库.
结果明明卖出两张机票，数据库中机票余额只减少1。
归纳起来就是：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。前文（2.1.4数据删除与更新）中提到的问题及解决办法往往是针对此类并发问题的。但仍然有几类问题通过上面的方法解决不了，那就是：
不可重复读
不可重复读是指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。具体地讲，不可重复读包括三种情况：
事务T1读取某一数据后，事务T2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对重读B，B已为200，与第一次读取值不一致。
事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神密地消失了。
事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。（这也叫做幻影读）
读&脏&数据
读&脏&数据是指事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤消，这时T1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就为&脏&数据，即不正确的数据。
产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其它事务的干扰，从而避免造成数据的不一致性。
并发一致性问题的解决办法
封锁（Locking）
封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。
基本的封锁类型有两种：排它锁（Exclusive locks 简记为X锁）和共享锁（Share locks 简记为S锁）。
排它锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其它事务在T释放A上的锁之前不能再读取和修改A。
共享锁又称为读锁。若事务T对数据对象A加上S锁，则其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其它事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
在运用X锁和S锁这两种基本封锁，对数据对象加锁时，还需要约定一些规则，例如应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。下面介绍三级封锁协议。三级封锁协议分别在不同程度上解决了丢失的修改、不可重复读和读&脏&数据等不一致性问题，为并发操作的正确调度提供一定的保证。下面只给出三级封锁协议的定义，不再做过多探讨。
1级封锁协议
1级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。1级封锁协议可防止丢失修改，并保证事务T是可恢复的。在1级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读&脏&数据。
2级封锁协议
2级封锁协议是：1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。2级封锁协议除防止了丢失修改，还可进一步防止读&脏&数据。
3级封锁协议
3级封锁协议是：1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。3级封锁协议除防止了丢失修改和不读'脏'数据外，还进一步防止了不可重复读。
事务隔离级别
尽管数据库理论对并发一致性问题提供了完善的解决机制，但让程序员自己去控制如何加锁以及加锁、解锁的时机显然是很困难的事情。索性绝大多数数据库以及开发工具都提供了事务隔离级别，让用户以一种更轻松的方式处理并发一致性问题。常见的事务隔离级别包括：ReadUnCommitted、ReadCommitted、RepeatableRead和Serializable四种。不同的隔离级别下对数据库的访问方式以及数据库的返回结果有可能是不同的。我们将通过几个实验深入了解事务隔离级别以及SQL Server在后台是如何将它们转换成锁的。
Serializable
Serializable隔离级别是最高的事务隔离级别，在此隔离级别下，不会出现读脏数据、不可重复读和幻影读的问题。在详细说明为什么之前首先让我们看看什么是幻影读。
所谓幻影读是指：事务1按一定条件从数据库中读取某些数据记录后，事务2插入了一些符合事务1检索条件的新记录，当事务1再次按相同条件读取数据时，发现多了一些记录。
repeatable read
1：所有的select在第一次一致读以后在事务中都会使用一样的数据状态快照。
2：update，delete都会使用间隙锁来保证数据的安全。防止phantom。
3：这是采用最广的事务隔离级别，也是默认的事务隔离级别。
read commited
1:每一个select都会使用各自的数据状态的快照。
2:如果当前的数据状态已更新到最新，但是当单个select的时候仍然会产生不一致的数据状态。
3:更少的间隙锁意味着更少的死锁。
4:唯一key的检查在第二索引和其它外键检查的时候也会产生间隙所。（gap必须被锁定以防止在parent row被删除后仍在child row中插入相关数据）。
5:这种隔离级别也是使用的非常普遍的隔离级别尤其是在5.1以后的版本中。
6：征对在5.0更早的版本中，可以通过innodb_locks_unsafe_for_binlog移除gap locking。
（In V5.1, most gap-locking is removed w/ this level, but you MUST use row-based logging/replication。）
read uncommitted
1：这种隔离级别几乎不被使用，在select将会看到各种奇怪的数据现象，当然包括其它事务还未提交的数据。
2：强烈不推荐，不能保证数据的一致性。