基于dogpile锁的缓存前端。
dogpile.cache的Python项目详细描述
dogpile由两个子系统组成，一个在另一个之上。
dogpile提供了“dogpile锁”的概念，一种控制结构 它允许选择单个执行线程作为 一些资源，同时允许其他执行线程引用前面的 创建过程中此资源的版本；如果没有以前的 版本，然后这些线程阻塞，直到对象可用。
dogpile.cache是一个缓存api，它为 缓存任何种类的后端，并另外提供api钩子 将这些缓存后端与dogpile的锁定机制集成。
总的来说，dogpile.cache是Beaker缓存系统的替代品，其内部是 是同一作者写的。烧杯的所有“工作”理念- 以更高效和简洁的方式在dogpile.cache中实现，以及 克鲁夫特（烧杯的内部结构最早写于2005年）被降为 垃圾堆。
文档
见dogpile.cache的完整文档 dogpile.cache documentation。这个 以下各节提供了dogpile包的简要概要。
功能
- 一个简洁的api，它鼓励预先定义的 “区域”，每个区域定义一组缓存特性，包括 存储后端、配置选项和默认过期时间。
- 标准的get/set/delete api和函数decoratorapi是 提供。
- 密钥生成机制是完全可定制的。功能 decorator api提供了一个可插入的“密钥生成器”来定制 缓存键与函数调用相对应，并且 “密钥管理器”功能提供可插入的密钥管理 （例如编码、sha-1散列）根据每个区域的需要。
- dogpile锁，最初是作为烧杯后面的核心引擎开发的 缓存系统，这里大大简化、改进和测试。 一些关键性能 烧杯结构固有的问题，尤其是 值通常是从缓存中“双取”的，已被修复。
- 后端实现自己版本的“分布式”锁，其中 “分发”与后端的存储系统匹配。例如， memcached后端允许所有客户端协调值的创建 使用memcached本身。dbm文件后端使用锁文件 在dbm文件旁边。新的后端，比如基于redis的后端， 可以提供适合于存储的自己的锁定机制 引擎。 写新的文件或对现有的文档进行黑客攻击是有意的。 例程-所需要的只是基本的get/set/delete方法。分布的 为后端定制的锁是可选的，否则dogpile使用 一个普通的线程互斥锁。新的后端可以用dogpile.cache注册 直接或通过setuptools入口点提供。
- 包括三个memcached后端（python memcached，pylibmc， bmemcached），一个redis后端，一个基于python的后端 anydbm和一个简单的字典后端。
- 第三方插件的空间，包括提供 从dogpile.cache引擎到mako模板。
欢迎加入QQ群-->： 979659372
