缓存漫谈<一>

最新推荐文章于 2024-09-17 18:12:41 发布

天际宇尘

最新推荐文章于 2024-09-17 18:12:41 发布

阅读量373

点赞数

分类专栏：性能优化文章标签：缓存架构

性能优化专栏收录该内容

2 篇文章 0 订阅

订阅专栏

不能说万能的缓存，但是没有缓存是万万不能的，每次都穿透到数据库，不考虑用户的感受，数据库也会跟你拜拜的。

浏览器端缓存

1、尽量多的使用ajax刷新页面局部，减少服务器压力。
2、设置请求的过期时间，如响应头Expires、Cache-control进行控制。这种机制适用于如对实时性不太敏感的数据，如商品详情页框架、商家评分、评价、广告词等；但对于如价格、库存等实时要求比较高的，就不能做浏览器端缓存。

CDN缓存

有些页面/活动页/图片等服务可以考虑将页面/活动页/图片推送到离用户最近的CDN节点让用户能在离他最近的节点找到想要的数据。一般有两种机制：推送机制（当内容变更后主动推送到CDN边缘节点），拉取机制（先访问边缘节点，当没有内容时回源到源服务器拿到内容并存储到节点上），两种方式各有利弊。使用CDN时要考虑URL的设计，比如URL中不能有随机数，否则每次都穿透CDN，回源到源服务器，相当于CDN没有任何效果。对于爬虫可以返回过期数据而选择不回源。

接入层缓存

对于没有CDN缓存的应用来说，可以考虑使用如Nginx搭建一层接入层，该接入层可以考虑如下机制实现：

1、URL重写：将URL按照指定的顺序或者格式重写，去除随机数；
2、一致性哈希：按照指定的参数（如分类/商品编号）做一致性Hash，从而保证相同数据落到一台服务器上；
3、proxy_cache：使用内存级/SSD级代理缓存来缓存内容；
4、proxy_cache_lock：使用lock机制，将多个回源合并为一个，减少回源量，并设置相应的lock超时时间；
5、shared_dict：此处如果架构使用了nginx+lua实现，可以考虑使用lua shared_dict进行cache，最大的好处就是reload缓存不丢失。

此处要注意，对于托底/异常数据不应该让其缓存，否则用户会在很长一段时间看到这些数据。

应用层缓存

我们使用Tomcat时可以使用堆内缓存/堆外缓存，堆内缓存的最大问题就是重启时内存中的缓存丢失，如果此时流量风暴来临可能冲垮应用；还可以考虑使用local redis cache来代替堆外内存；或者在接入层使用shared_dict来将缓存前置，减少风暴。

应用缓存

本机ehcache、guava cache的使用，尽可能的使用这些内存缓存和硬盘缓存，网络上的数据再快也不可能比内存和硬盘更快。

ps : 不要试图使用ehcache的分布式结构，我曾经用超过一年的时间搞这个东西，事实证明，理论是先进的，事实是残酷的，因为ehcache server是用java写的，硬伤在那，快不起来。至于ehcache其他的分布式方案也存在各种硬伤，所以，在ehcache没有更多的改进之前，当成内存、硬盘缓存用就行了。

分布式缓存

使用redis、memcache之类的分布式存储

1、首先接入层读取本地proxy cache / local cache；
2、如果不命中，回源到tomcat，读取应用缓存
3、如果还不命中，会读取分布式redis集群；
4、如果还不命中，则直接调用依赖业务获取数据；然后异步化到各种缓存；

并发化

并发和异步是个好东西。但是不能滥用，你要清楚的记得，异步不是不耗资源了，是在后台耗，出了问题吃不了兜着走，都不用死锁(死锁的后果……..)，只要跟前台线程形成资源竞争就够受的了，很难查出来。

假设一个读服务是需要如下数据：
1、数据A 10ms
2、数据B 15ms
3、数据C 20ms
4、数据D 5ms
5、数据E 10ms

那么如果串行获取那么需要：60ms；

而如果数据C依赖数据A和数据B、数据D谁也不依赖、数据E依赖数据C；
那么我们可以这样子来获取数据：
这里写图片描述
那么如果并发化获取那么需要：30ms；能提升一倍的性能。
假设数据E还依赖数据F(5ms)，而数据F是在数据E服务中获取的，此时就可以考虑在此服务中在取数据A/B/D时预取数据F，那么整体性能就变为了：25ms。

程序级缓存

搞java的人请看，下面这段代码

 public String getNowTime() {

        String date = new SimpleDateFormat("YYYY-MM-DD HH:mm:ss").format(new Date());
        return date;
    }

改成

    private static final SimpleDateFormat dateFormat = new SimpleDateFormat("YYYY-MM-DD HH:mm:ss");

    public String getNowTime() {

        String date = dateFormat.format(new Date());
        return date;
    }

感觉怎么样？同样的东西，一天new几亿遍多浪费性能啊，关键是你确定你的系统里这样的问题只有这一个吗？

同样的道理，网络io不也是吗？本来一个网络链路可以复用很多很多次的，然后非得每次都去建立一次是真的真的影响很大的，比如httpclient，有多少人用了连接池管理？让网络响应变成了异步？

降级开关

对于一个读服务，很重要的一个设计就是降级开关，在设计降级开关时主要如下思路：

1、开关集中化管理：通过推送机制把开关推送到各个应用；
2、可降级的多级读服务：比如只读本地缓存、只读分布式缓存、或者只读一个默认的降级数据；
3、开关前置化：如架构是nginx—>tomcat，可以将开关前置到nginx接入层，在nginx层做开关，请求不打到后端应用。

限流

目的是防止恶意流量，恶意攻击，可以考虑如下思路：

1、恶意流量只访问cache；
2、对于穿透到后端应用的可以考虑使用nginx的limit模块处理；
3、对于恶意ip可以使用如nginx deny进行屏蔽。

大部分时候是不进行接入层限流的，而是限制流量穿透到后端薄弱的应用层。

切流量

对于一个大型应用，切流量是非常重要的，比如多机房有机房挂了、或者有机架挂了、或者有服务器挂了等都需要切流量，可以使用如下手段进行切换：

1、DNS：切换机房入口；
2、LVS/HaProxy：切换故障的nginx接入层；
3、Nginx：切换故障的应用层；

另外我们有些应用为了更方便切换，还可以在nginx接入层做切换，通过nginx进行一些流量切换，而没有通过如LVS/HaProxy做切换。

其他

1、不需要cookie的应用使用无状态域名，如3.cn；
2、接入层请求头过滤，只转发有用的请求头到后端应用；
3、数据过滤逻辑前置，比如在接入层进行请求参数的合法性过滤；
4、内网设置合理的连接、读、写超时时间；
5、根据需要开启gzip压缩减少流量；
6、使用unix domain socket减少本机连接数；
7、内网考虑使用http长连接；
8、响应请求时，考虑响应头加上服务器ip等信息，方便调试<记得加密>。