[读]互联网应用服务扩展的一点经验

互联网应用服务扩展的一点经验

http://blog.rebill.info/archives/wangdi-internet-service.html

FreeWheel：互联网MRM视频广告投放发布平台: B2B：content owner ->content distributiors

广告应用服务器： 匹配(用户请求和现有广告的匹配)

Log processor: map-reduce(hapdoop), ETL--->OLAP（数据仓库）

Pusher: OLTP DB cache in memory, Pull from DB, 预处理和数据准备。mmap structured memory dump

总结:

商业模式和业务决定设计方案
服务的高可靠性: 99.99% uptime
峰值比: 5:1 peak to Mean.

1.应用服务扩展
1.1 无状态的应用服务器：
把需要状态的信息都编码到url，消除服务器间网络通信依赖
应用服务可重启

1.2 复制和多层次cache.

Master->slave读写分离: 避免Master"长"写锁block slave读锁
Cache的expire time需要认真考虑

Dot server: 无逻辑的server, 为了避免广告应用服务器集群全部单机造成对外服务失效。
Dot server对请求返回一个cache的无广告标准输出.

日志处理：
使用google protocol buffer避免自己定义格式和写parser, 同时binary log减少日志体积, 扩展字段方便
小公司尽量少去重新造轮子.

2.数据仓库扩展：
De-Normalization 反范式, 允许冗余, SQL逻辑简单， 查询性能好， 标准BI工具建模容易
Pivot: 合并相同key的多行数据到一行, 提高
Long tail roll up(长尾成一个item)

Benchmarking:
提取mysql slow query log多次平均测量值， 每月选择top slow query优化
InnoDB buffer设置70%机器内存
不要为了优化而优化, 只有在需要时才考虑:Table partition(分表-垂直分割) and sharding（按客户分库-水平分割）

3.运营原则
系统容量扩展规划: 为峰值预留50%容量， 当系统平均负载>50%, 是扩容的信号。

N+1 Data center: 数据中心不同地理位置分布，备用ISP和CDN

监控:
1. 应用check live
2. 服务异常警报： 错误，延时等
3. 数据库master-slave同步
4. Slow query日报
5. 当日业务运营情况日报

多阶段部署: 建一个和生产环境等比例缩小的Lab， 拓扑结构和生产环境相同, 使用生产环境的真实数据做集成测试。
分阶段部署， 分批分时升级

测试: DEV vs QA: 1:1

以自动化回归测试为核心。

Netlog: What we learned about scalability & high availability
http://www.slideshare.net/folke/netlog-what-we-learned-about-scalability-high-availability-430211
Apache+PHP+eAccelerator+Keepalived(for HA)
Ngnix+Lighttpd+CDN: static files(css/js/image/photo/video)
Search: Sphinx, mysql full-text search is very slow.

DB partitioning(sharding): Divide data on primary key,
How: Mysql partitioning since 5.1

Memcached for sessoin/query result/processed data/generated html
Cache with TTL/Cache forever with invalidate/Cache forever with update

Global locking: use memcache as locking mechanism

Flooding detection by useing memcache[很通用的高效flooding判断方法]
User can only redo action A after a timeout
a guestbook message can only be posted once every
2 minutes
User can not do action A more than X times in T
minutes
only 12 failed login attempts per hour are allowed





Scalability, Availability & Stability Patterns
http://www.slideshare.net/jboner/scalability-availability-stability-patterns

Scalable Web Architectures: Common Patterns and Approaches
http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches
应用架构设计的3个目标: Scale, HA, Performance.

What is scalability for ?
1. Traffic growth
2. Dataset growth
3. Maintainability

Scalability two kinds:
1. Vertical(get bigger): 有些时候增加一些硬件(内存)的代价要小于重新设计软件或者切分数据
比如Mysql性能不够时可以先加一些内存试试.
2. Horizontal(get more)

Share nothing的server容易扩展.

Queuing: with queue, it is easy to parallel in asynchronus method

Database is the toughest part to scale. Dual Intel64 system wtth 16GB+ of RAM can get you a long way.

Mysql: Master-Master+multi-slave(as hot/hot) is good for HA.
design schema/access to avoid collision(hashing users to servers)
No auto-inc columns for hot/hot

Data Federation:
Simple things first: Vertical partitioning + sharding+ central lookup

Multi-site HA:

GSLB: global server load balancing, easiest are DNS