视频的Cache层是使用Squid进行服务的,当然对于这样的缓存服务也有人使用Varish或者Nginx的Proxy Cache.但是经过一段时间的使用和了解,Squid确实有其强大指出,尤其在反代理这个方面.包括还有很多成熟的功能模块,对于视频这样重网络I/0和大文件存储的应用来说,某些参数的设置和模块确实比较重要.
1:视频拖动模块
支持视频的拖动,这个其实需要二次开发,但是应该不难.
2:视频业务一般都是做防刷的,一般通过变化URL进行控制,而Squid是通过URL进行缓存的,所以同一份内容可能会缓存多次,而Storeurl_rewrite就能解决这个问题.
3:对于视频大文件来说,存放在磁盘和内存中的文件假如过大(尤其是内存)则可能一个4G的内存只能存放很少数量的对象个数,这时候
maximum_object_size,minimum_object_size ,maximum_object_size_in_memory 参数就能发挥作用了
4:对于静态页面缓存来说,其实内存和磁盘不是瓶颈,最大化内存使用也没有问题,一般情况下内存Cache替换策略使用LRU就行了,而对于视频这样的大业务来说.需要充分考虑缓存成本,对象大小,访问频率,使用使用GDSF的淘汰策略,看了淘宝的CDN业务针对大文件,小文件存放的设备(SSD,SAS,SATA)有所策略,也是借鉴于GDSF算法.
5:对于内存的分配计算也很重要
需要考虑并发链接的内存分配,文件索引关系的内存,Cache对象消耗的内存,对于cache_mem的配置很重要.另外cache_swap_low 也控制了磁盘的使用.
6:由于视频文件本身比较大,传输量比较大,经常存在用户主动关闭页面,那么这个时候是否继续请求后端并缓存,quick_abort_min就会起作用,对于大文件来说设置大一点比较靠谱.
7:对于RANGE的请求,range_offset_limit的质量从查阅的资料来看不是非常的了解,总之不支持这样的请求相对比较合适.
8:对于各种不同Cache的头的请求已经URL地址的随机参数来说,refresh_pattern和reload_into_ims就会起作用,总体来说reload_into_ims是转变请求为If-Modified-Since的处理
9:zero_buffers
据同事说会有性能上的提升,可觉得作用不大.
10:cache_vary
对于不同http协议导致的多份Cache,强烈建议使用Squid2.7版本.我们博客使用的是2.6,导致在Squid和后端没有进行任何压缩并浪费流量,而消耗性能的压缩工作放在了七层.
总体上来说Squid有其优势,但是对于单机的优化,无非是支持过多的链接数,尽量将网卡跑慢,所以I/O的优化,减少系统调用,包括使用更优秀的网络调用,内存的优化都是单机优化的课题.