作者文章: Fenng

QClub 杭州站成功在支付宝举行

我开始还有点担心到底多少人会来参加这次 QClub，毕竟这几天杭州太热了，不过大家的热情比天气还热 :) 甚至还有从上海、宁波等地赶来的朋友，如果今天的技术活动能让各位感到不虚此行则是我们莫大的荣幸，非常感谢各位朋友的光临!

组织这样的会议，我也不是很有经验，希望没有怠慢了大家。有点小纰漏：最后要不是同事提醒，为大家准备的 T 恤居然差点忘了发送，有几位朋友走的快，可能没有拿到 T 恤，希望下次活动的时候给大家补上。

会议内容，回头 InfoQ 泰稳那边会有视频和文字的技术内容，我这里先发点会议的照片(拍的好的可能是同事拍的，拍的手法很差的基本是我按的快门，如有不合适的地方请通知我，完整的照片集等下周整理一下放上来）。

上图：会议结束时合影

上图：泰稳拿了一只录音笔，让程立别在身上；同事拿来一只录音笔，程立也别在衣服上；接着又要拿无线麦克风，发现身上挂的东西太多了 :)

上图：聚精会神。可见程立的技术分享之精彩。

上图：左边：支付宝架构师胡喜，右：淘宝架构师林昊(BlueDavy)，有点遗憾的是没让他给大家分享点东西:)

上图：谈到妙处，开怀一笑。

上图：这两个朋友对支付宝的学习发展计划居然很感兴趣 :) 今天活动的会议室平时支付宝用来做新员工培训的，所以墙壁上有很多招贴画、手写的海报什么的。

更多照片看我的 Flickr 或者 Yupoo 相册。

–EOF–

Alipay + QClub , 期待杭州侠客光临

本月 26 日，也就是明天，QClub：当SOA遭遇现实将如期在支付宝举行。

除了报名参加的杭州本地的众多技术精英，阿里集团各家子公司也都有人参加，淘宝、阿里软件、阿里妈妈都会有资深架构师到现场来。相信这回是一场精彩的思维碰撞，期待。

特邀嘉宾：支付宝首席架构师程立(花名：鲁肃)

程立，支付宝（中国）网络技术有限公司。2004年开始参与淘宝网与支付宝系统的建设，2005年起进入支付宝，一直从事于互联网电子支付系统的研发工作。现任支付宝首席架构师，专注于电子支付系统的分布式服务架构与开放架构。

一说起 SOA 可能很多人会觉得比较”空”，这也是我们举办会议的目的之一，”来点实在的技术信息” 是这次活动的一个宗旨。

会议地点

文三路、万塘路交汇处，华星时代广场 5 楼。大厅届时会有人指路

友情提示

为便于交流，请尽量携带名片 :)

–EOF–

Google App Engine 有可能支持 Perl

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

今天看到 Brad Fitzpatrick (就是大名鼎鼎的 Memcached 的作者，现在效力 Google) 在网志中说道，正在利用 Google 著名的 20% 的业余时间为 Google App Engine 增加对 Perl 的支持。

[来源]

还记得时不时的会从中文 Perl 邮件列表里看到有人散布 Perl 过时的言论，其实一个语言过时与否都不重要，关键的是是否有人依赖该语言打造出比较激动人心的应用。如果 GAE 能够支持 Perl ，或许就是 Perl 焕发第二春的时候。从这个角度来说， Erlang 不也是如此么?

提个意见，Google App Engine 啥时候能支持给中国移动发短信? 现在支持 China Unicom，周围没有朋友用联不通的，大家都用移不动的。

–EOF–

MySQL 大企业级应用可行性分析(之二)

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

再说存储引擎

继续上一篇的讨论，记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是，注意各个引擎的锁的粒度。InnoDB 是行锁，锁的实现是依赖于索引的，MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标，其能力很大程度上决定并发能力。

至于 TRANSACTION ISOLATION LEVEL，则是另外一个需要衡量的指标。

老生常谈的，某某引擎适合什么类型的应用，归根结底还是由于其实现的机制决定了引擎的特性。

存储层的解决方案

相信没有人愿意在 MySQL 上用 RAW 设备，很多人几乎就是直接把数据文件放在文件系统上(个人认为，对于数据库这样的应用来说，文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统，单节点的数据存储能力肯定要受到制约–没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障，麻烦就来了。从这个角度考虑，或许 LVM2 是一个可选的方式。

当然，如果把数据文件扔到 SAN 上也还不错。一方面问题是，现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面，很多 MySQL 用户没有 SAN 环境的，数据都是在本地磁盘上。

固态硬盘与 MySQL

前两天有朋友在上一篇分析留言，提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。相信现在有很多企业需要在 DB 的 IOPS 上寻求突破，SSD 是个可能的突破口，但从目前我收集到的数据来看，还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。

商业支持

现在 MySQL 的背后有 Sun ，但是，如果不购买服务的话，到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务，如果问题出在存储引擎上，MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点，因为衔接的环节多，一旦有商务上的问题，很容易陷入扯皮阶段。

–思路中断，这是这个系列不成熟的第二篇。如果有第三篇，我倒是想写几点关于 MySQL 的设想。

–EOF–