虎扑基础设施架构探讨

3,197 views

Published on

虎扑基础设施架构探讨 之 存贮篇, 讨论 分级缓存/存贮 体系、架构

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,197
On SlideShare
0
From Embeds
0
Number of Embeds
710
Actions
Shares
0
Downloads
59
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

虎扑基础设施架构探讨

  1. 1. 虎扑基础设施架构探讨<br />—— 分级缓存/存贮体系<br />
  2. 2. 目前的架构: 山是山<br />
  3. 3. 目前的架构<br />Memcached<br />Redis<br />Memcached<br />Redis<br />Web server<br />Mysql<br />Web server<br />Mysql<br />Web server<br />MySQL<br />Web server<br />Web server<br />TT<br />Coreseek<br />TT<br />
  4. 4. 目前的架构: 优缺点<br />Pros<br />简单、直接<br />Cons<br />与 基础设施 绑定的应用程序<br />当基础设施变化时, 代码需要相应修改<br />有些情况下代价是昂贵的<br />
  5. 5. 存在的其它问题<br />缓存与 KeyValueDB, 两种编程范式<br />TT/Redis既作缓存, 又作 KeyValueDB<br />混用容易造成混淆<br />分布式缓存传输代价较高<br />Photo 项目<br />短连接的性能损耗<br />频繁连接, 连接损耗<br />
  6. 6. 编程范式<br />Cache 范式<br />Pros: 简单,访问者触发,lazy update<br />Cons: 雪崩,需时时检测缓存是否存在<br />Database 范式<br />Pros: ACID, persistent<br />Cons: active update<br />
  7. 7. 对现有设施的考察<br />
  8. 8. 现有缓存/存贮基础设施<br />Redis<br />TT<br />Memcache<br />APC/eAccelerator<br />MySQL<br />
  9. 9. Redis: 是什么<br />Persistent In-memory K/V Database<br />Persistent In-memory Shared Cache<br />最大存贮量就是分配给它的内存量<br />
  10. 10. Redis: 设计哲学<br />内存当硬盘,硬盘当磁带<br />
  11. 11. Redis: 优缺点<br />Pros<br />全内存,性能好<br />多种数据结构支持<br />String, Hash, List, Set, Sorted Set<br />开发者社群活跃<br />Cons<br />DB 容量受限于内存,目前不能充分利用磁盘的大容量来存放冷数据<br />较弱的 ACID 特性<br />
  12. 12. Redis: 新浪微博应用<br />Redis<br />MySQL<br />Redis<br />MySQL<br />Redis<br />MyTrigger<br />MySQL<br />Redis<br />Redis<br />Redis<br />Redis<br />Redis<br />Web server<br />Web server<br />Web server<br />RedisProxy<br />Web server<br />Web server<br />
  13. 13. 新浪为什么不用 Memcache<br />为什么不用 Memcache?<br />雪崩<br />缺乏原生 HA 方案<br />
  14. 14. Redis: 新浪微博<br />Pros<br />读取缓存的程序逻辑简单<br />避免处处检测缓存是否存在、重建<br />Cons<br />积极的缓存更新<br />对于缓存数据逻辑复杂的情况<br />步行街的主题列表<br />每一秒钟都有很多 UPDATE 操作<br />代价相对较高<br />
  15. 15. Redis-Proxy<br />对短连接的优化<br />Pros<br />Cons<br />系统组计划引入这种技术<br />SQLRelay<br />寻找开源工具<br />手工打造<br />
  16. 16. TT/KT: 是什么<br />Traditional K/V Database<br />Persistent K/V Database<br />K/V 数据库,但大部分热数据在内存中缓存<br />TT 以磁盘为中心,所以对于”持久化”这块的可靠性工夫下了不少<br />KT 新特性:<br />Persistent Shared Cache<br />支持多数据库<br />速度较 TT 更快<br />
  17. 17. TT/KT: 优缺点<br />Pros<br />支持最大 8 EiB的数据库…<br />围绕硬盘的设计,ACID 特性好<br />内建 Lua支持<br />Cons<br />不如 Redis支持的数据类型、操作多<br />性能上较 Redis稍弱<br />
  18. 18. Memcache: 是什么<br />In-memory Shared Cache<br />HA / Replication<br />Repcached<br />
  19. 19. Memcache: 优缺点<br />Pros<br />简单,快速<br />Cons<br />原生无持久性<br />原生无 HA/Replication 能力<br />不如 Redis支持的数据类型、操作多<br />
  20. 20. APC/eAccelerator: 是什么<br />不只是 PHP 优化器和代码缓存<br />还可以是 本地数据缓存<br />
  21. 21. APC/eAccelerator: 优缺点<br />Pros<br />速度快, 非常快<br />Cons<br />PHP 引擎会较频繁重启, 导致缓存清空, 雪崩<br />不如 Memcache等独立服务器, 重启无关<br />方向<br />可否实现一种独立的本地缓存? PHP 引擎重启无关?<br />(可以实现。)<br />
  22. 22. MySQL Handler Socket<br />补充介绍<br />For InnoDB<br />
  23. 23. Benchmark (get/set)<br />
  24. 24. Benchmark (get)<br />
  25. 25. 建议的架构: 山非山<br />
  26. 26. 建议的架构<br />Redis<br />GlobalCache<br />Web server<br />Web server<br />Web server<br />Web server<br />Memcached<br />Mysql<br />Web server<br />LocalCache<br />Mysql<br />Mysql<br />TT<br />SearchEngine<br />KeyValueDB<br />
  27. 27. 分级缓存/存贮体系<br />本机缓存 (APC, eAccelerator, …)<br />自动过期…<br />分布式缓存 (Memcache, Redis)<br />共享缓存、可后台手工清除<br />NoSQL (TT, Redis)<br />Key/Value 存贮,简单快速的存贮<br />SQL DB (Mysql) <br />传统存贮,可进行复杂操作 (投影、选取, etc.)<br />Full Text Index (Coreseek)<br />全文索引存贮<br />
  28. 28. 轻量级抽象<br />Hoop_LocalCache<br />Hoop_GlobalCache<br />Hoop_KeyValueDB<br />Hoop_MySQLDB<br />Hoop_SearchEngine<br />Hoop_...<br />
  29. 29. 分级缓存/存贮体系<br />Hoop_LocalCache<br />PHP 容器中的缓存<br />系统维护角度,会较频繁地进行重启<br />适合于:<br />页面缓存、片断缓存<br />总是自动过期的数据项<br />使用非常频繁的数据项或 Size 较大的数据项,除了在 GlobalCache中存贮外,本地亦可缓存一份<br />请求参数无关的缓存<br />不适合于:<br />请求参数依赖的缓存<br />程序控制的缓存无效化 (缓存一致性问题)<br />
  30. 30. 分级缓存/存贮体系<br />Hoop_GlobalCache<br />Session<br />User info<br />程序控制清除、替换<br />请求参数依赖的缓存<br />…<br />
  31. 31. 本地缓存 vs. 全局缓存<br />APC/eAccelerator vs. Memcache<br />Photo 项目中的应用<br />解决全局缓存的网络时延问题<br />
  32. 32. GetOrLock和 延迟删除<br />Hoop_LocalCache支持<br />Hoop_GlobalCache支持<br />原理<br />
  33. 33. 分级缓存/存贮体系<br />Hoop_KeyValueDB<br />简单、快速的 数据库<br />
  34. 34. 分级缓存/存贮体系<br />Hoop_MySQLDB<br />传统存贮,可进行复杂操作 (投影、选取, etc.)<br />
  35. 35. 分级缓存/存贮体系<br />Hoop_SearchEngine<br />全文索引存贮与查询<br />
  36. 36. 为什么我们要自己做抽象?<br />分级缓存/存贮体系<br />常规框架分为两层: Cache / DB<br />我们有第三层<br />KeyValueDB<br />避免 Fork<br />封装优于补丁<br />
  37. 37. 思考: 山仍是山<br />
  38. 38. 山仍是山<br />从最终优化角度来讲<br />各个 NoSQL产品有自己的优缺点、特性<br />存在需要调用其特殊 API 的需求<br />[NOTE: 过早的优化是万恶之源…]<br />
  39. 39. 山仍是山: Redis案例<br />Redis特有功能很好用<br />List, Hash, Set, Sorted Set<br />其它的 NoSQL产品缺乏这些功能<br />如何在 Hoop_KeyValueDB框架下使用?<br />
  40. 40. 山仍是山: 对策<br />这部分代码量较少时<br />维护量则亦较少<br />可以重构抽象层<br />较大抽象 (为 TT 提供相应模拟)<br />或添加新抽象层<br />与现有抽象存在明显区隔,是一种新的品类时<br />Hoop_KeyValueDB本身就是一个添加抽象层的好例子<br />
  41. 41. 结论<br />
  42. 42. Redis: 王道<br />拟使用 Redis逐步替代 TT / Memcache<br />逐步…逐步…逐步…<br />
  43. 43. 轻量级存贮抽象<br />大家支持吗?<br />
  44. 44. Hoop Framework ?<br />Passport API<br />SNS API<br />动态 API<br />JS、CSS Framework<br />Hoop Page Design Guideline<br />页面规范<br />
  45. 45. 最后…<br />
  46. 46. DRY: 不要重复你自己<br />避免重复代码 (Copy/Paste)<br />拒绝 Fork<br />封装优于补丁<br />上游优先<br />脚本化自己的测试<br />自动测试<br />回归测试<br />我也不想重复讲…<br />
  47. 47. 谢谢!<br />

×