| 1 | | 在应用访问数据库很频繁,数据库顶不下来的时候,我们大多数情况下会在应用与数据库之间加入缓存;但如果是数据库没压力,SQL正常等这些情况下,应用顶不下来,那我们该怎么处理???(PS:在这旁路缓存中,我们只讨论动态页的缓存)在现阶段,我们暂时只有的办法是:1. 加资源进行扩充; 2. 如果程序还存在优化空间,就对程序进行相应的优化。可不可以有一种方式:在资源不增加和应用基本不该动的情况下,进行架构的调优?针对这样一个提问,最近诞生一个不切实际的想法:旁路缓存。基本目标是:外部条件帮助应用生成动态链点的缓存,应用代码不需更改或只需要增加个投递功能。基本原理为:Nginx做mc|redis的存取,用户第一次访问Nginx,Nginx进行读取mc|redis,如果没有则留下痕迹,旁路缓存根据痕迹生成相应的缓存数据,并把相应数据存入相应的缓存中。架构图如下: |
| | 1 | 在应用访问数据库很频繁,数据库顶不下来的时候,我们大多数情况下会在应用与数据库之间加入缓存; |
| | 2 | |
| | 3 | 但如果是数据库没压力,SQL正常等这些情况下,应用顶不下来,那我们该怎么处理??? |
| | 4 | |
| | 5 | (PS:在这旁路缓存中,我们只讨论动态页的缓存) |
| | 6 | |
| | 7 | 在现阶段,我们暂时只有的办法是:1. 加资源进行扩充; 2. 如果程序还存在优化空间,就对程序进行相应的优化。 |
| | 8 | |
| | 9 | 可不可以有一种方式:在资源不增加和应用基本不该动的情况下,进行架构的调优? |
| | 10 | |
| | 11 | 针对这样一个提问,最近诞生一个不切实际的想法:旁路缓存。 |
| | 12 | |
| | 13 | 基本目标是:外部条件帮助应用生成动态链点的缓存,应用代码不需更改或只需要增加个投递功能。 |
| | 14 | |
| | 15 | 基本原理为:Nginx做mc|redis的存取,用户第一次访问Nginx,Nginx进行读取mc|redis, |
| | 16 | |
| | 17 | 如果没有则留下痕迹,旁路缓存根据痕迹生成相应的缓存数据,并把相应数据存入相应的缓存中。架构图如下: |