Web缓存系统ehcache/Memcached/Redis/MongoDB及Nosql引入
转载:http://www.cnblogs.com/firejava/p/6256788.html
转载:http://www.oschina.net/news/71132/nosql-use-case
一、Web缓存技术
网站技术高速发展的今天,缓存技术已经成为大型网站的一个关键技术,缓存设计好坏直接关系的一个网站访问的速度,以及购置服务器的数量,甚至影响到用户的体验。网站缓存按照存放的地点不同,可以分为客户端缓存、服务端缓存。
客户端缓存又可分为:浏览器缓存、网关或代理服务器缓存,
网关或代理服务器缓存是将网页缓存中网关服务器上,多用户访问同一个页面时,将直接从网关服务器把页面传送给用户。浏览器缓存是最靠近用户的缓存,如果启用缓存,用户在访问同一个页面时,将不再从服务器下载页面,而是从本机的缓存目录中读取页面,然后再浏览器中展现这个页面。
服务端缓存分为:页面缓存、数据缓存、数据库缓存
1、页面缓存
页面缓存是将动态页面直接生成静态的页面放在服务器端,用户调取相同页面时,静态页面将直接下载到客户端,不再需要通过程序的运行和数据库的访问,大大节约了服务器的负载。
早期的网站很多使用发布系统来完成这个功能,在后台发布时将数据和页面模板整合成静态页面,存放在硬盘中。但这样的缺陷很明显,一是后台的程序的编写很 复杂,二是缓存的控制只能通过人为的方式来控制,这对一些更新十分频繁的网站就是一个噩梦,网站可能在不停的做缓存的删除和重建。当然后来出现了一些自动 更新这些缓存的框架,比如PHP的SMARTY模板技术,可以定义缓存过期的时间,自动去更新这些缓存。这对一些信息发布类网站已经确实适用了。
除了整个页面的缓存技术,还有一种技术叫做“网页片段缓存技术”,将页面的部分而不是全部进行缓存。代表作有ESI cache。
2、数据缓存
但是当WEB2.0兴起的今天,信息的发布已经不再是管理员统一发布的了,而是所有的用户都在发布信息,用户发布完信息后当然是想看到这些信息,而不是等到缓存时间到刷新后才看到这些数据,于是数据缓存的相关技术也就应运而生了。
比较有名的数据缓存框架有ehcache和memcached。
二、ehcache
EhCache 是一个纯Java的进程内缓存框架,具有快速、精干等特点,是Hibernate中默认的CacheProvider,所以被用于大型复杂分布式web application的各个节点中。Ehcache是一种广泛使用的开源Java分布式缓存。主要面向通用缓存,Java EE和轻量级容器。它具有内存和磁盘存储,缓存加载器,缓存扩展,缓存异常处理程序,一个gzip缓存servlet过滤器,支持REST和SOAP api等特点。
优点:
1. 直接在jvm虚拟机中缓存,速度快,效率高;
2. 小巧,使用简单;
缺点:
缓存共享麻烦,不易维护;集群分布式应用不方便。
应用场景:
单个应用或者对缓存访问要求很高的应用。
三、Memcached
Memcached是一套分布式的高速缓存系统,大 致的原理也和ehcache 相同,将数据采用键值的形式存放在内存中,使用时可以将查询的md5作为键,查询的结果作为值。相对ehcache而言,memcached是一个工 具,ehcache是一个框架,memcached更加底层更加灵活,当然你也要写相应的代码去使用它。
memcache通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中,然后从内存中读取,从而大大提高读取速度。
MemCache的工作机制:
检查客户端的请求数据是否在memcached中,如有,直接把请求数据返回,不再对数据库进行任何操作;如果请求的数据不在memcached中,就去查数据库,把从数据库中获取的数据返回给客户端,同时把数据缓存一份到memcached中(memcached客户端不负责,需要程序明确实现);每次更新数据库的同时更新memcached中的数据,保证一致性;当分配给memcached内存空间用完之后,会使用LRU(Least Recently Used,最近最少使用)策略加上到期失效策略,失效数据首先被替换,然后再替换掉最近未使用的数据。这是一张网上的memcached图,说明了memcached在系统中的位置。
Memcached的优点:
Memcached可以利用多核优势,单实例吞吐量极高,可以达到几十万QPS(取决于key、value的字节大小以及服务器硬件性能,日常环境中QPS高峰大约在4-6w左右)。适用于最大程度扛量。支持直接配置为session
handle。
Memcached的局限性:
只支持简单的key/value数据结构,不像Redis可以支持丰富的数据类型。
Memcached单个key-value大小有限,一个value最大只支持1MB,而Redis最大支持512MB
无法进行持久化,数据不能备份,只能用于缓存使用,且重启后数据全部丢失。
无法进行数据同步,不能将MC中的数据迁移到其他MC实例中。
Memcached内存分配采用Slab Allocation机制管理内存,value大小分布差异较大时会造成内存利用率降低,并引发低利用率时依然出现踢出等问题。需要用户注重value设计。
Slab Allocator的基本原理是按照预先规定的大小,将分配的内存分割成特定长度的块,已完全解决内存碎片问题。Slab Allocation 的原理相当简单。将分配的内存分割成各种尺寸的块(chucnk),并把尺寸相同的块分成组(chucnk的集合)如图:
而且slab allocator 还有重复使用已分配内存的目的。也就是说,分配到的内存不会释放,而是重复利用。
Slab Allocation 的主要术语
- Page :分配给Slab 的内存空间,默认是1MB。分配给Slab 之后根据slab 的大小切分成chunk.
- Chunk : 用于缓存记录的内存空间。
- Slab Class:特定大小的chunk 的组。
四、Redis
Redis是用C语言开发的一个开源的高性能键值对(key-value)数据库。它通过提供多种键值数据类型来适应不同场景下的存储需求,目前为止Redis支持的键值数据类型如下:字符串类型、散列类型、列表类型、集合类型、有序集合类型。
Redis的优点:
支持多种数据结构,如 string(字符串)、 list(双向链表)、dict(hash表)、set(集合)、zset(排序set)、hyperloglog(基数估算)
支持持久化操作,可以进行aof及rdb数据持久化到磁盘,从而进行数据备份或数据恢复等操作,较好的防止数据丢失的手段。
支持通过Replication进行数据复制,通过master-slave机制,可以实时进行数据的同步复制,支持多级复制和增量复制,master-slave机制是Redis进行HA的重要手段。
单线程请求,所有命令串行执行,并发情况下不需要考虑数据一致性问题。
支持pub/sub消息订阅机制,可以用来进行消息订阅与通知。
支持简单的事务需求,但业界使用场景很少,并不成熟。
Redis的局限性:
Redis只能使用单线程,性能受限于CPU性能,故单实例CPU最高才可能达到5-6wQPS每秒(取决于数据结构,数据大小以及服务器硬件性能,日常环境中QPS高峰大约在1-2w左右)。
支持简单的事务需求,但业界使用场景很少,并不成熟,既是优点也是缺点。
Redis在string类型上会消耗较多内存,可以使用dict(hash表)压缩存储以降低内存耗用。
Mc和Redis都是Key-Value类型,不适合在不同数据集之间建立关系,也不适合进行查询搜索。比如redis的keys pattern这种匹配操作,对redis的性能是灾难。
Redis的应用场景:
- 缓存(数据查询、短连接、新闻内容、商品内容等等)。(最多使用)
- 分布式集群架构中的session分离。
- 聊天室的在线好友列表。
- 任务队列。(秒杀、抢购、12306等等)
- 应用排行榜。
- 网站访问统计。
- 数据过期处理(可以精确到毫秒)
五、MongoDB
mongoDB 是一种文档性的数据库,主要解决海量数据的访问效率问题。
mongodb与mysql不同,mysql的每一次更新操作都会直接写入硬盘,但是mongo不会,做为内存型数据库,数据操作会先写入内存,然后再会持久化到硬盘中去,那么mongo是如何持久化的呢?
mongodb在启动时,专门初始化一个线程不断循环(除非应用crash掉),用于在一定时间周期内来从defer队列中获取要持久化的数据并写入到磁盘的journal(日志)和mongofile(数据)处,当然因为它不是在用户添加记录时就写到磁盘上,所以按mongodb开发者说,它不会造成性能上的损耗,因为看过代码发现,当进行CUD操作时,记录(Record类型)都被放入到defer队列中以供延时批量(groupcommit)提交写入,但相信其中时间周期参数是个要认真考量的参数,系统为90毫秒,如果该值更低的话,可能会造成频繁磁盘操作,过高又会造成系统宕机时数据丢失过。
1. MongoDB适用案例
1)事件记录
应用程序对事件记录各有需求。在企业级解决方案中,许多不同的应用程序都需要记录事件。文档数据库可以把所有这些不同类型的事件都存起来,并作为事件存储的”中心数据库”使用。如果事件捕获的数据类型一直在变,那么就更应该用文档数据库了。可以按照触发事件的应用程序名”分片”,也可以按照order_processed(表示订单已处理)或customer_logged(表示客户已记录)等事件类型”分片”。
2)内容管理系统及博客平台
由于文档数据没有”预设模式”,而且通常支持JSON文档,所以它们很适合在用”内容管理系统”及网站发布程序上,也可以用来管理用户评论、用户注册、用户配置和面向Web文档。
3)网站分析与实时分析
文档数据库可存储实时分析数据。由于可以只更新部分文档内容,所以用它来存储”页面浏览量”(page view)或”独立访问数”会非常方便,而且无需改变模式即可新增度量标准。分析:鉴于它的弱模式结构,不改变模式下就可以储存不同的度量方法及添加新的度量。
4)电子商务应用程序
电子商务类应用程序通常需要采用较为灵活的模式,以存储产品和订单。同时,它们需要在不做高成本数据库重构及数据迁移的前提下进行其数据模型。
5)日志
企业环境下,每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式,所以我们可以使用它储存不同的信息。
2、MongoDB不适用的场合
1)目前对于事务型业务、以及关联操作业务不适合。
2)在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务,如果对这方面有需求则不应该选择这个解决方案。
六、Nosql
Not Only SQL,其含义是:适合关系型数据库的时候就是用关系型数据库,不适用的时候也没必要非得使用关系型数据库不可,可以考虑使用更加合适的数据存储。
关系型数据库的优势和劣势:
优势:
1、保持数据的一致性(事务处理)
2、由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处)
3、可以进行JOIN等复杂查询
4、存在很多实际成果和专业技术信息(成熟的技术)。
劣势:
1、大量数据的写入处理
2、为有数据更新的表做索引或表结构(schema)变更
3、字段不固定的应用
4、对简单查询需要快速返回结果的处理。
NoSql数据库分为四类,分别为键值(Key-Value)存储数据库/列存储数据库/文档型数据库和图形(Graph)数据库。
分类 | Examples举例 | 典型应用场景 | 数据模型 | 优点 | 缺点 |
键值(key-value) |
Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB |
内容缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统等等。 | Key 指向 Value 的键值对,通常用hash table来实现 | 查找速度快 | 数据无结构化,通常只被当作字符串或者二进制数据 |
列存储数据库 | Cassandra, HBase, Riak | 分布式的文件系统 | 以列簇式存储,将同一列数据存在一起 | 查找速度快,可扩展性强,更容易进行分布式扩展 | 功能相对局限 |
文档型数据库 | CouchDB, MongoDb | Web应用(与Key-Value类似,Value是结构化的,不同的是数据库能够了解Value的内容) | Key-Value对应的键值对,Value为结构化数据 | 数据结构要求不严格,表结构可变,不需要像关系型数据库一样需要预先定义表结构 | 查询性能不高,而且缺乏统一的查询语法。 |
图形(Graph)数据库 | Neo4J, InfoGrid, Infinite Graph | 社交网络,推荐系统等。专注于构建关系图谱 | 图结构 | 利用图结构相关算法。比如最短路径寻址,N度关系查找等 | 很多时候需要对整个图做计算才能得出需要的信息,而且这种结构不太好做分布式的集群方案. |