无线客户端实战

今天是2013阿里技术嘉年华第一天,现场的火热程度,就像这头伏第一天一样,被一股热浪包围着。

在二楼的TechShow,我们团队的客户端数据分析产品“无线数读”占据了最热的角落,就在一排大机架的后面,正对着散热口。到会场的时候发现展台人气超高,心里暗自得意呢,还以为有这么多数据的粉丝。其实应该是“淘公仔”面子大,今天关注“数据说话”的朋友中,冲着淘公仔来的不少吧。

无线专场最后一场,我分享了一点无线淘宝的数据和做客户端数据遇到的经验。这一年多在无线数据上碰到很多坑,其实到现在也没有填完,现场分享的只是冰山一角,如果大家有兴趣,以后可以慢慢再聊。如果对无线数据感兴趣,希望在无线数据的分析和挖掘方面一展身手,我相信把简历给我是最正确的选择,没有之一,哈哈。

今天给大家分享了一个数据,在无线淘宝的用户中,有45.96%用的是苹果设备。初看这个数据很高兴,因为iOS用户的人均购买金额一直都大于Android,愿意花钱的人占比多一些当然没什么不好。但从另外一个角度来看,Android现在的设备出货量远大于iOS,也就是用Android手机的人,还有很多没有成为移动电子商务的用户。去年Android一直是男性用户居多,人均购买金额低可以理解。今年Android女性用户已经明显开始发力,Android用户的增长如果不能跟上设备出货量的增长,是个很危险的事情。在电商领域,得女性用户者得天下。男人负责赚钱养家,女人负责貌美如花嘛。

这里再附送一份我们最近研究的数据,是根据一些第三方的数据做的模型,计算得到的上半年中国的设备出货量(单位:万台,包括水货)

Android Q1:6365
Android Q2: 7508
iPhone Q1:1033
iPhone Q2:1100
iPad Q1:488
iPad Q2:390

数据是经过模型修正的,可能有一些出入,不知道大家觉得准确度如何,或者你有更准确的数据,欢迎分享给我。

刚刚微博上被人at,无节操的转发一下:

@不知一不知二

#ADC2013#阿里技术嘉年华,坚持到> 了最后一场,作为一个没有目的闲逛的闲散人员,我听了好多场,完整听完的就两场……总体感觉:程序员的表达能力还有待提高。不过也有讲得好的@tinyfool 巨能扯,很轻松的就吸引了观众的注意力,所有场次中@NinGoo 讲得最棒,条理清晰,内容充实,而且PPT超漂亮

昨天我们无线数读的PD MM瞄了一眼我正在修改的keynote,说,“枫哥,你做的PPT一点都不像技术屌丝”,我这算是被开除技术屌丝籍了么。。。

===== 一零二四的分割线 =====
最近刚开了个微信公众帐号【数据说话】,这是2013.7.13在上面推送的一篇文章。

如果有兴趣,欢迎关注,我会分享一些互联网和移动互联网方面的数据和观点。有几种方式可以都可以进行关注:
1. 可以用任何一款有扫码功能的App(微信,火眼,或者淘宝客户端等)扫描本站右上角的二维码
2. 微信->朋友们->添加朋友->搜号码,输入微信号【DataTalk】搜索
3. 微信->朋友们->添加朋友->查找微信公众帐号,输入【数据说话】或者【DataTalk】搜索

注:演讲的PPT已经分享在微盘:http://vdisk.weibo.com/s/Kjk2F/1374039026

大数据下的工行

2013.6.23,工行发生重大系统故障,已经有一阵子了。今天想起写这个话题,完全是因为昨天看到了一条现在已经被和谐的微博,当时随手收藏却忘记了粉一下Po主,和谐之后已经死无对证,找不到“传谣”的人了,于是标题的最后形容某群体组织的四个字的专有名词变成了“工行”,不过也好,原来想的标题估计是跨不过深壑的。

先来还原一下现场。2013.6.21,@中国工商银行电子银行 微博发布维护公告:

尊敬的客户:为了能够向您提供更加优质的服务,我行将于2013年6月23日0:10—1:40进行系统优化。期间,我行网上银行、电话银行、手机银行、短信银行、银企互联等相关系统将暂停服务。由此给您带来不便,敬请谅解。

从公告来看,这次维护涉及的面非常广,而时间只有90分钟。一般来说这种计划内的维护都会包括实际操作时间和系统验证的时间,金融类系统的验证工作一般也会比较耗时。因此推测前期准备工作应该还是比较充分。但凌晨2点到4点左右是业务最低峰时间(按照网购业务的低峰期推测),问题可能就出在这里,由于缺乏实际业务压力,验证工作可能只是做了功能性测试。到早上9点,业务压力上来以后,问题陆续出现,根据上述微博在当天12:50发布的消息推测,系统在10点半左右彻底崩溃:

6月23日上午10点38分至11点23分,中国工商银行部分地区因计算机系统升级原因造成柜面和电子渠道业务办理缓慢。目前系统已恢复,各项业务业务正常办理。中国工商银行对因此给客户带来的不便深表歉意。

大约11:23,系统故障排除,业务陆续恢复。这次故障同时影响柜台、ATM、网银和电话银行等各个业务渠道,问题应该是出在交易系统的数据库,和当天凌晨的升级肯定有因果关系。今天网上有消息称工行发布了内部通报:

“6月23日上午,数据中心(上海)监控发现主机CPU利用率升高,经分析判断与6月23日凌晨实施的主机DB2数据库软件升级版本有关(从V9升级到V10),在紧急回退升级系统软件版本后系统运行恢复正常。”

并且关于紧急回退版本的具体原因被归结为:

由于IBM提供的主机DB2V10版本内存清理机制存在缺陷引发。

首先补充一点技术背景知识,我对DB2也不是很熟悉,但是根据多年的Oracle/MySQL DBA经验,升级数据库有两种方案,一种是将新版本安装到新位置,用新版本数据库软件启动实例,执行升级脚本升级数据库的元数据,这样因为旧版本的软件还在,如果升级出现问题,还可以使用旧版本重新启动实例并执行降级脚本;另外一种是直接覆盖升级旧版本的数据库到新版本,但这样遇到问题就需要重新安装旧版本数据库软件。很明显,所有的数据库升级操作都应该选择第一种方案,而这次工商银行的升级也应该是做出了正确的选择。

好,现在假设我们是这次升级的负责人,凌晨顺利升级完成,检测所有功能正常,回家倒头睡觉。早上九点陆续收到告警,心里一惊,立即登录系统发现系统可用内存被快速消耗,随着业务压力越来越大,数据库链连接不断上涨,内存用尽,大量数据被交换到swap导致I/O响应越来越慢,最终数据库主机挂死,异常宕机。这时候又面临两种选择:一种是重新启动主机,回退到旧版本数据库,这需要大约30分钟到60分钟的重启和执行降级脚本的时间,但可以保证数据的一致性;另外一种选择,先不管已经挂死的主机,立即切换到灾备中心的备库(这里还需要假设备库的数据库版本没有升级,否则在业务压力下问题重现的几率非常高,所以也提醒我们,在制定数据库升级的方案时,主备库最好能错开时间执行),这样只需要将备库切换成主库的时间,一般几分钟内就能恢复业务,但是由于原来的主库宕机时,还有部分数据在内存和磁盘缓存的日志文件中可能没有同步到备库,可能会导致部分最新的交易数据受损。

在这种情况下,你会如何选择?尤其是你心里还很清楚,灾备中心平时很少做切换演习工作,你根本不敢保证切换到备库就能100%将业务恢复正常,还要承担部分交易数据不一致的后果。宕机一个小时会成为新闻头条,但要是交易数据不一致导致用户或者银行的money受损,那自己的头可能被老板敲成一条。。。

所以,理性的人一定会选择重启故障主机,使用旧版本数据库软件启动实例,执行降级脚本,恢复业务。这个过程由于紧张,加上应用软件可能还有些依赖要依次启动,业务流量需要限流慢慢放入系统,以便系统充分预热,因此恢复的时间会比计划内的维护时间要长很多,最终到11:23分,数据库终于有新的连接进来,各业务方陆续反馈恢复正常,你终于可以长吁一口气,揉一下眼睛,敲一下脑袋,开始思考怎么写故障报告吧。

所以,不用惊讶为什么花费了大量成本建设的灾备中心在这种情况下毫无用处,大部分灾备中心就是这么设计的。在对事务一致性要求非常严格的场景下,牺牲一定的业务连续性时间来获取一致性,这是符合CPA定理的合理选择。2008年,淘宝面临过同样的情况,当时机房异常停电,运营商一声不吭的躲在角落里抢修。终于在UPS电源支撑到最后一分钟时,运营商才打电话通知我们,电话还没说完,所有数据库就直接嗝屁了。当时的淘宝,虽然也有了备用机房,但两边还没有完全做到1:1对等,灾备演习也还没有成为常态(计划内切换已经是常态),加上在机房和运营商抢修人员沟通时,他们拍胸脯保证一个小时内能修好。于是我也就在机房里忐忑的度过了一个小时,中间有几次想下定决心做异常切换启用备库,最后在心理底线前电源恢复,赶紧启动小型机,启动数据库,还好都能正常启动,一场忙乱,现在想起来还历历如新。

这几年,淘宝的系统架构在发展的过程中,应该说充分的考虑了2008年这种惊险一小时的整机房断电的场景,从web到应用到数据库,都做了比较充分的容灾架构,并且从2010年开始实行严格的定期灾备切换演习。现在已经可以做到高峰期暴力演习,数据库和应用流量都能够做到自动切换,而用户几乎无感知。2008年的那次断电,也可以说功不可没。

故障不可怕,可怕的是对故障视而不见,推脱责任,找替罪羊。至于工行的这次故障,据说内部通报的结论是这样的:

同时,工行总行信息科技部将该事件直接原因归为IBM公司提供的软件产品存在缺陷,并称这点“经IBM公司正式确认”。

所以,我们都懂的。

===== 一零二四的分割线 =====

最近刚开了个微信公众帐号【数据说话】,这是在上面推送的一篇文章,自从有了微博以后慢慢的很少写稍微长一点的东西了,准备用微信公众号督促一下。

如果有兴趣,欢迎关注,我会分享一些互联网和移动互联网方面的数据和观点。有几种方式可以都可以进行关注:
1. 可以用任何一款有扫码功能的App(微信,火眼,或者淘宝客户端等)扫描本站右上角的二维码
2. 微信->朋友们->添加朋友->搜号码,输入微信号【DataTalk】搜索
3. 微信->朋友们->添加朋友->查找微信公众帐号,输入【数据说话】或者【DataTalk】搜索

《高性能MySQL》第三版勘误表

《高性能MySQL》第三本勘误表,欢迎各位反馈书中的问题,我们将尽量在再次印刷的时候修正这些问题,谢谢大家。
购买链接: Amazon 京东 当当

1. 译者序vi 倒数第2段第3行
其中,我负责前、推荐序和第1、2、3章 修改为 其中,我负责前言、推荐序和第1、2、3章

注:2013年5月第二次印刷已经订正

2. P57第7行
rdnwr 修改为 rndwr

注:2013年5月第二次印刷已经订正

3. P227第4行(感谢@半个馒头大师指正)
我们希望返回所有包含同一个演员参演的电影 修改为 我们希望返回所有有演员参演的电影

注:2013年7月第三次印刷已经订正

4. P227第12行(感谢@半个馒头大师指正)
很容易表达“包含同一个参演演员“的逻辑 修改为 很容易表达“有演员参演“的逻辑

注:2013年7月第三次印刷已经订正

5. P422第3行(感谢@hongbin119指正)
noop调度适合没有自己的调度算法的设备 修改为 noop调度适合那些自己在背后实现了调度算法的设备

注:2013年7月第三次印刷已经订正

《高性能MySQL》(第3版)中文版

历经差不多一年的时间,总算让《高性能MySQL》(第3版)中文版可以和大家见面了,今天Amazon和China-pub已经开始预售,其他网站这几天也都会开始上架。预计4.10可以正式出阁了。

Amazon预售地址
China-pu预售地址
在线试读 第2章 第3章 第4章

翻译是件苦差事,初稿出来后,大规模审稿两三次,身心俱疲,大量内容在审稿过程中都被重新修改润色。直到上个周末,最后又快速的过了一次,修正了几十处不太满意的小地方。只要没有最终正式交付给出版社,每看一遍都能找出很多可以改进的地方。因此,然后已经交付付印,心中依然怀有忐忑,期望不要有误导人的错误遗留其中。

内容简介

《高性能MySQL(第3版)》是MySQL 领域的经典之作,拥有广泛的影响力。第3 版更新了大量的内容,不但涵盖了最新MySQL 5.5版本的新特性,也讲述了关于固态盘、高可扩展性设计和云计算环境下的数据库相关的新内容,原有的基准测试和性能优化部分也做了大量的扩展和补充。全书共分为16 章和6 个附录,内容涵盖MySQL 架构和历史,基准测试和性能剖析,数据库软硬件性能优化,复制、备份和恢复,高可用与高可扩展性,以及云端的MySQL 和MySQL相关工具等方面的内容。每一章都是相对独立的主题,读者可以有选择性地单独阅读。

本书不但适合数据库管理员(DBA)阅读,也适合开发人员参考学习。不管是数据库新手还是专家,相信都能从本书有所收获。

译者序

  在互联网行业,MySQL 数据库毫无疑问已经是最常用的数据库。LAMP(Linux +Apache + MySQL + PHP)甚至已经成为专有名词,也是很多中小网站建站的首选技术架构。我所在的公司淘宝网,在2003 年非典肆虐期间创立时,选择的就是LAMP 架构,当时MySQL 的版本还是4.0。但是到了2003 年底,由于业务超预期的增长,MySQL 4.0(当时用的还是MyISAM 引擎)的很多缺点在高并发大压力下暴露了出来,于是技术上开始改用商业的Oracle 数据库。随后几年Oracle 加小型机和高端存储的数据库架构支撑了淘宝网业务的爆炸式增长,数据库也从最初的两三个库增长到十几个库,并且每个库的硬件已经逐步升级到顶配,“天花板”很明显地摆在了眼前。于是在2008 年,基于PC 服务器的MySQL 数据库再次成为DBA 团队的选择,这时候MySQL 的稳定版本已经升级到5.0,并且5.1 也已经在开发中,性能和特性相对于2003 年的时候已经有了非常大的提升。淘宝网的数据库架构也逐渐从垂直拆分走向水平拆分,在大规模水平集群的架构设计中,开源的MySQL 受到的关注度越来越高,并且一年多来的实践也证明了MySQL(存储引擎主要使用的是InnoDB)在高压力下的可用性。于是从2009 年开始,后来颇受外界关注的所谓“去IOE”开始实施,经过三年多的架构改造,到2012年整个淘宝网的核心交易系统已经全部运行在基于PC 服务器的MySQL 数据库集群中,全部实例数超过2000 个。今年的“双11”大促中,MySQL 单库经受了最高达6.5 万的QPS,某个拥有32 个节点的核心集群的总QPS 则稳定在86 万以上,并且在整个大促(包括之前三年的“双11”大促)期间,数据库未发生过任何影响大促的重大故障。当然,这个结果,也得益于淘宝网整个应用架构的设计,以及这几年来革命性的闪存设备的迅猛发展。

  2008 年,淘宝DBA 团队准备从Oracle 转向MySQL 的时候,团队中的大多数人对MySQL 的了解都非常之少。当时国内技术圈对MySQL 的讨论也不多见,网上能找到的大多数中文资料基本上关注的还是如何安装,如何配置主备复制等。而MySQL 中文类的书籍,大部分还是和PHP 放在一起,作为PHP 开发中的一环来讲述的。所以当我们发现mysqlperformanceblog.com 这个相当专业的国外博客的时候,无不欣喜莫名。同时也知道了博客的作者们2008 年出版的High Performance MySQL 第二版(中文版于2010 年1 月出版),这本书被很多MySQL DBA 们奉为圭皋,书的三位主要作者Baron Schwartz、Peter Zaitsev 和Vadim Tkachenko 也在MySQL DBA 圈中耳熟能详,他们组建的Percona 公司和Percona Server 分支版本以及XtraDB 存储引擎也逐渐为国内DBA所熟知。2011 年12 月,淘宝网和O’Reilly 在北京联合举办的Velocity China 2011 技术大会上,我们有幸邀请到Percona 公司的华人专家季海东(目前已离职)来介绍MySQL 5.5 InnoDB/XtraDB 的性能优化和诊断方法。在季海东先生的引荐下,我们也和Peter 通过Skype 电话会议有过沟通,介绍了MySQL 在淘宝的应用情况,我们对MySQL 一些特性的需求,以及对MySQL 做的一些patch,并随后保持了密切的邮件联系。有了这些铺垫,我们对于在生产系统中采用Percona Server 5.5 也有了更大的信心,如今已有超过1000个Percona Server 5.5 的实例在线上运行。所以今年上半年电子工业出版社的张春雨(侠少)编辑找到我来翻译本书的第三版的时候,很是激动,一口应承。

  考虑到这么经典的书应该尽快地和读者见面,故此我邀请了团队中的MySQL 专家周振兴(花名:苏普)、彭立勋、翟卫祥(花名:印风)、刘辉(花名:希羽)一起来翻译。其中,我负责前、推荐序和第1、2、3 章,周振兴负责第5、6、7 章,彭立勋负责第4、8、9、14 章,翟卫祥负责第10、11、12、13 章,刘辉负责第15、16 章和附录部分,最后由我负责统稿。所以毫无疑问,这本书是团队合作的结晶。虽然我们满怀激情,但由于都是第一次参与翻译技术书籍,确实对困难有些预估不足,加上下半年为了准备“双11”等各种大促,需要在DBA 团队满负荷的工作间隙挤出个人时间,初稿出来后,由于每个人翻译风格不太一致,几次审稿修订,也让本书的编辑李云静和白涛吃了不少苦头,在此对大家表示深深的感谢,是大家不懈的努力,才使得本书能够顺利地和读者见面。但书中肯定还存在不少问题,也恳请读者不吝指出,欢迎大家和我的新浪微博http://weibo.com/NinGoo 进行互动。

  同时还要感谢本书第二版的译者们,他们娴熟的语言技巧给了我们很多的参考。也要感谢帮助审稿的同事们,包括但并不仅限于张新铭(花名:俊达)、张瑞(花名:张瑞)、吴学章(花名:维西)等,彭立勋甚至还发动了他女朋友加入到审稿工作中,在此一并表示感谢。当然,最后还要感谢我的妻子Lalla,在我占用了大量周末时间的时候能够给予支持,并承担了全部的家务,让我以译书为借口毫无心理负担地偷懒。

   宁海元(花名:江枫)
   2013 年3 月 于余杭