才连接上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 在是可行的 而且是更有利的执行
管理人员的指令
专业经理人官僚的作风
的小道消息文化
绩效的评估
避免员工与家庭分开
对成员要有耐心
下一个是的memcache实战:
memcache@
企业的周五,穿正装
how big is ?
4亿用户
1000个服务器???错了,上千个服务器
memcache规模
400M gets/s
28M sets/s
2T
收:9.7M/s
图很cool
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今后的发展规划
有限的解决方案
下一位是:weibo
weibo的大胡子哥们 what's real-time data?
在讲什么是
memcached for reads
同声传译太烂了。。。
根据主键进行分区的例子
根据主键进行分区的例子和根据用户进行分区会有困难
weibo是根据时间来分区,一开始考虑不是很好的办法?这是一个非常临时性的分区方案,但也能满足99%的查询
将来的解决方式:nosql
实时数据的解决方案:适时的服务
通过offline的解决方案
发布一个新的在timeline里排序,当你的时候开始推送
通过提前的处理,可以提高处理量
一个表格对比08和10的s速度
只把数据保存到了内存里,是昂贵的
发一博给所有人的时候,尽量在一秒内,而且要保证120万的推送量
social graph:
所有数据都从内存里读,单元性地读取数据,把问题从大化小。
按照用户分解数据
数据二级索引
(看上去是复制两个维度的数据)
flockDB?开源的
分布性的存储中的数据一致性
分区和索引变得越来越复杂了。。。
(时间不够了。。)
吃饭时间,下午再来。。。
回来了,在大宴会厅听阿里巴巴国际站的架构。主要是境像。
数据同步1.0
SQL复制的方式会带来数据冲突,比如说批量作。
双站点应用拆分的问题。
CAP原理
写数据一致性和可用性
读数据容忍一致性,境像
结论:读应用更容易实现跨IDC的部署
数据同步会放大数据不一致
从设计上避免数据完整性的问题
设计业务流程的时候需要避免跨IDC的WEB Flow
阿里的读应用基本是从搜索来或者是cache来
缺陷:
双向同步的冲突
解决业务冲突
双站点扩展性已经好了很多
进入第三阶段:多站点 全境像
目标是所有机房的所有应用都必须有跨IDC的备份,数据亦然。
数据同步瓶颈分析
受制于为了满足数据一致性而对写入作进行的排序
数据同步2.0设计原则
在数据库层面记录数据变更
并行所有可以并行的内容
有选择的侵入业务
merge作
写应用的镜像方案:
双master在实现复杂性上会带来问题
可维护性提高
(笔记本没电了。。。)
后面还有“去哪儿”网站架构、人人网架构、新浪微博架构。。。晚上回去再补上来。。。
原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]
捐赠说明