CN102355596B - 一种适用于视频服务的缓存服务器部署方法 - Google Patents
一种适用于视频服务的缓存服务器部署方法 Download PDFInfo
- Publication number
- CN102355596B CN102355596B CN 201110305582 CN201110305582A CN102355596B CN 102355596 B CN102355596 B CN 102355596B CN 201110305582 CN201110305582 CN 201110305582 CN 201110305582 A CN201110305582 A CN 201110305582A CN 102355596 B CN102355596 B CN 102355596B
- Authority
- CN
- China
- Prior art keywords
- cache
- server
- file
- caching
- aufs
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 11
- 230000006870 function Effects 0.000 claims abstract description 6
- 238000012986 modification Methods 0.000 claims abstract description 4
- 230000004048 modification Effects 0.000 claims abstract description 4
- 239000003795 chemical substances by application Substances 0.000 claims description 50
- 230000004044 response Effects 0.000 claims description 16
- 241000238366 Cephalopoda Species 0.000 claims description 13
- 230000000694 effects Effects 0.000 claims description 5
- 230000008569 process Effects 0.000 claims description 5
- 238000012360 testing method Methods 0.000 claims description 5
- 238000012544 monitoring process Methods 0.000 claims description 3
- 238000011160 research Methods 0.000 claims description 3
- 230000009897 systematic effect Effects 0.000 claims description 3
- 230000008901 benefit Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 241000237858 Gastropoda Species 0.000 description 1
- 235000002595 Solanum tuberosum Nutrition 0.000 description 1
- 244000061456 Solanum tuberosum Species 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种适用于视频服务的缓存服务器部署方法，视频客户端通过访问更近的缓存代理服务器，达到共享远程源站点服务器上的视频的作用，缓存服务器能分担、减少源站点的访问压力，更近的缓存服务器能为客户端提供更有质量的视频服务，针对视频点播方面的缓存服务器，采用将硬盘设计成多盘位，适当的内存作缓存，多核而不是高频CPU，缓存代理采用新的、稳定版本，提供一套软硬件结合的缓存代理方案，能够很好的应用于视频等流媒体应用上，稍作修改，可以应用于其他的缓存代理方面,如大型门户网站缓存代理上。
Description
技术领域
本发明涉及计算机网络通信领域，具体涉及一种适用于实时通讯的视频网络服务器设计和实现。
背景技术
随着计算机网络迅速发展，计算机领域已经发生了很大的变革，计算不在局限于单台计算机，存储不再受限于硬盘的大小，人们从网上获取的信息也不再满足于文字、图片、新闻等静态信息。过去几十年间，人们利用计算机主要是本机处理或者是局域网处理，随着网络技术和计算机硬件要求的不断提升，它也在各方面服务人们的生活。网络的迅速发展使得视频点播成为一种可能，它作为一种新型的娱乐方式服务于更多群体，让更多的消费群体能够共享提供者的作品。尤其是最近几年，视频点播发展的如火如荼，悠视、PPlive、酷6、土豆等视频网站和一些CDN代理商为门户网站提供的服务，它们迅速成长起来，并被广大用户群体所接收,可见视频服务领域作为一种新型网络产业有着旺盛的生命力和广阔的发展前景。
然而，由于网络应用的不断加大以及INTERNET分布形式和用户的分布无规则性，势必会导致源站点服务器的负载增加和客户端浏览不顺畅，用户不能容忍响应时间很长和蜗牛般的访问速度。为了能有效缓解源站点服务器的负载压力，提高客户端的浏览质量，缓存代理(proxy cache)就成为一种优先选择,如何使缓存代理更好服务视频应用成了需要解决的工作。
发明内容
本发明的目的是提供一种适用于视频服务的缓存服务器部署方法。
本发明的目的是按以下方式实现的，视频客户端通过访问更近的缓存代理服务器，达到共享远程源站点服务器上的视频的作用，缓存服务器能分担、减少源站点的访问压力，更近的缓存服务器能为客户端提供更有质量的视频服务，步骤如下：
缓存代理服务器上，在AUFS文件存储模式下，缓存代理在缓存目录下创建二级子目录树，用L1和L2分别表示第一级目录和第二级子目录，在顶级cache_dir目录下创建一定数量的L1，在每个L1下创建一定数量的L2， L1下不直接存放视频文件， L2下存放的才是真正的视频文件，视频文件用A代替，大小平均1-2M，每个L2下存储的文件数量，用N表示， 则整个系统存放文件的数量的关系式为：size=L1*L2*N*A，SIZE单位为MB，为了减少检索的时间，深度搜索的目录不易太多，也就是L2下面的文件数量不易太多，控制在100个文件左右， L1和L2的设置，对缓存代理性能有很大影响，理论研究L2比L1大，这样能保证在同一级目录下搜索到更多的相关文件，而不用重新搜索上级目录；
正常使用缓存代理，首先适当修改内核，具体涉及：
操作系统内核是RHEL 4 AS4；
关于文件描述符的有：
/proc/sys/fs/file-max 8192->1006154
FD_SETSIZE涉及下面几个文件：
/usr/include/linux /typesize.h
/usr/include/linux/bits FD_SETSIZE
/usr/include/linux/posix_types.h
ulimit –Hn 1006154
在编译缓存代理的过程中，查看修改信息：Maximum number of file descriptors we can open... 65536
关于防止网络拥塞的有：
/prco/sys/net/ipv4/neigh/default gc_thresh1、gc_thresh2、gc_thresh3 将值分别扩大8倍分别修改为1024、5120、10240；
/Prco/sys/net/ipv4、ip_forward 0修改为1， 即运行前监测；
/etc/security/limit.conf 将* － nofile 65536或更大的1006154加入；
以上参数均在编译squid之前修改才有用；
为了能在缓存服务器中使用AUFS,需要在编译的时候，将AUFS的相关参数进行编译，具体如：
1）使得--enable-storeio 包含AUFS存储格式，默认只有ufs；
2）选中--enable-epoll，能有效的支持IO访问;
3）根据磁盘的数量，有效的配置异步IO的参数量：--enable-async-io
4）启动大文件参数 --with-large-files
5）设置系统的线程数--with-threads=N
6）将系统支持的最大文件描述符数量设置大些--with-maxfd=32768；
选择多硬盘的服务器，目前1U的服务器最多只能挂载4硬盘，除去系统盘，还只能有3块用作缓存代理，而使用2U服务器，能够使用作缓存代理的硬盘位达到7块，对于娱乐应用的服务器，重要的是访问，响应速度，因此系统存储端采用不作RAID方式，以保证访问读写速度；
编译完成以后，需要在缓存代理配置文件中根据磁盘数配置主要的文件缓存目录：
cache_dir aufs /cc1 500000 32 512 设置一个缓存目录的存储模式为aufs，目录名称为cc1，也就是磁盘的挂载点，整个目录的大小为500000M（500G）；
cache_dir aufs /cc2 500000 32 512
……
配置有效的用户和用户组：
cache_effective_user squid
cache_effective_group squid
增加缓存代理服务器的内存，缓存代理用到的数据都是经过后端硬盘，而访问硬盘会需要很多时钟周期，将系统内存分配给缓存代理使用，将大部分读写直接在内存上完成，能使数据的读写能力大大的提高，分配整个系统1/3左右的内存资源作为cache_mem使用，会使得缓存代理与系统性能发挥的更佳；缓存代理关心的几个重要指标分别是命中率，响应时间，吞吐量，测试结果表明：
1）aufs相对于ufs和diskd存储模式，响应时间上，缩短50％以上；吞吐量却提高1倍以上；命中率也提高很多；
2）4磁盘的aufs比2磁盘的aufs在响应时间和吞吐量上都有很大提高；
3）适量的内存作为缓存使用，不管哪种存储模式，各项指标都有很大提高。
本发明的有益效果是：
1、大量部署缓存服务器，选择后端存储模式，现在支持的存储模式有ufs、diskd、aufs、coss，根据视频缓存文件的特点，选择一种适用于大文件的存储模式。
2、根据应用的特点，缓存服务器需要满足视频应用的性能要求：吞吐量相当大，客户端分布广泛，负载很大，响应时间需要很短，视频数据流流畅，数据的正确性的重要性其次。
3、增加服务器的I/O处理能力。选择多磁盘服务器，能够提供性能更优的缓存代理功能。多个磁盘取代2磁盘的服务器，实际上增加系统的I/O能力。在传输大文件的过程中，能大大缩小访问时间。
4、调整系统的各项参数使得系统的硬件能发挥更大作用，缓存代理也能在现有资源上发挥最大的作用。具体包括：（1）内核文件描述最大数；（2）网络的阻塞开放数量；（3）缓存代理的异步I/O数量；（4）用作缓存代理的内存使用比率。
针对视频点播方面的缓存服务器，采用将硬盘设计成多盘位，适当的内存作缓存，多核而不是高频CPU，缓存代理采用新的、稳定版本。提供一套软硬件结合的缓存代理方案，能够很好的应用于视频等流媒体应用上，稍作修改，可以应用于其他的缓存代理方面,如大型门户网站缓存代理上。
附图说明
附图1缓存代理服务器网络结构图；
附图2文件存储模式。
具体实施方式
参照说明书附图对本发明的方法作以下详细地说明。
缓存代理中，用户的访问实体被成为对象，对象包括文本，图片，下载文件，网页连接和其他信息,从大小上分，可分为大文件和小文件，网络访问的对象大小平均24K，而视频文件的平均大小有2M，因此，缓存服务器中，视频作为大文件看待,基于缓存服务器的后端文件系统目前有UFS 、DISKD 、AUFS、COSS,基于小文件的缓存代理跟大文件的缓存代理设计和实现方式又不一样。本文提供一种基于大文件的缓存代理方式，并提供测试对比。
1)缓存代理服务器上运行的缓存代理服务是squid。通过squid，它一方面将源站点的视频文件同步到缓存服务器proxy上，另一方面对客户端提供视频服务。缓存代理服务器的系统结构如图1所示。
2)UFS是一种传统的unix文件系统，也能适用于一般轻量的squid应用中。但是存在一个致命缺点就是性能非常有限，读写能力和cache命中率都非常低。DISKD文件系统是在UFS上改进的一种系统，效率提升有限。COSS文件系统目前还是一种实验型的文件系统，容易丢失数据，不能很好的支持从磁盘数重建据；还有就是它是针对小文件读写的一种文件系统。不适合部署到视频等大文件缓存服务器上。
3)AUFS以异步I/O方式实现传统unix filesystem的存储机制，与传统的存储机制相比，它使用大量线程进行磁盘I/O操作，AUFS在多CPU核系统上优势更明显。它唯一的锁操作发生在请求和结果队列。然而，所有其他的函数执行都是独立的。当主进程在一个CPU上执行时，其他的CPU处理实际的I/O系统调用。AUFS充分利用服务器上的CPU资源。AUFS文件在缓存服务器上的存储方式如图2所示。
4) 针对于视频等大文件服务，打开文件和寻道seek时间占整个文件下载的时间的比例相对于小文件来说要小得多，下载文件的时间占整个访问的绝大部分。而适用于小文件存储的COSS后端存储模式在这方面就比AUFS性能差，AUFS 的优势在于使用大量的线程，进行磁盘I/O操作，充分发挥线程的优势，对大文件进行同时下载。AUFS对所有的cache_dir使用一个大的线程池，每次squid需要读写，打开、关闭，删除cache文件时，I/O请求被分派到这些线程之一。Cache_dirs和AUFS启动的线程的对应关系是更好的应用AUFS的一个重要因素。下表是它们的对应关系：
| Cache_dirs | 1 | 2 | 3 | 4 | 5 | 6 |
| Threads | 16 | 26 | 32 | 36 | 40 | 44 |
5)在视频服务器上，一个磁盘上部署一个cache_dirs。如果一个磁盘上部署多个cache-dirs，在IO操作的时候，多缓存目录还是用到一个控制器，性能上得不到提升。根据磁盘数量，确认部署的cache_dirs数量。只有两块盘服务器中只有两个控制器，每个磁盘的I/O流量有限，而采用多盘相当于增加了控制器和I/O带宽，并行访问可以调高性能。采用4个250G代替2个500G的硬盘，用多盘代替双盘可以使性能有显著的提高。
6)为了能让系统更好的运行，适当调整系统的参数，重新修改内核文件描述符、关于网络方面的参数。默认系统的部分网络参数是通用的，对特定的网络应用，需要适当调整，才能是缓存应用的功效发挥得更好。
7)确定缓存目录下的一级目录和二级目录的关系。根据磁盘的容量大小和视频文件的特点，确定一级目录和二级目录的数量，可以将搜索的复杂程度降低，减少检索文件的时间，增加响应速度。
8)适当增加cache－mem的大小。能加速缓存代理服务器的访问和提高响应时间。
实施例
视频客户端通过访问更近的缓存代理服务器，达到共享远程源站点服务器上的视频的作用。如图1所示。缓存服务器能分担、减少源站点的访问压力，更近的缓存服务器能为客户端提供更有质量的视频服务。
缓存代理服务器上，在AUFS文件存储模式下，缓存代理在缓存目录下创建二级目录树，L1和L2，分别表示第一级目录和第二级目录，在顶级cache_dir目录下创建一定数量的一级目录L1，在每个一级目录下创建一定数量的二级目录L2。一级目录下不直接存放视频文件，二级目录下存放的才是真正的视频文件，存储的方式如图2所示。视频等文件大小平均1-2M，用A代替。每个二级子目录下存储的文件数量，用N表示。 则整个系统存放文件的数量的关系式为：size=L1*L2*N*A，SIZE单位为MB。为了减少检索的时间，深度搜索的目录不易太多，也就是L2下面的文件数量不易太多，控制在100个文件左右。L1跟L2设置对缓存代理性能有很大影响，理论研究L2比L1大，这样能保证在同一级目录下搜索到更多的相关文件，而不用重新搜索上级目录。
正常使用缓存代理，首先适当修改内核。具体涉及：
操作系统内核是RHEL 4 AS4。
关于文件描述符的有：
/proc/sys/fs/file-max 8192->1006154
FD_SETSIZE涉及下面几个文件：
/usr/include/linux /typesize.h
/usr/include/linux/bits FD_SETSIZE
/usr/include/linux/posix_types.h
ulimit –Hn 1006154
在编译缓存代理的过程中，可以查看修改信息：Maximum number of file descriptors we can open... 65536
关于防止网络拥塞的有：
/prco/sys/net/ipv4/neigh/default gc_thresh1、gc_thresh2、gc_thresh3 将值分别扩大8倍分别修改为1024、5120、10240。
/Prco/sys/net/ipv4、ip_forward 0修改为1， 即运行前监测。
/etc/security/limit.conf 将* － nofile 65536或更大的1006154加入。
以上参数均在编译squid之前修改才有用。
为了能在缓存服务器中使用AUFS,需要在编译的时候，将AUFS的相关参数进行编译，具体如：
1）使得--enable-storeio 包含AUFS存储格式，默认只有ufs；
2）选中--enable-epoll，能有效的支持IO访问;
3）根据磁盘的数量，有效的配置异步IO的参数量：--enable-async-io
4）启动大文件参数 --with-large-files
5）设置系统的线程数--with-threads=N
6）将系统支持的最大文件描述符数量设置大些--with-maxfd=32768
选择多硬盘的服务器，目前1U的服务器最多只能挂载4硬盘，除去系统盘，还只能有3块用作缓存代理，而使用2U服务器，能够使用作缓存代理的硬盘位达到7块。本发明采用其中的6块。对于娱乐应用的服务器，重要的是访问，响应速度，因此系统存储端采用不作RAID方式，可以保证访问读写速度。
编译完成以后，需要在缓存代理配置文件中根据磁盘数配置主要的文件缓存目录：
cache_dir aufs /cc1 500000 32 512 设置一个缓存目录的存储模式为aufs，目录名称为cc1，也就是磁盘的挂载点，整个目录的大小为500000M（500G）。
cache_dir aufs /cc2 500000 32 512
……
配置有效的用户和用户组：
cache_effective_user squid
cache_effective_group squid
适当增加缓存服务器的内存。在很多情况下，缓存代理用到的数据都是经过后端硬盘，而访问硬盘会需要很多时钟周期，那样容易造成大量访问对象的延时，这是视频应用所不能容忍的。适当将系统内存分配给缓存代理使用，将大部分读写直接在内存上完成，能使数据的读写能力大大的提高。不是用到的系统内存越多越好，那样会耗光系统的所有资源而使整个缓存服务器的工作能力下降；分配的比例太小，也会导致缓存代理不能发挥更大的作用。实践证明，分配整个系统1/3左右的内存资源作为cache_mem使用，会使得缓存代理与系统性能发挥的更佳。本文采取 cache_mem 1GB。
缓存代理关心的几个重要指标分别是命中率，响应时间，吞吐量。
根据上面说明，进行实验实施的测试结果表明：
1）aufs相对于ufs和diskd存储模式，响应时间上，缩短50％以上；吞吐量却提高1倍以上；命中率也提高很多。
2）4磁盘的aufs比2磁盘的aufs在响应时间和吞吐量上都有很大提高。
3）适量的内存作为缓存使用，不管哪种存储模式，各项指标都有很大提高。
除说明书所述的技术特征外，均为本专业技术人员的已知技术。
Claims (1)
1.一种适用于视频服务的缓存服务器部署方法, 其特征在于视频客户端通过访问更近的缓存服务器，达到共享远程源站点服务器上的视频的作用，缓存服务器能分担、减少源站点的访问压力，更近的缓存服务器能为客户端提供更有质量的视频服务，步骤如下：
缓存服务器上，在AUFS文件存储模式下，缓存代理在缓存目录下创建二级子目录树，用L1和L2分别表示第一级目录和第二级子目录，在顶级cache_dir目录下创建一定数量的L1，在每个L1下创建一定数量的L2， L1下不直接存放视频文件， L2下存放的才是真正的视频文件，视频文件用字母A代替，大小平均1-2M，每个L2下存储的文件数量，用字母N表示， 则整个系统存放文件的数量的关系式为：size=L1*L2*N*A，SIZE单位为MB，为了减少检索的时间，深度搜索的目录不宜太多，也就是L2下面的文件数量不宜太多，控制在100个文件， L1和L2的设置，对缓存代理性能有很大影响，理论研究L2比L1大，这样能保证在同一级目录下搜索到更多的相关文件，而不用重新搜索上级目录；
正常使用缓存代理，首先适当修改内核，具体涉及：
操作系统内核是RHEL 4 AS4；
关于文件描述符的有：
/proc/sys/fs/file-max 8192->1006154
FD_SETSIZE涉及下面几个文件：
/usr/include/linux /typesize.h
/usr/include/linux/bits FD_SETSIZE
/usr/include/linux/posix_types.h
ulimit –Hn 1006154
在编译缓存代理的过程中，查看修改信息：Maximum number of file descriptors we can open... 65536
关于防止网络拥塞的有：
/prco/sys/net/ipv4/neigh/default gc_thresh1、gc_thresh2、gc_thresh3 将值分别扩大8倍分别修改为1024、5120、10240；
/Prco/sys/net/ipv4、ip_forward 0修改为1， 即运行前监测；
/etc/security/limit.conf 将* － nofile 65536或更大的1006154加入；
以上参数均在编译squid之前修改才有用；
为了能在缓存服务器中使用AUFS,需要在编译的时候，将AUFS的相关参数进行编译，具体如：
1）使得--enable-storeio 包含AUFS存储格式，默认只有ufs；
2）选中--enable-epoll，能有效的支持IO访问;
3）根据磁盘的数量，有效的配置异步IO的参数量：--enable-async-io
4）启动大文件参数 --with-large-files
5）设置系统的线程数--with-threads=N
6）将系统支持的最大文件描述符数量设置大些--with-maxfd=32768；
选择多硬盘的服务器，目前1U的服务器最多只能挂载4硬盘，除去系统盘，还只能有3块用作缓存代理，而使用2U服务器，能够使用作缓存代理的硬盘位达到7块，对于娱乐应用的服务器，重要的是访问，响应速度，因此系统存储端采用不作RAID方式，以保证访问读写速度；
编译完成以后，需要在缓存代理配置文件中根据磁盘数配置主要的文件缓存目录：
cache_dir aufs /cc1 500000 32 512 设置一个缓存目录的存储模式为aufs，目录名称为cc1，也就是磁盘的挂载点，整个目录的大小为500000M（500G）；
cache_dir aufs /cc2 500000 32 512
配置有效的用户和用户组：
cache_effective_user squid
cache_effective_group squid
增加缓存服务器的内存，缓存代理用到的数据都是经过后端硬盘，而访问硬盘会需要很多时钟周期，将系统内存分配给缓存代理使用，将大部分读写直接在内存上完成，能使数据的读写能力大大的提高，分配整个系统1/3的内存资源作为cache_mem使用，会使得缓存代理与系统性能发挥的更佳；缓存代理关心的几个重要指标分别是命中率，响应时间，吞吐量，测试结果表明：
1）aufs相对于ufs和diskd存储模式，响应时间上，缩短50％以上；吞吐量却提高1倍以上；命中率也提高很多；
2）4磁盘的aufs比2磁盘的aufs在响应时间和吞吐量上都有很大提高；
3）适量的内存作为缓存使用，不管哪种存储模式，各项指标都有很大提高。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 201110305582 CN102355596B (zh) | 2011-10-11 | 2011-10-11 | 一种适用于视频服务的缓存服务器部署方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 201110305582 CN102355596B (zh) | 2011-10-11 | 2011-10-11 | 一种适用于视频服务的缓存服务器部署方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102355596A CN102355596A (zh) | 2012-02-15 |
| CN102355596B true CN102355596B (zh) | 2013-08-28 |
Family
ID=45579081
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 201110305582 Active CN102355596B (zh) | 2011-10-11 | 2011-10-11 | 一种适用于视频服务的缓存服务器部署方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102355596B (zh) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102882977B (zh) * | 2012-10-16 | 2015-09-23 | 北京奇虎科技有限公司 | 网络应用集成系统和方法 |
| CN103118086A (zh) * | 2013-01-22 | 2013-05-22 | 温水生 | 一种基于包转发的小文件缓存方法和设备 |
| CN103701936B (zh) * | 2014-01-13 | 2017-05-03 | 浪潮(北京)电子信息产业有限公司 | 一种适用于动漫行业的可扩展共享存储系统 |
| CN104363313B (zh) | 2014-12-02 | 2018-09-18 | 网宿科技股份有限公司 | 使用内容分发网络的网站的资源使用率保障方法和系统 |
| CN105376218B (zh) * | 2015-10-21 | 2020-11-13 | 上海思华科技股份有限公司 | 一种快速响应用户请求的流媒体系统和方法 |
| CN105898396A (zh) * | 2015-11-13 | 2016-08-24 | 乐视云计算有限公司 | 第三方视频推送方法和系统 |
| CN107818111B (zh) * | 2016-09-13 | 2021-10-15 | 腾讯科技（深圳）有限公司 | 一种缓存文件数据的方法、服务器及终端 |
| CN107846613A (zh) * | 2016-09-18 | 2018-03-27 | 中兴通讯股份有限公司 | 视频获取方法、平台和系统，终端，调度和缓存子系统 |
| CN108132757B (zh) * | 2016-12-01 | 2021-10-19 | 阿里巴巴集团控股有限公司 | 数据的存储方法、装置及电子设备 |
| CN107769996B (zh) * | 2017-10-24 | 2021-02-09 | 新华三云计算技术有限公司 | 一种服务端工作状态检测方法和装置 |
| CN109491929A (zh) * | 2018-11-15 | 2019-03-19 | 广东小天才科技有限公司 | 一种缓存数据读写方法及系统 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030093544A1 (en) * | 2001-11-14 | 2003-05-15 | Richardson John William | ATM video caching system for efficient bandwidth usage for video on demand applications |
| CN101027668B (zh) * | 2004-07-21 | 2012-01-04 | 海滩无极限有限公司 | 基于块映射表缓冲存储和虚拟文件系统的可堆叠文件系统模块的分布式存储结构 |
| CN101241501A (zh) * | 2008-02-25 | 2008-08-13 | 浪潮电子信息产业股份有限公司 | 适用于高速缓存代理服务器体系结构的文件系统构建方法 |
| CN101841526A (zh) * | 2010-03-04 | 2010-09-22 | 清华大学 | 一种适用大规模用户点播的集群式流媒体服务器系统 |
| CN101840337B (zh) * | 2010-05-06 | 2013-01-23 | 浪潮电子信息产业股份有限公司 | 一种适用于捕包应用的裁减系统定制方法 |
| CN101854388B (zh) * | 2010-05-17 | 2014-06-04 | 浪潮(北京)电子信息产业有限公司 | 一种集群存储中并行访问大量小文件的方法及系统 |
-
2011
- 2011-10-11 CN CN 201110305582 patent/CN102355596B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN102355596A (zh) | 2012-02-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102355596B (zh) | 一种适用于视频服务的缓存服务器部署方法 | |
| Berg et al. | The {CacheLib} caching engine: Design and experiences at scale | |
| US11593037B2 (en) | File system block-level tiering and co-allocation | |
| Kougkas et al. | Hermes: a heterogeneous-aware multi-tiered distributed I/O buffering system | |
| US10262005B2 (en) | Method, server and system for managing content in content delivery network | |
| Dong et al. | A novel approach to improving the efficiency of storing and accessing small files on hadoop: a case study by powerpoint files | |
| Xu et al. | Characterizing facebook's memcached workload | |
| US8612668B2 (en) | Storage optimization system based on object size | |
| Badam et al. | HashCache: Cache Storage for the Next Billion. | |
| CN102955786B (zh) | 一种动态网页数据缓存和发布方法及系统 | |
| KR101672901B1 (ko) | 분산 파일 시스템에서 소형 파일에 대한 접근성 향상을 위한 캐시 관리 시스템 | |
| Moon et al. | Optimizing the hadoop mapreduce framework with high-performance storage devices | |
| CN102387220A (zh) | 一种基于云存储的离线下载的方法及其系统 | |
| Vazhkudai et al. | Constructing collaborative desktop storage caches for large scientific datasets | |
| Fu et al. | Performance optimization for managing massive numbers of small files in distributed file systems | |
| EP4254187A1 (en) | Cross-organization & cross-cloud automated data pipelines | |
| US8392559B2 (en) | Multiple phase distributed reduction | |
| CN104657461A (zh) | 基于内存与ssd协作式的文件系统元数据搜索缓存方法 | |
| Wu et al. | Exploiting intel optane ssd for microsoft sql server | |
| Hou et al. | GDS-LC: A latency-and cost-aware client caching scheme for cloud storage | |
| Cao et al. | Is-hbase: An in-storage computing optimized hbase with i/o offloading and self-adaptive caching in compute-storage disaggregated infrastructure | |
| Yang et al. | Tombolo: Performance enhancements for cloud storage gateways | |
| Zhou et al. | Hierarchical consistent hashing for heterogeneous object-based storage | |
| CN102609508A (zh) | 一种面向网络存储的文件高速访问方法 | |
| CN109844723A (zh) | 使用基于服务的统计信息进行主控建立的方法和系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |