后端常用缓存
‘壹’ magento如何实施正确的缓存策略以达到最佳性能
本篇文章主要介绍一下在maegnto里cache(File System, APC, Memcached, Redis)的使用，及在不同的服务器环境中改怎么使用让其性能达到最佳。
理解magento的Two-Level Caching
magento默认使用zend framework的二层缓存存储方式。就是说它使用两层结构对cache进行配合管理，一个快的，但大小有限制的结构是一层比如APC或者Memcached ，一个比较慢的结构作为第二层比如file system.每一种存储结构各有利弊，要不同情况不同分析使用，APC 和 Memcached 是使用 key/value来存储cache，他们都不支持tag。File system 和Redis 支持tag.
magento二级缓存结构工作流程图示 (Thanks to Fabrizio Branca)：
magento自带的各种后端缓存介绍：
File system (var/cache)
默认情况下，Magento 将它的缓存条目存储在file系统中，在var/cache/下可查看。这种情况很适合小型的，数据量不大的站点。但是对于大型的站点，随着浏览量的不断增多，对file的读写操作也将越来越多，站点也会越来越慢。magento是由tags来对cache进行组织管理的，这意味着可以对某一个cache组（相同的tag为一个group）进行操作。
优点：这是默认的，不需要装额外的软件
缺点：清除cache依赖于tag，通常修改某个proct或处理某个order完之后，对应的前台页面都需要更新缓存。每次更新缓存时，都需要根据tag进行所有条目即file进行查找，试想如果站点有多于1000个proct，整个cache的大小将会大于50MB，大约有3500个file，你能想象到每次更新cache都要对3500个file进行查找有多慢吗。
小提示
1：使用 SSD 替代普通硬盘
2：把var/cache接入 tmpfs
----------------------------------------------------------------------------------------------------------------------------------
APC – Alternative php Cache (Key/Value)
APC是一个免费，开源且强健的框架用来缓存和优化 PHP 的中间代码。
优点：相对于file cache system是很快了
缺点:不支持tag，所以依然需要file system作为slow level cache。服务器需要安装PHP APC 模块
小提示：确保有足够的内存给APC ，可在 php.ini 中修改参数apc.shm_size
Configuration (app/etc/local.xml)
<global>
...
<cache>
<backend>apc</backend>
<prefix>mgt_</prefix>
</cache>
...
</global>
Settings for php.iniapc.enabled = 1
apc.optimization = 0
apc.shm_segments = 1
apc.shm_size = 768M
apc.ttl = 48000
apc.user_ttl = 48000
apc.num_files_hint = 8096
apc.user_entries_hint = 8096
apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.enable_cli = 1
apc.cache_by_default = 1
apc.max_file_size = 10M
apc.include_once_override = 0
---------------------------------------------------------------------------------------------------------------------------
Memcached (Key/Value)
Memcache是一个高性能的分布式的内存对象缓存系统，通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中，然后从内存中读取，从而大大提高读取速度。
优点：更快的存取速度
缺点：不支持tag，所以依然需要file system作为slow level cache
需求：1：Memcached server 2： PHP extension for memcached
Configuration (app/etc/local.xml)<global>
...
<cache>
<backend>memcached</backend><!-- apc / memcached / empty=file -->
<memcached><!-- memcached cache backend related config -->
<servers><!-- any number of server nodes can be included -->
<server>
<host><![CDATA[127.0.0.1]]></host>
<port><![CDATA[11211]]></port>
<persistent><![CDATA[1]]></persistent>
</server>
</servers>
<compression><![CDATA[0]]></compression>
<cache_dir><![CDATA[]]></cache_dir>
<hashed_directory_level><![CDATA[]]></hashed_directory_level>
<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
<file_name_prefix><![CDATA[]]></file_name_prefix>
</memcached>
</cache>
...
</global>
---------------------------------------------------------------------------------------------------------------------
Redis – Advanced key-value store with full cache tag support
magento允许我们使用redis server作为中央存储仓库，它支持tag的使用，所以不再需要file system作为slow level cache。在多服务器多站点环境中，强烈推荐使用redis
，用一个中央缓存仓库，对所有server cache进行管理。
优点：快；支持tag；已在一个日均ip为500000的站点做过测试，性能极好且稳定。
需求：1：服务器上需要装Redis 2：PHP 扩展 phpredis 需要安装 3：Magento扩展“Cm_Cache_Backend_Redis”需要安装
Installation
1. Install redis (2.4+ required)
2. Install phpredis
3. Install the magento extension “Cm_Cache_Backend_Redis”
4. Edit your app/etc/local.xml
<global>
...
<cache>
<backend>Cm_Cache_Backend_Redis</backend>
<backend_options>
<server>127.0.0.1</server> <!-- or absolute path to unix socket -->
<port>6379</port>
<persistent></persistent>
<database>0</database>
<password></password>
<force_standalone>0</force_standalone>
<connect_retries>1</connect_retries>
<automatic_cleaning_factor>0</automatic_cleaning_factor>
<compress_data>1</compress_data>
<compress_tags>1</compress_tags>
<compress_threshold>20480</compress_threshold>
<compression_lib>gzip</compression_lib> <!-- Supports gzip, lzf and snappy -->
</backend_options>
</cache>
...
</global>
转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦
‘贰’ 如何利用Nginx的缓冲，缓存优化提升性能
反向代理的一个问题是代理大量用户时会增加服务器进程的性能冲击影响。在大多数情况下，可以很大程度上能通过利用Nginx的缓冲和缓存功能减轻。
当代理到另一台服务器，两个不同的连接速度会影响客户的体验：
从客户机到Nginx代理的连接。
从Nginx代理到后端服务器的连接。
Nginx具有优化这些连接调整其行为的能力。
如果没有缓冲，数据从代理的服务器发送并立即开始被发送到客户。如果假定客户端很快，缓冲可以关闭而尽快使数据到客户端，有了缓冲，Nginx 代理将暂时存储后端的响应，然后按需供给数据给客户端。如果客户端是缓慢的，允许Nginx服务器关闭到后端的连接。然后，它可以处理数据分配到客户端， 以任何可能的速度。
Nginx默认有缓冲设计，因为客户端往往有很大的不同的连接速度。我们可以用以下指令调节缓冲行为。可以在HTTP，server或 location位置来设置。重要的是要记住，大小size指令是针对每个请求配置的，所以增加超出你需求会影响你的性能，如果这时有许多客户端请求：
proxy_buffering：该指令控制缓冲是否启用。默认情况下，它的值是“on”。
proxy_buffers：该指令控制代理响应缓冲区的数量（第一个参数）和大小（第二个参数）。默认配置是8个缓冲区大小等于一个内存页（4K或者8K）。增加缓冲区的数目可以让你缓冲更多信息。
proxy_buffer_size：从后端服务器的响应头缓冲区大小，它包含headers，和其他部分响应是分开的。该指令设置响应部分的缓冲区大小。默认情况下，它和proxy_buffers是相同的尺寸，但因为这是用于头信息，这通常可以设置为一个较低的值。
proxy_busy_buffers_size：此指令设置标注“client-ready”缓冲区的最大尺寸。而客户端可以一次读取来自一个缓冲区的数据，缓冲被放置在队列中，批量发送到客户端。此指令控制允许是在这种状态下的缓冲空间的大小。
proxy_max_temp_file_size：这是每个请求能用磁盘上临时文件最大大小。这些当上游响应太大不能装配到缓冲区时被创建。
proxy_temp_file_write_size：这是当被代理服务器的响应过大时Nginx一次性写入临时文件的数据量。
proxy_temp_path：当上游服务器的响应过大不能存储到配置的缓冲区域时，Nginx存储临时文件硬盘路径。
正如你所看到的，Nginx提供了相当多的不同的指令来调整缓冲行为。大多数时候，你不必担心太多，但它对于调整一些值可能是有用的。可能最有用的调整是proxy_buffers和proxy_buffer_size指令。
‘叁’ nginx缓存和后端服务器负载均衡
后端群集是为了平衡来自前端的请求。通常是为了减轻单独后端处理的压力（尤其各种动态网页），但又不希望使用缓存，使得客户端不能看到最新页面。倘若前端做了缓存，那么前端就不会对后端发送请求，取而代之，从缓存调用。所以请求不会去后端，也就看不到最新页面。
所以说...缓存+群集后端要闹哪样啊？
‘肆’ 一般项目为了解决什么问题而使用redis
redis是内存数据库，访问速度非常快，所以能够解决的也都是这些缓存类型的问题，如下：
1、会话缓存（Session Cache）
最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？
幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
2、全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。
再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。
此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
3、队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。
‘伍’ 如何缓存一个block
magento是基于zend framework的，所以cache的使用基本也继承了他的一些特性。我们要知道缓存中有几个重要的概念:
数据本身；数据的标识；缓存生命期；缓存操作接口;
Zend_Cache 的使用比较简单, 它可以把数据保存到 File, Memcache, sqlite 等介质(称为后端, Backend)中. 还有前端(Frontend), 主要用来对要缓存的数据进行转换, 如序列化.
Zend Framework 后端主要有
apc (Zend_Cache_Backend_Apc),
files (Zend_Cache_Backend_File),
memcached (Zend_Cache_Backend_Memcached)
and some more..
Magento 增加了几种：
database (Varien_Cache_Backend_Database)
eaccelarator (Varien_Cache_Backend_Eaccelarator).
为了更深入的理解magento cache，本文就以缓存某个block为例，分析下他的工作流程和原理。在magento中，所有的block都是继承自Mage_Core_Block_Abstract，当输出某个block到页面时，会调用到这个类的toHtml方法，该方法中有如下code片段：
[php] view plain
$html = $this->_loadCache();//加载缓存，假设为第一次加载，还没有被缓存过，进入if代码段
if ($html === false) {
$translate = Mage::getSingleton('core/translate');
/** @var $translate Mage_Core_Model_Translate */
if ($this->hasData('translate_inline')) {
$translate->setTranslateInline($this->getData('translate_inline'));
}
$this->_beforeToHtml();
$html = $this->_toHtml();
$this->_saveCache($html);//这句代码很简单，但却在内部完成了大量的工作，下面进入它内部深入分析
if ($this->hasData('translate_inline')) {
$translate->setTranslateInline(true);
}
}
继续看本类中的function _saveCache($data)
[php] view plain
function _saveCache($data)
/**
* Save block content to cache storage
*
* @param string $data
* @return Mage_Core_Block_Abstract
*/
protected function _saveCache($data)
{
if (is_null($this->getCacheLifetime()) || !Mage::app()->useCache(self::CACHE_GROUP)) {
return false;
}
$cacheKey = $this->getCacheKey();
/** @var $session Mage_Core_Model_Session */
$session = Mage::getSingleton('core/session');
$data = str_replace(
$session->getSessionIdQueryParam() . '=' . $session->getEncryptedSessionId(),
$this->_getSidPlaceholder($cacheKey),
$data
);
//可以肯定进入了Mage_Core_Model_App 的function saveCache
Mage::app()->saveCache($data, $cacheKey, $this->getCacheTags(), $this->getCacheLifetime());
return $this;
}
打开Mage_Core_Model_App 的function saveCache
[php] view plain
/**
* Saving cache data
*
* @param mixed $data
* @param string $id
* @param array $tags
* @return Mage_Core_Model_App
*/
public function saveCache($data, $id, $tags=array(), $lifeTime=false)
{
$this->_cache->save($data, $id, $tags, $lifeTime);
return $this;
}
可以看到$this->_cache这个对象调用了save，继续看$this->_cache到底属于哪个类的实例，在本类中找到protected function _initCache()，code如下：
[php] view plain
/**
* Initialize application cache instance
*
* @return Mage_Core_Model_App
*/
protected function _initCache()
{
$this->_isCacheLocked = true;
$options = $this->_config->getNode('global/cache');
if ($options) {
$options = $options->asArray();
} else {
$options = array();
}
//实例化Mage_Core_Model_Cache，并传入参数$options
$this->_cache = Mage::getModel('core/cache', $options);
$this->_isCacheLocked = false;
return $this;
}
上面Mage::getModel('core/cache', $options)的$options是app/etc/local.xml中节点global/cache下的配置，假设ocal.xml如下：
[html] view plain
<config>
<global>
<cache>
<backend>apc</backend>
<slow_backend>File</slow_backend>
<auto_refresh_fast_cache>1</auto_refresh_fast_cache>
<prefix>MYSHOP_</prefix>
<default_priority>10</default_priority>
</cache>
</global>
</config>
能看到$this->_cache是实例化了实例化Mage_Core_Model_Cache，所以Mage_Core_Model_App 中的$this->_cache->save($data, $id, $tags, $lifeTime)即调用的Mage_Core_Model_Cache的function save。进入Mage_Core_Model_Cache的save：
[php] view plain
/**
* Save data
*
* @param string $data
* @param string $id
* @param array $tags
* @param int $lifeTime
* @return bool
*/
public function save($data, $id, $tags=array(), $lifeTime=null)
{
/**
* Add global magento cache tag to all cached data exclude config cache
*/
if (!in_array(Mage_Core_Model_Config::CACHE_TAG, $tags)) {
$tags[] = Mage_Core_Model_App::CACHE_TAG;
}
return $this->_frontend->save((string)$data, $this->_id($id), $this->_tags($tags), $lifeTime);
}
可以看到$this->_frontend->save(...)这句,那么这里的_frontend是什么呢？继续看此类的构造函数(只列出部分code)：
[php] view plain
$backend = $this->_getBackendOptions($options);
$frontend = $this->_getFrontendOptions($options);
$this->_frontend =Zend_Cache::factory('Varien_Cache_Core', $backend['type'], $frontend, $backend['options'],true, true, true);
没错_frontend就是类Varien_Cache_Core的一个实例，因为Varien_Cache_Core是继承自Zend_Cache_Core，所以这里_frontend实际上实例化的是Zend_Cache_Core，即调用的是Zend_Cache_Core的save，再继续分析，打开Zend_Cache_Core，找到function save它里面包含了如下代码片段：
[php] view plain
if (($this->_extendedBackend) && ($this->_backendCapabilities['priority'])) {
$result = $this->_backend->save($data, $id, $tags, $specificLifetime, $priority);
} else {
$result = $this->_backend->save($data, $id, $tags, $specificLifetime);
}
可以看到这里实际上又变成了_backend的来调用的save，(开头我们已经说了backend是用来保存数据的),那么这里_backend到底是哪个backend(file,db,apc...)呢？继续分析,在这个类里面有一个方法setBackend：
[php] view plain
/**
* Set the backend
*
* @param Zend_Cache_Backend $backendObject
* @throws Zend_Cache_Exception
* @return void
*/
public function setBackend(Zend_Cache_Backend $backendObject)
{
$this->_backend= $backendObject;
// some options (listed in $_directivesList) have to be given
// to the backend too (even if they are not "backend specific")
$directives = array();
foreach (Zend_Cache_Core::$_directivesList as $directive) {
$directives[$directive] = $this->_options[$directive];
}
$this->_backend->setDirectives($directives);
if (in_array('Zend_Cache_Backend_ExtendedInterface', class_implements($this->_backend))) {
$this->_extendedBackend = true;
$this->_backendCapabilities = $this->_backend->getCapabilities();
}
}
里面有$this->_backend= $backendObject这句，$backendObject是传入的参数，那么是何时调用的setBackend呢？实际上，这个方法是在上边Mage_Core_Model_Cache里的save方法中调用$this->_frontend = Zend_Cache::factory('Varien_Cache_Core', $backend['type'], $frontend, $backend['options'], true, true, true);这句的的时候，已经被调用了，可以打开Zend_Cache的factory 方法查看，会发现有一句$frontendObject->setBackend($backendObject);参数$backendObject是factory传入的参数$backend['type']，$backend['type']到底是什么呢，我们在Mage_Core_Model_Cache的构造函数中看到$backend=$this->_getBackendOptions($options)这句，所以$backend是在本类的_getBackendOptions中被设置的，找到_getBackendOptions,code如下：
[php] view plain
/**
* Get cache backend options. Result array contain backend type ('type' key) and backend options ('options')
*
* @param array $cacheOptions
* @return array
*/
protected function _getBackendOptions(array $cacheOptions)
{
$enable2levels = false;
$type = isset($cacheOptions['backend']) ? $cacheOptions['backend'] : $this->_defaultBackend;
if (isset($cacheOptions['backend_options']) && is_array($cacheOptions['backend_options'])) {
$options = $cacheOptions['backend_options'];
} else {
$options = array();
}
$backendType = false;
switch (strtolower($type)) {
case 'sqlite':
if (extension_loaded('sqlite') && isset($options['cache_db_complete_path'])) {
$backendType = 'Sqlite';
}
break;
case 'memcached':
if (extension_loaded('memcache')) {
if (isset($cacheOptions['memcached'])) {
$options = $cacheOptions['memcached'];
}
$enable2levels = true;
$backendType = 'Memcached';
}
break;
case 'apc':
if (extension_loaded('apc') && ini_get('apc.enabled')) {
$enable2levels = true;
$backendType = 'Apc';
}
break;
case 'xcache':
if (extension_loaded('xcache')) {
$enable2levels = true;
$backendType = 'Xcache';
}
break;
case 'eaccelerator':
case 'varien_cache_backend_eaccelerator':
if (extension_loaded('eaccelerator') && ini_get('eaccelerator.enable')) {
$enable2levels = true;
$backendType = 'Varien_Cache_Backend_Eaccelerator';
}
break;
case 'database':
$backendType = 'Varien_Cache_Backend_Database';
$options = $this->getDbAdapterOptions();
break;
default:
if ($type != $this->_defaultBackend) {
try {
if (class_exists($type, true)) {
$implements = class_implements($type, true);
if (in_array('Zend_Cache_Backend_Interface', $implements)) {
$backendType = $type;
}
}
} catch (Exception $e) {
}
}
}
if (!$backendType) {
$backendType = $this->_defaultBackend;
foreach ($this->_defaultBackendOptions as $option => $value) {
if (!array_key_exists($option, $options)) {
$options[$option] = $value;
}
}
}
$backendOptions = array('type' => $backendType, 'options' => $options);
if ($enable2levels) {
$backendOptions = $this->_getTwoLevelsBackendOptions($backendOptions, $cacheOptions);
}
return $backendOptions;
}
代码有些长，但这个方法很重要，后端具体使用什么类型存储缓存都是在这里被设置和转换的，有代码分析可知，默认的Backend为file，其他有sqlite, apc, memcached, xcache, eaccelerator, database等几种类型，当backend是memcached, apc,xcache时，magento就自动开启two level cache，具体设置可以自行看function _getTwoLevelsBackendOptions。
‘陆’ 三分钟读懂redis数据库
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
1. 使用Redis有哪些好处？
(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
(2) 支持丰富数据类型，支持string，list，set，sorted set，hash
(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
2. redis相比memcached有哪些优势？
(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
(2) redis的速度比memcached快很多
(3) redis可以持久化其数据
3. redis常见性能问题和解决方案：
(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...
这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。
4. MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据
相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：
voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据
相关推荐：《Python视频教程》
5. Memcache与Redis的区别都有哪些？
1)、存储方式
Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
Redis有部份存在硬盘上，这样能保证数据的持久性。
2)、数据支持类型
Memcache对数据类型支持相对简单。
Redis有复杂的数据类型。
3），value大小
redis最大可以达到1GB，而memcache只有1MB
6. Redis 常见的性能问题都有哪些？如何解决？
1).Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。
2).Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3).Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
4). Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内
7. redis 最适合的场景
Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：
1.Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2.Redis支持数据的备份，即master-slave模式的数据备份。
3.Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
（1）会话缓存（Session Cache）
最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？
幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
（2）全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。
再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。
此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
（3）队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。
（4）排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：
当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。
（5）发布/订阅
最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。
‘柒’ Django 4.0 正式发布，新的密码哈希器和 Redis 缓存后端
Django 4.0 正式发布，4.0 版本支持 Python 3.8、3.9 和 3.10。随着 Django 4.0 的发布，Django 3.2 的主流支持已经结束。此版本主要有如下亮点：
重要更新
zoneinfo 作为默认时区
Django 3.2 允许使用非 pytz 时区。Django 4.0 是 zoneinfo 作为默认时区：弃用 pytz 且将在 Django 5.0 中删除它。zoneinfo 是 Python 3.9 标准库的一部分，如果你在使用 Python 3.8 ，则会自动安装 zoneinfo 包。
注意，如果你处于非 utc（世界标准时间） 时区，且在使用 pytz normalize() 和 localalize () api，那你可能设置了TIME_ZONE ，需要审查一下代码。4.x 系列版本周期有一个过渡性的 use_depreccated_pytz 设置，允许从 pytz 慢慢过渡到 zoneinfo ，这个设置将在 Django 5.0 中删除。
此外，zoneinfo 作者创建的 pytz_deprecation_shim 包用于帮助从 pytz 进行迁移，这个包提供 shims 来安全地移除 pytz ，还有一个详细的迁移指南，展示如何移动到新的 zoneinfo api。渐进更新可以用 pytz_deprecation_shim和use_depreccated_pytz 这两个过渡设置。
函数的唯一约束
UniqueConstraint() 的新 *expressions 位置参数可以在表达式和数据库函数上创建函数式唯一约束。例如：
使用该 Meta.constraints 选项将函数唯一约束添加到模型中 。
增加 scrypt 密码哈希器
新的 scrypt 密码哈希器比 PBKDF2 更安全，建议使用。但它不是默认选项，因为它需要 OpenSSL 1.1 以上版本和更多的内存。
Redis 缓存后端
新的 django.core.cache.backends.redis.RedisCache 缓存后端为使用 Redis 缓存提供了内置支持。此功能 需要 redis-py 3.0.0 或更高版本。
基于模板的表单渲染
使用模板引擎渲染表单，如用于表单的 render() , get_context() 和 template_name ，用于表单集的 五个渲染相关的属性和方法 。
次要更新项：
django.contrib.admin
django.contrib.auth
django.contrib.gis
django.contrib.postgres
django.contrib.staticfiles
缓存
新的异步 API： django.core.cache.backends.base.BaseCache 开始使缓存后端异步兼容。新的异步方法都有 a 前缀的名称，例如 aadd() ， aget() ， aset() ， aget_or_set() ，或 adelete_many() 。
以后 a 前缀一般会用于方法的异步变体。
CSRF
国际化
通用视图
DeleteView 现在使用 FormMixin ，允许您提供一个 Form 子类，例如带有确认删除之类的复选框。
日志
管理命令
模块
请求和响应
信号
模板
测试 ¶
Django 4.0 是一个超大版本更新，除了上述更新以外还包含一些功能的弃用，以及不向后兼容的更新项，完整版更新内容可在 更新公告 中查看。
‘捌’ 我用java在后端集成了redis作为缓存，mysql数据库记录了经纬度的信息，
经纬度信息一般不怎么变化，可以先放到redis中去建立索引，后面app端直接查询缓存就可以了，比较快！
‘玖’ redis主要解决什么问题
redis是内存数据库，访问速度非常快，所以能够解决的也都是这些缓存类型的问题，如下：
1、会话缓存（Session Cache）
最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？
幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
2、全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。
再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。
此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
3、队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。
排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：
当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。
5、发布/订阅
最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。
Redis提供的所有特性中，我感觉这个是喜欢的人最少的一个，虽然它为用户提供如果此多功能。
等等？
‘拾’ 一个网站从前端到后端有哪些可以缓存的地方
页面、数据都可以缓存