第一次作为讲师参加这样大规模的会议，经验不足，特总结一下：
1.虚心接受批评建议，诚心提高演讲技巧。
2.会前准备过份考虑切合当天大会主旋律。
3.铺垫过多，观众需要速食。
4.要讲的东西一定要放到ppt上，会场很大，由于音响回声，前半场需要讲师，后半场只需要幻灯播放员。
5.三段式的ppt最能快速切入主题：1）解决什么问题 2）用什么关键代码解决 3）在哪里下载
6.不谈构架，潜心解决实际问题。
7.10月份杭州QCon如果时间允许，再去分享更好的主题：米聊团队背后的技术，届时一定不忘记上面的6点。
如果您当天听了我的讲座有任何建议，欢迎以评论方式提出。
下面是ppt：

QCon 2011 beijing官方下载地址 http://www.qconbeijing.com

QCon是由C4Media媒体集团InfoQ网站主办的全球顶级技术盛会，每年在伦敦、旧金山、东京、北京召开。2009年4月，QCon首次登陆北 京。大会吸引了500多名架构师、项目经理、资深开发者和技术领导者、以及100多家企业的参与，并获得了业界空前的好评！2010年，QCon全球企业 开发大会（北京站）将于4月23日～25日，在北京京仪大酒店举行。大会将开设包括架构、语言、敏捷、SOA、BAAP、案例在内的6大主题，邀请40多 名国内外著名讲师授课，预计将有200多家企业、500多名来自业内的资深人士参会。

QCon回忆录

4月24日QCon现场直播流水帖

54chen有幸参加并记录了Qcon24日的全过程，上周接到会议的ppt，大小共计90M左右，在网上看到TimYang大侠和blogKid都有提供下载，无赖因为文件太大，反而没有办法持续提供，周末想想，根据以前我发802.1x代码的经验，可以让需要的同志提供email，我转发过去，前提是你要准备个有90M左右空间的邮箱，我是用gamil发过来的，分成了4个部分，一部分20M的附件。慢慢享用吧！需要的同志请留言留下email地址，通过RSS看到本文的同志，如果点feedburner的url被墙的话，请点击下面的地址进来：

http://www.54chen.com/architecture/qcon-beijing-2010-related-ppt-download.html

在前天（2010年4月24日），有幸参加了第二届的QCon北京全球企业开发大会。会上有来自facebook\twitter等国际知名企业的技术高手，和来自国内一线互联网公司的高手，对相应研究的主题进行了深刻的交流。

大早爬起床来，困顿中来到大钟寺附近，寻找到目标酒店。

找到目标、进入，入口很开放，不需要有效证件，能找到自己的牌子就能进去了。领了写上自己名字的牌子挂上脖子，感觉质量差了点。

凭感觉上楼，无特别标识。找到主会场。

未遇到同事，领同声传译耳机，无身份证，不给领。正巧电话淘宝老同事正赴现场，帮领，一枚。

会议开始，现场满座。

第一场，万众期待的eclipse之父Erich Gamma没有出现，颇有些失望。取而代之的是一场敏捷开发管理的内容。相关的现场笔录在 http://www.54chen.com/architecture/april-24-live-stream-qcon-posts.html

第二场，facebook的大侠，讲他们咋用memcached，这哥们具说是设计了个memcache的udp读取的方法，得了个美国的奖。同声传译的影响太大，断断续续的理解了些大概，感觉他们用的二级甚至三级的memcache的方案是很不错的。这哥们自己也同意，方法有些山寨，但好用才是王道。他一定不知道什么是“山寨”。

第三场，twitter的大侠上场，兄弟胡子好浓密呀，哪国人仕？胡子浓密的一定是高手。讲了他们在使用时间片的分步数据方案时的问题。

然后基本上就到了中午十二点了。。。开饭时间一到，拖了十分钟，结束了早上的会议。

同淘宝的老同事一起吃饭，不到四十分钟吃饭的时间。

回到主会议现场，下午是国内讲师。这时第一次见到了台上的Fenng，平心而论，要比头像上帅，还是特意处理过的？

然后第四场一开始，是阿里巴巴的国际站做镜像的一些经验。东西讲得不深，很大面上的来讲～～听一半，笔记本没有电了，撤到外面去上了个厕所。

回来的途中，遇到了Fenng。第一眼他没认出来。看牌子看出来了，看来我的头像也没有本人帅。。。拉拉家长换了名片后，他语重心长的说，科学院一定要坚持办下去。那情景，和某某革命电影情节类似，不过我一时想不出来了，很久没有看革命电影了。激动之下，我解释了下为什么是“五四陈科学院”，是为了纪念一场胜利的革命（1919年5月4日在北京爆发的中国人民彻底的反对帝国主义、封建主义的爱国运动）和70年零一个月后另一场革命未胜利的惨剧，借以勉励，同志仍需努力的道理。

再进入到现场，阿里的大侠已经行文渐尾。

第六场是去哪儿网站的吴永强大侠讲他们的一些运维经验，这哥们也是雅虎出来的，雅虎的运维肯定被继承了过去，所以稳定是没得说的。

掌声中，进入到第六场。人人网的高级技术总兼，我们的老大黄sir，飘逸地带着mac大本上场。这里要多讲一讲，黄sir一向重视技术，对人人网从小到大的发展了如指掌。几个主题下来，从人人网的发展，到我们的nuclear项目介绍，再到王志亮大侠的rose框架，行云流水。

再掌声中，大家对nuclear的设计很感兴趣，会后纷纷在外面探讨起来。按压不住，我也去和前辈们过过招。这一过招，认识了不少朋友，其中还有来自盛大的俞前辈，对dynamo原理理解深刻，经验丰富，似乎盛大在考虑开拓S3类似的业务。另外也和twitter上一系列的同志对上了号，交换了名片。

一番探讨之后，回到现场，新浪微博的大侠timyang已经讲了大半了，听了个大概，作了些笔录。

时间过得很快，一天过去了，最后的时候，找到timyang简单聊了下新浪微博的一些动向。

然后，同原同事、现场twitter上一些朋友，一一告别。Fenng和infoQ的老大（神似）忙里忙外，没顾上去打招呼，领了个t-shirt作纪念，离开。

酒店里一天没有自然光线，感觉很晕。。。（不排除是因为起太早）

国内类似的技术聚会，聚到一起的大侠们越来越多啦。。。感叹一下。

才连接上3G，开始直播

Eric Gamma因为冰岛火山灰原因，没能到，更换成了Scurm的主席

1.scrum agile
30+years管理经验
存在的问题：
1.在公司和团队的环境中，存在沟通问题
2.组织的管理层没有关注到知识性的工作与体力性工作之间的差异
3.高技术的工作人员存在优先选择的问题
4.人们觉得我们不了解我们工作的复杂性

agile宣言
四项价值观：
个体和交互重于过程和工具
可工作软件重于详尽的文档
。。
12个原则：

要经常性地交互可用的软件，周期从几周到几个月不等到，交互的时间越短越好（经常和客户沟通）
最重要的一点：激励项目人员，调动工作经验，钱不是万能的
非常有意思的原则
面对面的交谈
可用的软件是衡量进度的主要指标
项目周期需要保持长期稳定，要有节奏，不要过多催促
技术的精益求精及对设计的不断完善将提升敏捷性
尽最大可能简洁
允许团队自己放手去做，相信你的团队成员，他们会犯错误但是可以理解的
团队经常地自我反省如何提高技术能力

Scrum 不仅仅用在软件上，其他用途也是可以的
Scrum的角色职能
ScrumMaster的误解：这个角色不是项目经理，是为这个团队提供服务的。5-12个人组织团队
产品的backlog：产品功能表
任务表:sprint backlog 在实现上述的功能，我们要做些什么，这并不是真正意义上的时间表

sprint planning:30天要完成这个工作
日常会议
sprint review
sprint retrospective

是一种风险管理的方式，把风险降到最低，特别是大规模开发某个程序的话，可以规避这种风险
可以经常性问客户这样行不行
它是一个非常科学的方式

三个原则能解决很多问题：
询问团队人员
检查代码、检查工作程序
快速提供成绩

有许多问题会导致失败：
1.文化和不信任
2.投资人之间的交流不畅通
3.设计人员同时做多个项目
4.没有遵循sprint
5.外行人加以干涉
6.团队成员没有全力投入(我帮不了你，这不是我的事情)
7.scrum master成了项目经理
8.工作不够迅速

被误解的一些：
Done:必须是可交互了
团队没有投入到改善工作中去
他们经常去探索问题而不解决
对个人的奖励而不是团队奖励

Scrum doesn't work in china
这哥们的图很牛B

中国是共产主义国家，是可以使用scrum的

文化对scrum的影响

讲一个指数，power distance index
另一个：Cultural agility index
个人主义和集体主义的文化

根据agility index 在中国是可行的 而且是更有利的执行

管理人员的指令

专业经理人官僚的作风

中国的小道消息文化

绩效的评估

避免员工与家庭分开

对成员要有耐心

下一个是facebook的memcache实战：

memcache@facebook
企业的周五，穿正装
how big is facebook?
4亿用户
1000个服务器？？？错了，上千个服务器

facebook memcache规模
400M gets/s
28M sets/s
2T
收：9.7M/s

图很cool
facebook terms
tier：层级
cluster:数据中心
ToR:top of rack switch
memcache/memcached

游戏中的memcache规则
get : on miss query data and set（这点我赞同）

short profile
PHP并行数据查询：php polling IO  / 有一个PHP异步IO的方案？
用户的好友信息缓存效果并不是很好
把大数据和小数据分类

序列化与压缩
fb-serialization:快3倍 小30%
gzompress serialized string

mcproxy
scaling servers

增加服务器
查5000个好友的时候 用UDP解决这个问题 测量时间
热门的页面：把key复制 公布热键
replicated keys

举例说在profile表里的一个字段confirmed int:Mirrored keys

mutexes：锁 （这个方案用图演示的，感觉会有可能出现一次出不来信息）

公共主页的数据更新方案：多级memcache方案

删除的一致性：schema-version

delete replay:
delete can fail
log failed deletes
用了iptable

McSQL

测试：
你的动作要快，不要影响系统

python and ctypes
write tests not test frameworks

memcache今后的发展规划
有限的解决方案

下一位是：twitter

twitter的大胡子哥们
what's real-time data?

在讲什么是tweet
memcached for reads

同声传译太烂了。。。
根据主键进行分区的例子

根据主键进行分区的例子和根据用户进行分区会有困难

twitter是根据时间来分区，一开始考虑不是很好的办法？这是一个非常临时性的分区方案，但也能满足99%的查询
将来的解决方式：nosql

实时数据的解决方案：适时的服务

通过offline的解决方案

发布一个新的tweet在timeline里排序，当你tweet的时候开始推送

通过提前的处理，可以提高处理量

一个表格对比08和10的tweets速度

只把数据保存到了内存里，是昂贵的

发一推给所有人的时候，尽量在一秒内，而且要保证120万的推送量

social graph:

所有数据都从内存里读，单元性地读取数据，把问题从大化小。
按照用户分解数据

数据二级索引
（看上去是复制两个维度的数据）

flockDB?开源的

分布性的存储中的数据一致性

分区和索引变得越来越复杂了。。。

(时间不够了。。)

吃饭时间，下午再来。。。

回来了，在大宴会厅听阿里巴巴国际站的架构。主要是境像。

数据同步1.0

SQL复制的方式会带来数据冲突，比如说批量操作。

双站点应用拆分的问题。

CAP原理

写数据一致性和可用性

读数据容忍一致性，境像

结论：读应用更容易实现跨IDC的部署

数据同步会放大数据不一致

从设计上避免数据完整性的问题

设计业务流程的时候需要避免跨IDC的WEB Flow

阿里的读应用基本是从搜索来或者是cache来

缺陷：

双向同步的冲突

解决业务冲突

双站点扩展性已经好了很多

进入第三阶段：多站点 全境像

目标是所有机房的所有应用都必须有跨IDC的备份，数据亦然。

数据同步瓶颈分析

受制于为了满足数据一致性而对写入操作进行的排序

数据同步2.0设计原则

在数据库层面记录数据变更

并行所有可以并行的内容

有选择的侵入业务

merge操作

写应用的镜像方案：

双master在实现复杂性上会带来问题

可维护性提高

（笔记本没电了。。。）

后面还有“去哪儿”网站架构、人人网架构、新浪微博架构。。。晚上回去再补上来。。。