楼层数据 nginx 处理 替代redis

说明

• 用户访问楼层数据
• nginx请求自身缓存模块
• nginx根据配置（默认5分钟，即缓存5分钟自动失效，失效后请求页面服务重新缓存），读取缓存，如果缓存中没有数据，则放过请求。
• Nginx 请求放过，交给具体服务来处理
• 获取最新的楼层信息，返回信息
• 前端得到数据，进行楼层渲染

架构思路

楼层数据，是一个高频访问，低频修改的关键信息，与之相等的还有商品信息。在系统架构初期，这些信息准备以redis缓存的形式存储，用户访问时，nginx通过中间件，直接访问redis进行响应，这样操作的主要问题是在数据发生变动时需要系统主动将信息推送给redis，性能损耗不大，但是系统多了一些关键性的步骤，也更容易出错。在技术探索中，发现nginx的缓存模块性能优异，且自动拥有灾备机制，最终选择了nginx缓存。

如下图配置所示，在nginx中配置拦截规则，将服务器的响应填充至nginx缓存（默认有效期3分钟，即3分钟，通过一个nginx最多请求一次服务器），如果没有，或者数据已过期，则直接将请求转发给对应的API。API响应后，缓存数据自动更新，且返回给前台。

示例配置

    location /buyer {
            sendfile off;
            proxy_redirect off;
            proxy_http_version 1.1;
            proxy_set_header Connection "keep-alive";
            proxy_set_header Accept-Encoding "";

            #此处是托底配置，旧的总比出错强，当nginx请求后台服务器报错的时候，
            #如果返回配置的错误响应码，nginx则直接取缓存文件中的旧数据返回给用户，托底使用必选配置。
            proxy_cache_use_stale error timeout updating http_502 http_504;

            #缓存并发锁，当nginx缓存没有命中的时候只有一个请求回源tomcat请求数据，其他请求会等待。非必选配置。
            #意思就是当多个请求传递到此配置时即他们的proxy_cache_key是一样的，那多个请求只有一个才会真正回源【即到真正应用阶段生成响应内容】，
            #最后将响应内容 添加到 cache ，然后其他请求 就从cache 获取数据，或直到超时。
            proxy_cache_lock off;
            #等待锁超时时间设置 非必选配置。
            proxy_cache_lock_timeout 10s;
            proxy_ignore_headers Cache-Control Expires;
            # 配置了缓存空间名称，具体可以看节点的 proxy_disk.conf ，不同的请求对应不同的空间名称。
            proxy_cache tmpcache; 

            # 根据响应码设置缓存时间，超过这个时间即使缓存文件中有缓存数据，nginx也会回源请求新数据。
            proxy_cache_valid  200 180s; 

            # proxy_cache_key buyer-api;
            # proxy_cache_prefix_dir $cpid_cid;
            proxy_pass  http://127.0.0.1:8888;
            # 代理后转发的路径

        }

优势

• nginx使用自有缓存模块，性能没有问题
• nginx直接自生响应，不会存在请求jvm、其他缓存的性能损耗
• 服务端不需要主动推送，主动缓存。只需要增删改查逻辑处理，就可以实现对高频访问数据的调整。
• 灵活配置，入手成本低。配置简单，nginx基本人人都会，简单配置时间，以及代理的服务，即可完成

劣势

• nginx缓存模块不共享，多个nginx负载之后，缓存会生成多份。但是以上述配置3分钟1次请求的频率来看的话，即便10个nginx负载，3分钟10个请求，也没有什么问题。
• 缓存时间内，数据不能得到实时的展示。以当前场景楼层问题来看，本架构适用于高频访问，低频修改，即前端楼层数据存在一个3分钟的缓存，是可以接受的范围内的场景。如果是有事务强制要求的场景，那么建议使用传统的redis缓存来处理。