09年给技术内部交流时的ppt

交易方面

  • 程序执行时间过长
    • 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)
      • 更新方案表时,造成锁表
        • 永远可读
        • 永远可写
    • 过关统计、开奖慢
      • + – 基于任务的网格分布式计算
  • 注数越来越大的单式方案
    • + – Map-reduce分布式计算
  • 越来越多的程序,越来越多的故障点
    • 在故障中生存
      • 一次请求的失败不能影响其他请求
    • 坚持做到运维友好
      • 统一、易懂的配置文件
      • 完整的安装、部署文档
    • 做简单的程序
      • Keep it simple, stupid
      • Do one thing, and do it well
    • 要有日志

数据方面

  • 数据量不断上升带来的性能问题
    • 历史数据生成据静态文件
    • 分库、分区、key-value
  • 大量的年久失修的应用
    • 根据访问量决定关闭或重构
  • 用户对数据及时性、全面性、完整性、准确性的不断追求
    • 更好的抓取,计算,更新缓存机制