Web相关Cache介绍
 
简介
 
Cache，中文意思是缓存，是用来将频繁访问的数据，存储于用户本地或者是访问速度很快的存储介质上，以便于提高访问速度及响应时间，我们的电脑的C PU中也有调整缓存，不过我今天这里说的是WEB方面的CACHE，如何合理的使用WEB相关的CACHE，提交用户访问网站的速度及响应时间。以下分别客户端cache、代理服务器、CDN及镜像站点、中心CACHE服务器、JVM CACHE、数据库CACHE简单的介绍了每种CACHE，参考了很多的文章，在些对原作者表示感谢，本文无求育人，只求自育。
 
 
客户端CACHE
 
客户端CACHE，包括浏览器本身的缓存、FLASH存储等，用于存储一些临时的文件或者变化不太或无变化的数据：如浏览器自动将用户浏览的网页存储在用户的硬盘上，下次再浏览相同的网站的时候，系统会自动从硬盘中调出该网页，既节省了时间也减少了网络的交换；还有就是相同的数据需要以不同的形式在客户端展现，如新版工作平台中的应用，页面加载的时候已经加载完了全部应用，但用户看到的并且不是全部应用，用户在做频道切换或者是通过查看全部应用面板查看全部应用的时候，就不需要到后台再次获取数据了，直接从浏览器本身的缓存中获取进行渲染即可，这样也增加了用户的访问速度。
 
目前国内的网络访问速度还不是很好，合理的得用客户端的CACHE功能，减少网络的访问次数，这无疑会提升客户体验，给被访问的网站加分，并且不会有硬件的费用投入，算从理论上讲是一种“零”投入的策略。
 
 
代理服务器(Proxy Server)
 
代理服务器(Proxy Server)，常用的就是“翻墙”，从去年开始因为ZF对GOOGLE的限制，而我辈又要始终追随GOOGLE，那最好的一个办法就是“翻墙”去GOOGLE了；还有就是需要访问的站点访问速度比较慢，可以通过代理服务器提高访问的速度，以下是一个原理图：
 
 
商用的代理服务器，通常都是有CACHE功能的，访问都比较稳定，且个人信息安全性也相对要高得多；但是普通的代理服务器就一定有CACHE功能了，访问的稳定性也不一定能够保证，最可怕的个人信息的安全性完全没有保障，因而在考虑使用代理服务器的时候要慎重，否则不要因小失大，那可就亏大了。
 
 
CDN、镜像站点
 
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服务器上，服务器智能识别，让用户获取离用户最近的服务器，提高速度。
 
以下是CDN原理图：
 
 
现阶段，国内流量比较大的网站，如阿里巴巴、淘宝、腾讯、新浪、网易等都有使用CDN技术，这给用户的感觉就是在任何地方访问都比较快。
 
镜像站点、CDN这二者之间有一点比较类似，都是通过增加服务结点来降低访问的拥挤度，并提高用户访问的速度。他们的差别是镜像服务本身是一个独立的服务器，内容完全来自于主服务器，通过定期到主服务器去更新内容而保持内容与主服务器基本一致，如华军软件园的实现就是很多的镜像站点，直接访问该镜像的请求都全部去了该镜像服务器，这就会出现不同的镜像站点会有不同的访问压力，也就是没有导流、负载均衡的作用，但如果镜像站点出现了问题，是没有被其它服务器代理的，就相当于你访问的其它网站出现问题一样：挂了；CDN其实也是代理，只是他比镜像服务更智能的代理，如果当前服务器访问量过大时，可以将流量导到其它的其它服务器，提升响应的时间，它的优势在于几乎涵盖国内所有线路，而在可靠性上，CDN 在结构上实现了多点的冗余，即使某一个节点由于意外发生故障，对网站的访问能够被自动导向其他的健康节点进行响应。CDN能轻松实现网站的全国铺设，不必考虑服务器的投入与托管、不必考虑新增带宽的成本、不必考虑多台服务器的镜像同步、不必考虑更多的管理维护技术人员。
 
 
中心数据CACHE服务器
 
以上谈到的都是应用以外的CACHE，以增加服务器节点提升用户访问速度，有没有办法使系统在获取数据数据时不是每次都和数据库打交道，减少I/O的开销，从而提访问速度呢？答案是肯定的，阿里使用的是内存CACHE（memcached），将经常访问、不易变化且CACHE命中率比较大的数据，放到CACHE服务器中，如阿里助手的菜单，这些数据都是不怎么变化，放到CACHE中应用在获取菜单数据时，速度就会提高，从而提高应用响应时间，也可以说是提高了用户的访问速度。
 
在选择，需要注意几点：1、CACHE的可靠性，在大量访问及使用的情况，能够保证数据的可靠性；水平伸缩性比较好，这方便于快速提高CACHE的系统容量；CACHE要能够快速数据恢复，当其中某台CACHE出现问题的时候，其它的CACHE能够在短时间之内代替它的工作；2、CACHE的有效性，要支持定期的数据失效策略，为其它需要使用CACHE的数据提供存储空间。
 
使用CACHE的时候，也需要注意CACHE的命中率要高，意思就是CACHE中要存放经常访问、不易变化的数据，这才能够体现CACHE的价值，如果将阿里每个用户的个人信息都放到CACHE中，这是没有意义的。
 
 
JVM CACHE
 
这里说的JVM CACHE，也是将数据放到内存中，算是另外一种内存CACHE，如我们在代码中写的静态对象，只是这种CACHE是没有过期策略的，除了绝对不变的数据以外，如配置文件及参数可以保存JVM中，不推荐使用JVM CACHE；阿里助手的菜单使用的是MEMCACHE，没有使用JVM CACHE，因为菜单有些时候也需要做变更的，这个时候要使变更立马的反映出来，可以通过手动清理MEMCACHE的方式，而JVM CACHE是不方便清理的，并且如果又是在集群环境中，完全清理的成本将是非常大的，而使用中心CACHE服务器，只需清理一次就完全清除了；如果菜单出不来或者数据不正确，那至少是A类故障，呵呵，老板又要找我喝酒了。
 
另外还有一些数据库中间件，如IBATIS、HIBERNATE等，也都支持数据缓存，支持数据自动过期策略，可以设定CACHE的数量，如下是IBATIS的CACHE配置实现：
 
 
 
 
<cacheModel id="USERINFO-CACHE" type="LRU" readOnly="true" serialize="true"> 
 
    <!---数据自动过期时间->
 
    <flushInterval minutes="10"/> 
 
    <!---保存的结果集的数量->
 
<property name="size" value="500" />
 
    <!---数据过期的操作->
 
<flushOnExecute statement="MY_SQL_INSERT"/>
 
    <!---数据过期的操作->
 
<flushOnExecute statement="MY_SQL_UPDATE"/>
 
</cacheModel>
 
<select id="..." parameterClass="..." resultMap="..." cacheModel="USERINFO-CACHE">
 
    SQL HERE
 
</select>
 
 
 
这个对于缓解数据库的的压力也是会起到不少作用的，特别是在对相同的数据进行高峰访问的情况下，那效果是港港的。
 
 
数据库CACHE
 
数据库本身也是有CACHE的，这里我们就不继续究下去了，有兴趣的可以去研究研究。
 
 
结束语
 
本篇介绍CACHE，是从离用户最近到用户最远的顺序进行介绍的，让你可以一层层的去了解合适的优化策略，比较泛泛，没有什么深入的东西，都只是从表面上谈到了一些东西，具体的场景和使用，还需要根据具体情况而定。
 
 
 

问题描述
Linux内存使用量超过阈值，使得Java应用程序无可用内存，最终导致程序崩溃。即使在程序没有挂掉时把程序停掉，系统内存也不会被释放。


找原因的过程
这个问题已经困扰我好几个月了，分析过好多次都没有找到原因，网上查了一下该问题其他人也都遇到过，不过并没有什么好的解决方案，因为项目一直没有上线，每次当内存不足时导致程序崩溃都是重启服务就好了，索性也就没花太多的时间来找问题。现在项目马上上线了，不能在出现程序崩溃的情况了，况且还是前置系统，更不能出现任何问题。
最开始一直认为是程序的原因导致内存泄漏，使用jdk自带的jmap -F -dump:live,format=b,file=/usr/local/sztFront/logs/heapdump.bin命令输出过几次dump文件，通过MemoryAnalyzer分析，应用程序没有耗内存过大的变量。后台猜测是否日志输出过多导致的，毕竟是前置系统，每天的报文量特别大，日志能到达5,6个G。所以把日志接收报文关了，日志大小马上降下来了，每天200M。程序挂掉的时间变长了，原来差不多一周就挂掉了，现在可以达到两周左右才挂掉，还是不行，没有冲根本上解决问题。经过在网上搜索各种相关的问题，问题出现在Cached的值过大，导致系统没有可以再分配的内存空间。Cached只要用来缓存文件的，经常读写的文件会被缓存到Cached中，可以增加读写效率，该功能是Linux系统内核提供的，从2.6.16以后的核心版本才提供，也就是老版的操作系统，如红旗DC 5.0、RHEL 4.x之前的版本都没有。这就可以解释为什么我的项目总挂掉了，我的项目主要就是处理文件的，所以接收和下载的文件会被缓存起来，一直耗着内存不释放，即使把程序停掉也不会释放内存。最后找到了三条执行，可以清理cached的内存
三条指令：
sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches

执行完这三条指令后通过free -m命令查看，free可用内存马上增多，buff/cache列值变小，说明内存被释放了，但是不能总是手动的执行这三条指令，所以最后写了一个shell脚本，开启Linux定时任务crond，每天早上检查一次free内存，当小于4G时执行这三条命令（注：系统内容20G）。
注意：在执行这三条命令之前一定要先执行sync命令（描述：sync 命令运行 sync 子例程。如果必须停止系统，则运行sync 命令以确保文件系统的完整性。sync 命令将所有未写的系统缓冲区写到磁盘中，包含已修改的 i-Node、已延迟的块 I/O 和读写映射文件）


解决方案（手动）
1. 修改/proc/sys/vm/drop_caches，释放Slab占用的cache内存空间（参考drop_caches的官方文档）：


Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:
* echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
* echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
* echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation, and dirty objects are notfreeable, the user should run "sync" first in order to make sure allcached objects are freed.
This tunable was added in 2.6.16.

注意：在执行这三条命令前先执行sync命令



解决方案（自动）
1、编写shell定时任务脚本freemem.sh

#! /bin/sh
used=`free -m | awk 'NR==2' | awk '{print $3}'`
free=`free -m | awk 'NR==2' | awk '{print $4}'`
echo "===========================" >> /app/memory/logs/mem.log
date >> /app/memory/logs/mem.log
echo "Memory usage before | [Use：${used}MB][Free：${free}MB]" >> /app/memory/logs/mem.log
if [ $free -le 4000 ] ; then
                sync && echo 1 > /proc/sys/vm/drop_caches
                sync && echo 2 > /proc/sys/vm/drop_caches
                sync && echo 3 > /proc/sys/vm/drop_caches
				used_ok=`free -m | awk 'NR==2' | awk '{print $3}'`
				free_ok=`free -m | awk 'NR==2' | awk '{print $4}'`
				echo "Memory usage after | [Use：${used_ok}MB][Free：${free_ok}MB]" >> /app/memory/logs/mem.log
                echo "OK" >> /app/memory/logs/mem.log
else
                echo "Not required" >> /app/memory/logs/mem.log
fi
exit 1


2、使用crontab -e命令编辑当前用户的crontab


0 6 * * * /usr/local/tomcat/sztFileFront/bin/freemem.sh

定时任务编写参考：http://www.jb51.net/article/15008.htm

3、重启crond服务

/sbin/service crond restart


4、查看crond服务是否重启成功


/sbin/service crond status




最后，问题解决。我设定的定时任务是每天早上6点执行一次freemem.sh脚本。

https://blog.csdn.net/weixin_41950473/article/details/85269304

 通过 pp.sohu.com，淘宝，拍拍网的域名分析：
 1871.img.pp.sohu.com.cn ，1872.img.pp.sohu.com.cn，1873.img.pp.sohu.com.cn ...
 大致分析，是通过squid 集群的方式实现：
 大致的结构图如下：
 
  
 
 
 
分析的理由如下：
 （一 ）
 一般 Squid Server 集群 简单的运作模式是： 
 1. 当 Squid Server (parent) 没有资料时，会先向 Sibling 的 Squid Server 要资料。 
 2. 如果都拿不到资料，才向用户端回报拿不到资料。  
 （二）
 从pp.sohu.com网站上网页相关返回头信息分析：
 
X-Cache
 MISS from 12237950.14924987.21130635.sohu.com, HIT from 14087629.19002952.22596629.sohu.comAge32282
 
Via1.1 12237950.14924987.21130635.sohu.com:80 (squid), 1.0 14087629.19002952.22596629.sohu.com:80 (squid)
 
说明，它确实是squid集群，第一个squid中没有找到，跑到相邻的squid server 去查找资料。
 具体的集群方式，到底是 Sibling 在前，还是parent在前，不太清楚，或者没有parent，全都是由sibling组成。都有可能。
 但是 有时候可以看到：
 X-Cache 
 HIT from 10011260.10470073.18905479.sohu.com, 
 HIT from 14087629.19002952.22596629.sohu.com 
 所以设想，他可能有一个 parent squid server。
 从 14087629.19002952.22596629 估计，他们是三个squid 一小组之类的。
 
图有可能是如下所示：
 
 
 
 
 
 
 
s
 
 
 
（三）
 有一遍关于 paipai网的图片架构，由于他们是网上c@c 类型的网站，商品的图片数量肯定是巨大的，他们的解决方案是：
 试用了squid 磁盘cache集群技术。 
 以下是他们们对squid cache集群的配置方面的一些阶段性的经验： 
     A、 需要ulimit增加打开文件句柄的数量，以满足大并发访问的要求。 
     B、 编译的时候需要加入epoll支持。 
     C、 编译时打开cachemgr管理功能，以便运营时的监控数据获取。 
     D、 编译时加入GDSF淘汰策略。淘汰策略对CPU消耗和命中率有明显影响。 
     相关文献（John Dilley的Enhancement and Validation of Squid’s Cache Replacement Policy）中也有这方面的数据： 
 
E、 编译是加入异步IO支持参数。 
     F、 根据cache对象的大小设定cache的介质是内存还是磁盘。 
     由于squid可控内存有限，我们设置大量小文件（小于25K的图片）cache在内存中，设置大文件（大于25K的图片）cache在磁盘。
  G、 磁盘cache不是越大越好。根据现在的访问情况看，如果目前一个省的用户的访问行为足够代表性。对于拍拍图片的访问命中率大概是：5G可以达到54％；20G可以达到 80％（以上磁盘cache容量是单机设置，测试时用了2台服务器做集群，所以总容量是上述的1倍）。 
 H、 做磁盘cache的分区的文件系统最好使用reiserfs。 
 I、 不要记录cache_access_log和cache_store_log，这些log会严重影响磁盘IO性能。 
 J、 使用ICP协议作为集群服务器间的通信协议，虽然比较老，但比较稳定。 
 K、 对于32位的suse系统，内存cache大小不能超过1.8G 
 
参考网址：
 一下这篇文章，和我们的问题，非常相似。
 （拍拍网的图片架构）
 http://blog.csdn.net/sutine/archive/2009/09/28/4606490.aspx 
 
 
 
（四）
 再到拍拍网和淘宝的网站查看网页头部返回的信息：
 他们相似的地方，都是利用 图片服务器多域名这样的方式，实现的集群，
 不同的是拍拍网使用的是nginx在最前端，淘宝好像是squid直接定在前面，没仔细看。
 
由于感觉squid直接在前，还是比较危险，而且，squid集群维护比较麻烦，抗压能力也不怎么强，所以，
 根据推测，自己设计了一个图片服务器搭建的方案：
 
 
 
 
 
 
 
 
 
 
 
 
 
解释如下：
 （1）
 假设现在有 十个域名：
 Img01.xxx.com 到img10.xxx.com   每个域名后面都带有一一台或者几台nginx。利用nginx抗压力和利用它的url_hash. 然后在后方再带上一组squid集群。
 (2） 
 Squid 集群，使用memDisk 和harddiskCache 同时使用。 针对不同的机器，加以调整，好机器内存大一点的话，多放点内存，比如5G内存cache，20G diskCache。由于我们现在的机器比较少，所以每台物理机器上安装2-3台squid。由于它消耗的主要是内存和磁盘，对cpu影响，不是非常的明显，应该可以扛得住。 
 10台机器*2 *20 +10*5*2 = 500G ，至少可以cache将近 我们 1/8的数据。
 
（3）
 同时，如果其中的一台squid死掉的话，还可以使用后被的nginx和squid顶上去，不会出现访问不到的情况。
 （4） 
 单独拿出一台 nginx 当做 perge Server。在内网使用，外网发来的perge指令，全部拦截。Real Server 使用lighthpppd  等对图片处理比较强的server来承担。
 

 （5） 
 前端机器上传图片的时候，将现有的这10个域名（可以随时添加），均匀的按照照片名称分散，保存到数据库里。
 
（6） 这样做的好处是：
 如果我添加一组 图片服务器域名，以前所有图片的cache不会失效。
 如果有一个盘柜的磁盘 满了的话，我可以添加一组 图片服务器域名 ，将以前的 域名从上传前端去除，这样，就可以实现 只读不写的功能，而且不用带来迁移的问题。
 
同时，由于上传的用户，大部分肯定是活跃用户，所以，我们可以将现在上传使用的 这组 图片服务器域名对应的机器以及它的cache集群，使用性能比较好的机器来顶，这样，就解决了最活跃的用户，让他的访问速度，比不活跃用户访问速度要快。
 然后按照时间，一年或者半年一次轮询切换最新使用的图片上传域名，也不会出现图片迁移的问题。
 
 
 
以上纯属 自己的看法，如有错误，请留言指教。