09年给技术内部交流时的ppt
Posted in Uncategorized
交易方面
- 程序执行时间过长
- Profile
- 解决Sql阻塞
- + – 使用索引（定位，group，order）
- 简化sql
- 不要依赖sql完成计算工作（file sort，join，tmptable、求和）
- 严格控制那种随着历史数据的积累，exam rows越来越大的查询
- 当数据量放大到千万级别，exam rows是否能小于2k
- No sql
- 数据库是个同时应对很多很多服务(交易、数据、账户、票务、等等)的单点
- 预先计算
- 后台计算，并存入Memcache
- Lucence索引
- 变化触发索引更新
- 缓存
- 缺点：更新慢，缓存失效瞬间会有较大压力
- Java或c重构
- 简化过于复杂的业务需求
- 要坚信：过于复杂的逻辑会让用户头晕并转身走掉
- 越来越大的访问量带来的压力
- 首先、要知道每个程序的负载能力（Requests/Sec）和scale能力（及瓶颈）
- + – 然后、要知道实际访问量（Requests/Sec），及趋势
- 要有预警机制
- 最后、及时扩充服务器
- 单期方案越来越多
- 方案列表对db压力大
- 简化列表逻辑
- 缓存
- 外部索引（lucene）
- 更新方案表时，造成锁表
- 永远可读
- 永远可写
- 过关统计、开奖慢
- + – 基于任务的网格分布式计算
- 方案列表对db压力大
- 注数越来越大的单式方案
- + – Map-reduce分布式计算
- 越来越多的程序，越来越多的故障点
- 在故障中生存
- 一次请求的失败不能影响其他请求
- 坚持做到运维友好
- 统一、易懂的配置文件
- 完整的安装、部署文档
- 做简单的程序
- Keep it simple, stupid
- Do one thing, and do it well
- 要有日志
- 在故障中生存
数据方面
- 数据量不断上升带来的性能问题
- 历史数据生成据静态文件
- 分库、分区、key-value
- 大量的年久失修的应用
- 根据访问量决定关闭或重构
- 用户对数据及时性、全面性、完整性、准确性的不断追求
- 更好的抓取，计算，更新缓存机制