周末参加了2009系统架构师大会，期间对自己感兴趣的话题做了部分笔记，现摘录如下：
大型可扩展系统架构-新浪网动态应用平台介绍
童剑 新浪高级系统架构师，研发中心平台部总监
- 资源监控
- HA Xen虚拟化
- 数据库集群
2006年点击量3亿/天
实时访问统计，考虑恶意访问
代码分发、数据库集群、软件仓库
高可用、低成本、可扩展
- 无单点故障
- 基于开源软件
- 各部门共享、对外透明
统一运行环境
- 统一配置
简单映像体系
(程序员看来)一个数据库、一个前台、一个缓存
架构图
|---> Cache ----->|
负载平衡 --| \|/ | VFS
|---> App ------->|
用到的软件
- LAMP
- Memecached
- Squid-Cache
- Heartbeat + DRBD
- Xen
- Cfengine
- Bind DNS + Mon
- Haproxy
一些经验
- 借鉴成功经验
如LiveJournal(Memcached、MogileFS)、Yahoo、Google、FaceBook等
- 使用成熟软件
重复造的轮子维护困难、不便于交接
- 底层封装和隔离
可扩展
- 简单 = 高效
够用、分阶段完善、简单(结构设计+实现方法) = 高效(开发过程 + 故障排除)
标准化配置
- 好处
开发生产分离、配置文件
- 运行环境配置
软件包、版本、路径、用户等
记录请求时长、MySQL慢日志
常用配置统一
- 其他...
约定和限制
- 基本约定
读写分离、缓存尽量使用Memcache、不用绝对路径、程序目录+x-w、数据库目录+w-x、不使用长连接、耗时查询小于1次/分钟
- 必要配置
涉及PHP安全方面的配置等
监控报警
- 详细感知
- 自动控制和修复
- 日志统计分析
- 数据监控
* 可用性(ping/port/disk usage)
* 容量(带宽、磁盘、CPU)
* 质量(响应速度、成功率)
* 异常(进程、访问量)
- 主动处理尝试
* 拒绝恶意IP
* 暂停异常服务
* kill异常进程
- 报警
* 仪表板
* Email
* SMS
* IM
性能
- 高可用
- 开发语言的选择
如果对CPU等资源占用不大，可选择解释性脚本语言(C虽然高效，但是从头再来毕竟耗费人力物力)
- 选择合适的服务器软件
高并发高IO时可选择Nginx/lighttpd
- 软硬件因素
- 网络性能
应熟悉常见现象
- 性能分析
对症下药才能治本
容量规划
- 负载 < CPU的核数
- 平常占用资源的40%，峰值80%
- 60%扩容
- 20% 保留给系统管理和监控使用
提问：如果多个机房中的某个机房的服务器出现问题，怎么做到切换服务器不影响访问？
回到：在DNS里设置某个域名的相应时间，所有Name Server都应该遵循该规范
Facebook最佳实践：从百万访问到千万并发访问
吴静涛：F5中国技术总监，高级架构师
- 柔性可用
- 客户诊断
- 降级服务
故障梯度服务（以qzone为例）
- 100% 最优
- 80% 取消增值服务
- 50% 基础功能
- 20% 核心功能
- 5% 公告
缓存、性能
- 用户端Cache
- CDN
- 核心动态数据
- 提升动态数据能力
TTC : 腾讯内存Cache集群
TTC1、TTC2 ----> DB
TTC1、TTC2 --> TTC0 ---> DB
- UGC内容放入存储平台
- 按需加载
- 检测平台、持续优化
其他
- 产品削锋填谷
以前一天只允许在0点开始买卖奴隶，造成该时段访问压力特别大，经产品策划协商，
更改策略：一天内0 - 9点均可开始买卖努力，但早上6点前买卖奴隶收入减半。。从
而通过策略将峰值下降很多
- 集群、轻量、标准
GSLB + LVS + Qzhttp
- 轻量内存
TTC + MySQL
- 逻辑?
S++ ?
- 海量数据存储
TFS、TDB
- 削锋填谷
* 明星 - 低
* 金牛 - 合理
* 瘦狗 - 高
其他：采集用户打开时间、多写少读（可在内存里积累一定的程度再去写）
电子支付系统的分布式服务架构与开放架构研究(PPT)
程立：支付宝（中国）网络技术有限公司 首席架构师
- SOA
性能、响应时间、指标
Async异步调用、future异步调用
- 容量
* 估算新业务上线对容量的需求
* 服务吞吐量优化
- 服务吞吐量
- 伸缩公式
- 伸缩上限
- 单个资源吞吐量上限(串行处理)
* 解决
- 充分扩容
- 平衡扩容
- 消除单点瓶颈
* 资源使用分析、SQL执行次数
* 单点故障
- 并发请求
- 重复请求
- 超量请求
- 请求挤压
- 其他
* 局部配额、令牌
* 幂等控制、操作日志
* 并发控制
- 经典方法（事务）
- 乐观方法(减少事务使用时间)
- 分布锁(生命周期、防止死锁)
* 请求丢弃
过期就丢弃相应的请求
* 时间控制
整体服务期限
* 分布事务
- TCC模式
Try - Confirm -Cancle
- 补偿模式
Do - 补偿
探寻架构设计中的第六感（新浪网)
李晓栋：新浪网研发中心架构部 技术经理
- QOS
- TCP/IP协议先天不足
- 管理心得
* 集中管理
* 监控报警
* 负载分析
* 服务配置
- 原则
* 高性能
* 高可靠性
* 高可管理性
- 流量快速分析
* MRTG、ARTU
* netflow、sflow、SNMP、Sniffer(pfring)
* payload、wireshark
- 平台使用方法
* tcpdump抓包
* 上传pcap包
* 选择分析条件
* 输出分析结果
- misc
* 交换机(prot-channel)
* LVS特殊单臂解决方案
* PK麻烦且变更不便
* 利用iptables获取TCP端口流量统计
* 网页挂马的JS?
淘宝开放平台架构设计与实践
岑文初: 淘宝网开放平台架构师
- 异步交互、通知
* 保持会话、支持异步(短信)
* 异步延时(大数据管理信息)
* 订阅关系维护、支持通知服务(系统间数据同步)
- 服务分流与隔离
二级域名(某API) --> 软负载(LVS、7层包、HA) --> 软负载 + 虚拟服务组(图)
上下文缓存
- 本地缓存、远程缓存
- 商业方面
* 流量收费(调用接口)
* 插件分成
高可用分布式数据库系统架构实践(Oracle\Mysql等数据库)
陈吉平：淘宝网技术总监、首席DBA、DBA Manager、Oracle ACE
- 分布式
分布式存储(TFS)、分布式Cache(Caire)
- 高可用之双机房架构
Data Guard + Redo mirror
- V3.0垂直扩展
用户、商品...
非核心数据使用MySQL
- V4.0 水平扩展 - 读写分离
- V4.0 水平扩展 - 水平拆分
* Scale Out
* 压力动态平衡
* 支持任何数据库
- Amazon、S3、EC2、Simple DB
- C1 读写分离
* 主库集中，读库水平分割
* 写操作、部分重要读操作回主库
* 读库故障可回主库
* APP -> TDDL
* 数据路由、数据复制
- C2 水平分割
* 16DB 1024张表，单表16亿条记录
* 避免无限制分表
* 没有主数据库
- 监控
* DB、Host
* SNMP ? => Agent??
Mysql数据库性能优化实战
叶金荣：搜狐游戏高级MySQL DBA
- 常用命令
* vmstats
vmstatus -s n 3
* iostats
* pidstat
* mpstats
* top
* sar
- 诊断方法
* mysql slow query
* show engine innodbstatus
* profiling
* mysql report
- 杂项
* 禁用swap
* micro slow补丁 可显示详细执行计划
* mysqlsla
* 数据库擅长的事情：存储数据 + 事务
* query cache可适当降低，可通过profiling查看，太大会引发新问题
* sending data值的设置
只查询需要的字段即可
* freeing items
* 关闭binlogs
* ssd 文件系统优化
* xfs文件系统存储单个大文件有优势
* 静态编译mysql速度也会提升
* DNS管理系统
* innodb buffer
* 5.0.77 higerreat版本
- 一些引擎
* MySIAM
* InnoDB
* TukoDB
* XtraDB
* Memcache for MySQL
* waffle Grid Project
- InnoDB Plugin 1.1
* 可快速创建索引
* 数据压缩
* 可在线设置是否单表使用空间
- misc
* OLTP/OLAP 应用类型
* COUNT(*)将进行全表扫描、InnoDB的表推荐使用COUNT(PK)
update: