redis支持的金字塔web框架会话工厂
pyramid-session-redis的Python项目详细描述
重要的
==
开发人员的便利性。
此软件包现在遵循多版本发布过程。
1.2.x分支从1.2.2开始处于维护模式，最终将发布1.3.0版。
1.4.x分支正在积极开发中，随时可能更改。它将在一个稳定的1.5.0API版本中达到高潮。
----
1.2.x分支和更早的分支与"金字塔Redis会话"基本兼容。如果您正在使用此功能，则应将您的安装固定到"<；=1.3.0"或"<；1.3"。
有些夸尔格可能已经改变了。软件包的结构也发生了变化，利用内部机制的高级用户将需要升级。包仍然是即插即用金字塔会话接口。
重要提示：内部负载结构在1.4分支中已更改，不再与现有的1.2会话兼容（它们将无效）。我对可以处理优美回退的prs开放。
像这样：
{m'：{}，
'c'：int，
'v'：会话api'u版本，
session int
r
*现在使用API版本，以处理将来的优雅更改
*不再保证存在超时（现在可以在redis上处理）
*也可能存在过期超时
s包可能比原始项目更可取。与最初的实现相比，这个包大大减少了redis和pyramid之间的通信。还提供了一些选项来最小化有效负载的大小。
此包包含许多挂钩和功能，以帮助在高流量情况下使用此功能的开发人员。此包不推荐"最佳部署"，但提供了在不同情况下创建最佳部署的不同策略。
到1.2.x
----
*原始包在大多数属性访问和写入上与redis通信。某些实现上的通信量可能太大。`棱锥体会话redis将使用棱锥体的add_finished_callback挂钩将单个"persist"或"refresh"任务排队。
*使用的原始版本"exists"检查会话是否存在，然后继续"get"或"set"新会话。`金字塔会话redis将立即尝试"get"，并在失败时"设置"一个新会话。这就消除了一个调用。
*对"set"和"expire"的单独调用替换为单个"setex"
*可以设置一个标志来启用lru缓存（最近使用最少的）模式。不会向redis发送过期数据，允许redis服务器处理lru逻辑本身
*活动的"session"与请求属性分离（即，这可以处理在备用属性上设置的"session"）
*原始库不会检测到嵌套字典中的更改此包使用"hashlib.md5"在读取时对序列化值进行指纹识别；如果未检测到任何更改，则故障保护将对+md5数据进行序列化，以确定是否应进行写入。这可以通过将"检测更改"设置为false来禁用。
*如果会话无法反序列化，则inal会引发致命错误。通过向构造函数传入"反序列化失败"new，可以在反序列化错误时创建新会话。
*通过"func\u check"response\u allow\cookies支持禁用cdn生成内容上的会话
*由于@github/hongyuan1306，令牌生成已合并到uSe python3的stdlib（如果不可用，则重新实现）。令牌也是32个字符，而不是20个字符。
*在lru模式下支持redis（请参阅http://redis.io/topics/lru-cache），方法是将"set_redis_ttl"设置为"false"（默认情况下为"true"）。这将消除对"expire"的调用，并将使用"set"而不是"setex"。
*在1.2.x分支中，创建的时间可以通过"use-int-time=true"设置为整数。这将通过"int（math.ceil（time.time（））"强制转换"created"时间。这可以将有效负载减少几位。
其他更新1.4.x+
===
*仅支持int（）时间。
*会话现在具有版本控制，可以通过"version"`v`键支持将来的升级。
*重写了内部有效负载的格式，编码的paylo广告现在使用一个字母的键而不是单词。这应该会抵消expires时间戳和版本id的添加。
*没有python超时控制的逻辑（呜呜！）这个问题已经解决了。"expires"`x`键现在跟踪过期时间。
*添加了一个"timeout_trigger"选项。这将延迟到期数据更新以降低redis的使用率。下面将更详细地解释这一点。
*在高负载情况下，redis可能会有性能和存储问题，因为在原始包中，sessionid是根据每个请求创建的（例如被不尊重会话的botnet刺穿）。在这个包中，使用了"lazycreate"方法。除非回调例程中需要会话，否则不会生成会话id/cookie。为了预先生成会话id/cookie，可以使用"redissession.sure\u id"函数。若要安全检查会话ID是否存在，还可以使用"redissession.session\u id\u safecheck"方法。
*向构造函数添加了"func\u invalid\u logger"。这可用于记录无效会话。当与statsd系统集成时，它非常有用。（见下文）
*向工厂和会话构造函数添加了"set_redis_ttl_readheavy"。此选项将通过在管道中同时执行get+expire来优化已由redis维护ttl的会话。
注意：
=
如果"set\u redis\u ttl"为false，则并不意味着根本没有超时--只是redis不会通过"setex"发送超时数据。`或者"过期"。超时数据仍将存储在python中。
l与存储在redis中的超时数据进行比较。
如果您不希望会话超时，请将初始的"timeout"设置为"0"或"none"。
`设置redis ttl`；它也不需要启用"timeout_trigger"或"python_expires"。
_ redis-ttl=true
python中没有超时，没有redis-ttl（仅"set"使用）
timeout=0或none
假设redis-ttl=true
timeout触发器
=======
timeout触发器可用于限制更新/写入的数量。这可能对你的使用模式更有利。
独立使用的不同内部数据存储区：一个用于密钥的有效负载，另一个用于密钥的到期。
在"经典"行为中（这个项目是从其派生的）：每次访问现有会话时，get后面都会向redis发送一个新的到期时间，实际上永远不会y"read"对应redis跟踪的到期记录有一个"write"。
为了通过setex最小化写入，我引入了超时触发器。触发器的工作原理是在redis数据负载中存储一些超时信息，并使用这些信息来确定何时发送写操作。不是每次读取都有get+expire，我们只有一个get并消除由expire引起的写操作。但这需要维护成本-一旦我们触发超时触发器，而不仅仅是get，我们需要更新内部超时负载并发出设置。
回到您的情况：当用户在40分钟内停止活动时，如果启用了超时触发器，则永远不会有是自会话首次创建以来有关用户活动的内部负载或redis的更新。触发器的目的是推迟"写入"操作。
为了使会话在大约一小时内对"读取"有效，您需要执行以下操作：
*一个10分钟触发器的两小时会话，或
*一个50分钟触发器的一小时会话
也可以通过将触发器设置为0来禁用该功能。每天多达几千个用户，您不应该对"经典"模式的开销有任何问题。当您访问了10000个用户和/或开始让群集Web服务器与专用的Redis实例通信时，设置每次读取操作后的新过期时间就成了您要避免的事情。
Scenario 1-Classic Redis
----
ic"redis usage pattern，会话使用通过每个会话视图上的"expire"调用刷新
这很有用，但意味着许多会话操作将触发两个redis调用（`get`+`expire`）。在高性能系统上，这可能是一个很大的问题。
>这是一个典型的刷新场景：
>timeout=200 `
/>2个00 `get`+`expire` 400
300 `get`+`expire` 500
400 `get`+`expire` 600
500 `get`+`expire` 700
scenario 2-超时触发器
on的"timeout"。
当当前时间在到期后600秒内
```
timeout=1200
timeout_trigger=600
```
将发生以下时间线
`*| 1200 600
1 `获取1200 600
…||||
599 `获取1200 600
600 `获取`+`设置1800 1200
601 `获取1800 1200
…||||
1199 ` get ` 1800 1200
1200 ` get `+` set `*2400 1800
此方法与通过"setex"在redis中设置ttl兼容，如果redis处于lru模式，则在python中执行所有操作
在达到阈值之前删除所有"expire"调用，该阈值可以是在重读情况下可减少的存储量
此方法的注意事项：有效负载内必须存储到期时间戳，更新超时需要"set"操作。
set_redis_ttl_read heavy
=====br/>
这是"1.4.2"中的一个新选项，sh会提高readheavy安装的性能，但可能会降低writeheavy安装的性能。此选项将在每次读取时聚合一个get+expire。
"设置redis ttl ttl readheavy"需要以下条件：
*设置一个"超时"值
*"设置redis ttl"为"真"
*"超时"触发器未设置
*"python\expires"为"假"
在只读请求中是这样的：
*在会话访问中，通过"redis.get{session{id}
*在棱锥回调中，通过"redis.expire{session{id}{expire}`
>在读写期间：
*在会话访问中，通过"redis.get{session{id}
*在金字塔回调，通过"redis.setex{session{id}{payload}{expiry}`
如果启用，在只读请求期间，redis实例上的行为将更轻：
*在会话访问时，使用两个redis命令打开管道：`pipeline.get{session{id}`，`pipeline.expire{session{id}{expirey}`.
*在棱锥回调中，重复的expire将被抑制。
但是在读写过程中，活动是：
*在会话访问时，使用两个redis命令打开一个管道：`pipeline.get{session id}'，`pipeline.expire{session id}{expirey}`.
*在金字塔回调中，通过`redis.setex{session id}{payload}{expire}`
读重应用程序应该通过piplined get+expire看到一个轻微的性能提升，但是写重应用程序可能会看到性能下降，因为它会给每个请求增加一个额外的expire。
IS库是在遇到错误的会话数据（如ID无效的cookie或损坏的数据存储）时自动创建新会话。优雅的"新会话"是最终用户的理想状态。
.
这可用于跟踪安全捕获和静默升级的无效会话
如何进行？该包使用"金字塔会话"redis.exceptions.invalidSession`
离子无效，因为没有cookie。这与"新会话"相同。
*`` InvalidSession\u NotInBackend（InvalidSession）``会话ID不在后端
*`` InvalidSession\u反序列化错误（InvalidSession）``反序列化错误。如果"反序列化失败"为true，则会引发此问题。否则，异常将被包装在"rawdeserializationerror"中并在未被捕获的情况下引发。
*``invalidSession\u payloadTimeout（invalidSession）``内部python负载超时
*``invalidSession\u payloadLegacy（invalidSession）``会话在早期版本上运行
工厂接受"func"无效的"logger"可调用参数。输入是在生成新cookie之前引发的异常，将是请求和"invalidSession"的实例。
_记录器（请求，引发的异常）：
"
引发的异常将是InvalidSession的一个实例e对于度量的statsd异常
"
如果是instance（引发的异常，无效会话nosessioncookie）：
statsd_client.incr（'invalid_session.nosessioncookie'）
elif isiinstance（引发的异常，无效会话notinbackend）：
statsd_client.incr（'invalid_session.notinbackend'）
elif isinstance（引发异常，invalidSession反序列化错误）：
statsd_client.incr（'invalid_session.deserializationerror'）
…
）
"func_invalid_logger"参数可以在设置文件中以点符号字符串的形式提供。
未捕获错误
==
zed_fails_new"不是"true"。第一个参数将是捕获的异常。这允许跨多个反序列化选项出现标准错误。
常见问题解答：
==
==
=1.4.x版本的API有点混乱。
[]创建新会话仍需要2个set/setex调用一个用于占位符，下一个用于更新。这应该合并为一个。
进一步阅读：
==
==
>有关python下的redis性能的更多信息，请参阅相关项目：
*https://github.com/jvanasco/dogpile_backend廑redis廑advanced
直到2016年11月这是维护为"jvanasco/pyramd_redis_sessions"
*jvanasco/pyramd_redis_sessions的主分支是"custom_deployment"
*从2016年11月起，名为"master"的分支是来自ericrasmussen的上游源
，这被分到了自己的项目中，以允许分发ion.
所有支持都通过github处理：https://github.com/jvanasco/pyramid_session_redis
overview
==
pyramid_redis_sessions是金字塔Web的服务器端会话库
RK，使用redis存储。这个库
实现了"金字塔iSession接口"lt；http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interface s.html\pyramid.interfaces.iSession>；` `.
表。当您的数据可以
放入内存时，它工作得最好，但它是可配置的，并且在需要将
同步到磁盘时仍然非常快。如果您想了解它的用例，有很多现有的基准测试、意见和文章。但是对于"金字塔Redis会话"，我特别感兴趣，原因如下：
*它真的很快（选择你自己的咒语）
*它有一个非常方便的内置机制来设置键的过期时间
*手表机制是一个很好的、轻量级的替代full事务
*会话数据通常很重要，但不是关键任务，但如果它是…
*它具有可配置的"持久性"lt；http://redis.io/topics/persistence>；`
/>`入门<；http://pyramid redis sessions.read the docs.org/en/latest/getting started.html>；`
指南。
您还可以在阅读文档时阅读
`完整文档<；http://pyramid redis sessions.readthedocs.org/en/latest/index.html>；`
支持
=======
我的尼克是伊拉斯马斯，
但如果我不在，你还可以很明显，可以从其他许多熟悉的常客那里获得支持。
有关详细信息，请参见
`license.txt<；https://github.com/ericrasmussen/pyramid廑redis廑u sessions/blob/master/license.txt>；`廑
===
==
=
-未发布的
*跳过1.3版本。目前没有足够的使用量来保证向后兼容
*一堆api更改来支持延迟创建的会话。原始结构将立即创建会话，这可能会导致bots和spidering的问题。
-2019/04/27
*版本1.5.0
*使用6来处理python3，而不是使用一些自制的东西
-10/17/2017
*版本1.4.2
*将默认超时触发器设置为"none"（问题12，从11分叉）
*已将"金字塔会话"迁移到"redis session"。"已完成回调"迁移到"redissession"。"已延迟回调"
*为读取密集型部署引入了新的"set_redis_ttl_readheavy"选项
-10/17/2017
*版本1.4.1
*修复了1.4.0上的部署错误，该错误的readme中包含非ascii字符
*忘记rUN Python3测试
-10/17/2017
*版本1.4.0
*更新的弃用警告
*准备不在每个访问上创建会话。不使用会话的机器人程序对redis进行spidered会损害redis。
*将"util.get_unique_session_id"重命名为"util.create_unique_session_id`
*添加了"util.empty_session_payload`
*将一些redis session factory函数迁移到了一个更全局（不是每个请求）的块中
*将"func_invalid_logger"添加到session factory，还r命名的内部异常。他们不是一个公共的API，所以不存在不推荐的问题。
*这在我们的生产使用中似乎很好，所以可以实时推送。
-1/24/2017:
*版本1.2.2
*合并了来自Chad Birch（@deimos）的大部分拉取请求https://github.com/jvanasco/pyramd_session_redis/pull/3
*澄清了文档中的假设_redis_ru，添加了tests
*将"force\u redis\u ttl"kwarg添加到"redisession.do\u refresh`
*添加了"set\u redis\u ttl"不赞成它是相反的："assume\u redis\u lru"。在1.4.0版本之前，将支持"assume_redis_lru"kwarg。
*添加了"use_int_time"作为会话工厂参数。这将把"created"时间转换为int（math.ceil（time）），节省一些空间
-1/17/2017:
*版本1.2.1
*修复了会话中的错误。使导致创建占位符会话的错误无效（https://github.com/jvanasco/pyramd\u session\u redis/issues/2）
*添加了防止上述错误的测试
*修复了一些白色错误空间问题（尾随空格，制表符不是空格）
*将pacakge version id从setup.py迁移到uuu init_uuu.py作为"uuu version_uuu"变量。
*迁移测试和代码以处理webob 1.7对cookie值的抨击
-12/23/2016:
*版本1.2.0
*合并了来自宏远1306的pr1（https://github.com/jvanasco/pyramid_session_redis/pull/1）
*使包python3兼容
*合并令牌/会话生成
*利用python3.6 stdlib的令牌/会话生成；否则返回。
*将令牌urlsafe上的位从32更新到48；这将编码为64个字符串
-11/10/2016:
*versIon 1.1.2
发布错误修复。
-11/10/2016:
*版本1.1.1
*集成/重写Pyramid_redis_会话中的PR，用于CDN上的会话泄漏
https://github.com/ericrasmussen/Pyramid_redis_会话/pull/74/files
*响应。vary现在将确保"cookie"
*会话工厂现在接受"func_che"ck_response_allow_cookies（response）`可调用，可禁用设置cookie。
*简化了utils中的一些工作
-11/09/2016:重命名为pyramid_session_redis
-2016年8月15日：jvanasco branch的更改
*添加了"反序列化失败"以处理反序列化错误
-2016年2月8日：jvanasco branch的更改
*使嵌套更改的检测可配置。默认设置为true。
-06/16/2016:jvanasco分行的更改
*通过棱锥体的"添加完成"回调将"按需"更改为单个回调
*通过棱锥体的"添加完成"回调将"刷新"更改为"按需"更改为单个回调d_callback`
*将活动"session"与"request"上的特定命名属性分离。
*删除了对redis'`exists'的初始调用。与"如果存在，那么获取"不同，我们只是获取活动会话，如果不存在，则创建一个新会话。
*用单个"setex"替换了对"set"和"expire"的单独调用
*添加了一个功能，假设redis作为lru缓存运行，因此不发送到期数据
*确保嵌套会话值在加载时通过计算序列化会话数据的MD5哈希值触发持久性；然后在完成的回调中再次执行
----
-初始版本
-09/24/2012:0.9 beta版本
-11/12/2012:如果需要，引发配置错误redis.sessions.secret设置
丢失。
-02/17/2013:新的API方法：调整会话的超时。此方法允许
永久更改给定会话的超时设置
会话的持续时间。
n
每次访问会话时都会重置超时的内部操作。
其他更改包括：
1）删除未使用的"period"设置
2）修复cookie-on-u异常的错误设置
3）使用asbool进行布尔设置
4）添加文档
5）添加新的配置选项（有关详细信息，请参阅文档）
>内部（非api）更改包括：
*重命名新会话标志从"_v_new"改为"_rs_new"
*删除util模块对cpickle的依赖关系
*始终将超时设置转换为int
*删除未使用的导入
*对docstring/comments的许多更新和添加
*将redis连接/客户端逻辑移动到新模块
-06/30/2013:新配置选项：
*redis.sessions.client廑callable（提供自己的redis客户端）
*redis.sessions.serialize（使用自己的pickling函数）
*redis.sessions.deserialize（使用自己的unpickling函数）
*redis.sessions.id_generator（可调用以生成会话ID）
*redis.sessions.prefix（在redis中向会话ID添加前缀）
中断更改：cookie_httpo现在才默认为true。如果您当前依赖外部脚本访问
会话cookie（这是一个坏主意），则需要显式设置：
redis.sessions.cookie\u httponly=false
f或者大多数（可能是所有）用户，您不会注意到任何差异。
reference:https://www.owasp.org/index.php/httponly
session id generation:session id现在由os.urandom的初始值生成，该值（根据t官方的（python文档）是"适合加密使用的"。以前的
实现主要关注完整性。这个
更新提高了完整性，但也增加了更高级别的
安全性。
-10/13/2013：许多文档改进和一些小的重构（更好的
注释、删除未使用的函数等）。
甚至在github主机上工作了几个月
，没有发布到pypi。它标志着另一个主要版本的升级，
这次升级到1.0a。从现在起，发行版将遵循一个更典型的版本控制模型（类似于金字塔的模型）。
-06/15/2014:1.0a2的更改
**breaking change**：the`.created``和`.timeou会话的t``属性
现在被序列化并存储在redis中，同时
会话dict存储在另一个dict中。这和对
`.created``和`.timeout``的其他更改意味着金字塔型的redis会话>；=1.0a2
能够反序列化使用
棱锥体redis会话创建的会话<；1.0a2。不需要更改代码，但在升级之前请准备清除现有会话数据。
*错误修复：``redissession.created``正在存储并返回当``redissession`实例处于初始化，而不是首次创建实际会话的时间。现在已经修复了这个问题。
*错误修复：由于"timeout"值不是会话的一部分（以前它存储在会话dict中的"timeout"键下），因此它已从会话中移出
例如，在清除会话时丢失。）
*错误修复：会话现在支持在`.invalidate（）```之后的同一请求中启动新会话（使用
新会话id）。
（以前这是不可能的，因为``.invalidate（）``已清除会话dict，但未更改会话id，并设置
头以删除cookie，这意味着在`.invalidate（）``丢失之后对
会话所做的任何更改。）
删除cookie
也意味着同一个cookie名称将有多个cookie头集
，这不应该根据
rfc 6265发生。已修复此问题以设置一个正确的set cookie
头，并且仅在必要时（例如，在同一请求中无效的新
会话无需设置任何cookie即可访问该会话）。
``.invalidate（）``现在也从redis中删除会话，而不是仅依赖会话过期。
*错误修复：``cookie\u path``设置无效，因为它不用于设置和删除cookie。已修复此问题，我们现在按照预期设置并删除具有指定"cookie路径"的cookie。
*错误修复：在将头设置为删除cookie时未使用"cookie域"设置值
，这意味着任何cookie即
没有删除与默认域不同的域（因为只有当路径和域与设置cookie时使用的路径和域匹配时，
cookie才会被删除）。现在已修复。
*修复了
docstring中"cookie_httponly"设置的默认值，其中默认值以前已从
从false更改为true，但docstring未使用
进行更新。
*棱锥体redis会话已放弃对python 2.6的支持，现在需要python>；=2.7。
已被删除，因为在新会话开始时，
工厂已将超时插入到redis中，因此不再需要更长的时间。
*添加了与cookie相关的工厂参数的测试。
*有组织地导入到pep 8。
上游包问题：redis py在redis==2.10中引入了中断（和
未记录的）api更改（有关
详细信息，请参见
https://github.com/andymccurdy/redis-py/issues/510）。固定到redis<；=2.9.1，直到确认
这是否是一个将被修复的错误，或者我们是否需要
适应两个不同的api以使用更新的版本。
-02/20/2015:1.0.1的更改
*删除了redis py支持新版本redis py的上限
*不再将未使用的设置传递给"stricredis.from_url"（不
行为更改，因为如果在忽略这些设置之前传递这些设置
）
*更新为成功
alpha周期后的正式/稳定版本，以支持pip安装
==
开发人员的便利性。
此软件包现在遵循多版本发布过程。
1.2.x分支从1.2.2开始处于维护模式，最终将发布1.3.0版。
1.4.x分支正在积极开发中，随时可能更改。它将在一个稳定的1.5.0API版本中达到高潮。
----
1.2.x分支和更早的分支与"金字塔Redis会话"基本兼容。如果您正在使用此功能，则应将您的安装固定到"<；=1.3.0"或"<；1.3"。
有些夸尔格可能已经改变了。软件包的结构也发生了变化，利用内部机制的高级用户将需要升级。包仍然是即插即用金字塔会话接口。
重要提示：内部负载结构在1.4分支中已更改，不再与现有的1.2会话兼容（它们将无效）。我对可以处理优美回退的prs开放。
像这样：
{m'：{}，
'c'：int，
'v'：会话api'u版本，
session int
r
*现在使用API版本，以处理将来的优雅更改
*不再保证存在超时（现在可以在redis上处理）
*也可能存在过期超时
s包可能比原始项目更可取。与最初的实现相比，这个包大大减少了redis和pyramid之间的通信。还提供了一些选项来最小化有效负载的大小。
此包包含许多挂钩和功能，以帮助在高流量情况下使用此功能的开发人员。此包不推荐"最佳部署"，但提供了在不同情况下创建最佳部署的不同策略。
到1.2.x
----
*原始包在大多数属性访问和写入上与redis通信。某些实现上的通信量可能太大。`棱锥体会话redis将使用棱锥体的add_finished_callback挂钩将单个"persist"或"refresh"任务排队。
*使用的原始版本"exists"检查会话是否存在，然后继续"get"或"set"新会话。`金字塔会话redis将立即尝试"get"，并在失败时"设置"一个新会话。这就消除了一个调用。
*对"set"和"expire"的单独调用替换为单个"setex"
*可以设置一个标志来启用lru缓存（最近使用最少的）模式。不会向redis发送过期数据，允许redis服务器处理lru逻辑本身
*活动的"session"与请求属性分离（即，这可以处理在备用属性上设置的"session"）
*原始库不会检测到嵌套字典中的更改此包使用"hashlib.md5"在读取时对序列化值进行指纹识别；如果未检测到任何更改，则故障保护将对+md5数据进行序列化，以确定是否应进行写入。这可以通过将"检测更改"设置为false来禁用。
*如果会话无法反序列化，则inal会引发致命错误。通过向构造函数传入"反序列化失败"new，可以在反序列化错误时创建新会话。
*通过"func\u check"response\u allow\cookies支持禁用cdn生成内容上的会话
*由于@github/hongyuan1306，令牌生成已合并到uSe python3的stdlib（如果不可用，则重新实现）。令牌也是32个字符，而不是20个字符。
*在lru模式下支持redis（请参阅http://redis.io/topics/lru-cache），方法是将"set_redis_ttl"设置为"false"（默认情况下为"true"）。这将消除对"expire"的调用，并将使用"set"而不是"setex"。
*在1.2.x分支中，创建的时间可以通过"use-int-time=true"设置为整数。这将通过"int（math.ceil（time.time（））"强制转换"created"时间。这可以将有效负载减少几位。
其他更新1.4.x+
===
*仅支持int（）时间。
*会话现在具有版本控制，可以通过"version"`v`键支持将来的升级。
*重写了内部有效负载的格式，编码的paylo广告现在使用一个字母的键而不是单词。这应该会抵消expires时间戳和版本id的添加。
*没有python超时控制的逻辑（呜呜！）这个问题已经解决了。"expires"`x`键现在跟踪过期时间。
*添加了一个"timeout_trigger"选项。这将延迟到期数据更新以降低redis的使用率。下面将更详细地解释这一点。
*在高负载情况下，redis可能会有性能和存储问题，因为在原始包中，sessionid是根据每个请求创建的（例如被不尊重会话的botnet刺穿）。在这个包中，使用了"lazycreate"方法。除非回调例程中需要会话，否则不会生成会话id/cookie。为了预先生成会话id/cookie，可以使用"redissession.sure\u id"函数。若要安全检查会话ID是否存在，还可以使用"redissession.session\u id\u safecheck"方法。
*向构造函数添加了"func\u invalid\u logger"。这可用于记录无效会话。当与statsd系统集成时，它非常有用。（见下文）
*向工厂和会话构造函数添加了"set_redis_ttl_readheavy"。此选项将通过在管道中同时执行get+expire来优化已由redis维护ttl的会话。
注意：
=
如果"set\u redis\u ttl"为false，则并不意味着根本没有超时--只是redis不会通过"setex"发送超时数据。`或者"过期"。超时数据仍将存储在python中。
l与存储在redis中的超时数据进行比较。
如果您不希望会话超时，请将初始的"timeout"设置为"0"或"none"。
`设置redis ttl`；它也不需要启用"timeout_trigger"或"python_expires"。
_ redis-ttl=true
python中没有超时，没有redis-ttl（仅"set"使用）
timeout=0或none
假设redis-ttl=true
timeout触发器
=======
timeout触发器可用于限制更新/写入的数量。这可能对你的使用模式更有利。
独立使用的不同内部数据存储区：一个用于密钥的有效负载，另一个用于密钥的到期。
在"经典"行为中（这个项目是从其派生的）：每次访问现有会话时，get后面都会向redis发送一个新的到期时间，实际上永远不会y"read"对应redis跟踪的到期记录有一个"write"。
为了通过setex最小化写入，我引入了超时触发器。触发器的工作原理是在redis数据负载中存储一些超时信息，并使用这些信息来确定何时发送写操作。不是每次读取都有get+expire，我们只有一个get并消除由expire引起的写操作。但这需要维护成本-一旦我们触发超时触发器，而不仅仅是get，我们需要更新内部超时负载并发出设置。
回到您的情况：当用户在40分钟内停止活动时，如果启用了超时触发器，则永远不会有是自会话首次创建以来有关用户活动的内部负载或redis的更新。触发器的目的是推迟"写入"操作。
为了使会话在大约一小时内对"读取"有效，您需要执行以下操作：
*一个10分钟触发器的两小时会话，或
*一个50分钟触发器的一小时会话
也可以通过将触发器设置为0来禁用该功能。每天多达几千个用户，您不应该对"经典"模式的开销有任何问题。当您访问了10000个用户和/或开始让群集Web服务器与专用的Redis实例通信时，设置每次读取操作后的新过期时间就成了您要避免的事情。
Scenario 1-Classic Redis
----
ic"redis usage pattern，会话使用通过每个会话视图上的"expire"调用刷新
这很有用，但意味着许多会话操作将触发两个redis调用（`get`+`expire`）。在高性能系统上，这可能是一个很大的问题。
>这是一个典型的刷新场景：
>timeout=200 `
/>2个00 `get`+`expire` 400
300 `get`+`expire` 500
400 `get`+`expire` 600
500 `get`+`expire` 700
scenario 2-超时触发器
on的"timeout"。
当当前时间在到期后600秒内
```
timeout=1200
timeout_trigger=600
```
将发生以下时间线
`*| 1200 600
1 `获取1200 600
…||||
599 `获取1200 600
600 `获取`+`设置1800 1200
601 `获取1800 1200
…||||
1199 ` get ` 1800 1200
1200 ` get `+` set `*2400 1800
此方法与通过"setex"在redis中设置ttl兼容，如果redis处于lru模式，则在python中执行所有操作
在达到阈值之前删除所有"expire"调用，该阈值可以是在重读情况下可减少的存储量
此方法的注意事项：有效负载内必须存储到期时间戳，更新超时需要"set"操作。
set_redis_ttl_read heavy
=====br/>
这是"1.4.2"中的一个新选项，sh会提高readheavy安装的性能，但可能会降低writeheavy安装的性能。此选项将在每次读取时聚合一个get+expire。
"设置redis ttl ttl readheavy"需要以下条件：
*设置一个"超时"值
*"设置redis ttl"为"真"
*"超时"触发器未设置
*"python\expires"为"假"
在只读请求中是这样的：
*在会话访问中，通过"redis.get{session{id}
*在棱锥回调中，通过"redis.expire{session{id}{expire}`
>在读写期间：
*在会话访问中，通过"redis.get{session{id}
*在金字塔回调，通过"redis.setex{session{id}{payload}{expiry}`
如果启用，在只读请求期间，redis实例上的行为将更轻：
*在会话访问时，使用两个redis命令打开管道：`pipeline.get{session{id}`，`pipeline.expire{session{id}{expirey}`.
*在棱锥回调中，重复的expire将被抑制。
但是在读写过程中，活动是：
*在会话访问时，使用两个redis命令打开一个管道：`pipeline.get{session id}'，`pipeline.expire{session id}{expirey}`.
*在金字塔回调中，通过`redis.setex{session id}{payload}{expire}`
读重应用程序应该通过piplined get+expire看到一个轻微的性能提升，但是写重应用程序可能会看到性能下降，因为它会给每个请求增加一个额外的expire。
IS库是在遇到错误的会话数据（如ID无效的cookie或损坏的数据存储）时自动创建新会话。优雅的"新会话"是最终用户的理想状态。
.
这可用于跟踪安全捕获和静默升级的无效会话
如何进行？该包使用"金字塔会话"redis.exceptions.invalidSession`
离子无效，因为没有cookie。这与"新会话"相同。
*`` InvalidSession\u NotInBackend（InvalidSession）``会话ID不在后端
*`` InvalidSession\u反序列化错误（InvalidSession）``反序列化错误。如果"反序列化失败"为true，则会引发此问题。否则，异常将被包装在"rawdeserializationerror"中并在未被捕获的情况下引发。
*``invalidSession\u payloadTimeout（invalidSession）``内部python负载超时
*``invalidSession\u payloadLegacy（invalidSession）``会话在早期版本上运行
工厂接受"func"无效的"logger"可调用参数。输入是在生成新cookie之前引发的异常，将是请求和"invalidSession"的实例。
_记录器（请求，引发的异常）：
"
引发的异常将是InvalidSession的一个实例e对于度量的statsd异常
"
如果是instance（引发的异常，无效会话nosessioncookie）：
statsd_client.incr（'invalid_session.nosessioncookie'）
elif isiinstance（引发的异常，无效会话notinbackend）：
statsd_client.incr（'invalid_session.notinbackend'）
elif isinstance（引发异常，invalidSession反序列化错误）：
statsd_client.incr（'invalid_session.deserializationerror'）
…
）
"func_invalid_logger"参数可以在设置文件中以点符号字符串的形式提供。
未捕获错误
==
zed_fails_new"不是"true"。第一个参数将是捕获的异常。这允许跨多个反序列化选项出现标准错误。
常见问题解答：
==
==
=1.4.x版本的API有点混乱。
[]创建新会话仍需要2个set/setex调用一个用于占位符，下一个用于更新。这应该合并为一个。
进一步阅读：
==
==
>有关python下的redis性能的更多信息，请参阅相关项目：
*https://github.com/jvanasco/dogpile_backend廑redis廑advanced
直到2016年11月这是维护为"jvanasco/pyramd_redis_sessions"
*jvanasco/pyramd_redis_sessions的主分支是"custom_deployment"
*从2016年11月起，名为"master"的分支是来自ericrasmussen的上游源
，这被分到了自己的项目中，以允许分发ion.
所有支持都通过github处理：https://github.com/jvanasco/pyramid_session_redis
overview
==
pyramid_redis_sessions是金字塔Web的服务器端会话库
RK，使用redis存储。这个库
实现了"金字塔iSession接口"lt；http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interface s.html\pyramid.interfaces.iSession>；` `.
表。当您的数据可以
放入内存时，它工作得最好，但它是可配置的，并且在需要将
同步到磁盘时仍然非常快。如果您想了解它的用例，有很多现有的基准测试、意见和文章。但是对于"金字塔Redis会话"，我特别感兴趣，原因如下：
*它真的很快（选择你自己的咒语）
*它有一个非常方便的内置机制来设置键的过期时间
*手表机制是一个很好的、轻量级的替代full事务
*会话数据通常很重要，但不是关键任务，但如果它是…
*它具有可配置的"持久性"lt；http://redis.io/topics/persistence>；`
/>`入门<；http://pyramid redis sessions.read the docs.org/en/latest/getting started.html>；`
指南。
您还可以在阅读文档时阅读
`完整文档<；http://pyramid redis sessions.readthedocs.org/en/latest/index.html>；`
支持
=======
我的尼克是伊拉斯马斯，
但如果我不在，你还可以很明显，可以从其他许多熟悉的常客那里获得支持。
有关详细信息，请参见
`license.txt<；https://github.com/ericrasmussen/pyramid廑redis廑u sessions/blob/master/license.txt>；`廑
===
==
=
-未发布的
*跳过1.3版本。目前没有足够的使用量来保证向后兼容
*一堆api更改来支持延迟创建的会话。原始结构将立即创建会话，这可能会导致bots和spidering的问题。
-2019/04/27
*版本1.5.0
*使用6来处理python3，而不是使用一些自制的东西
-10/17/2017
*版本1.4.2
*将默认超时触发器设置为"none"（问题12，从11分叉）
*已将"金字塔会话"迁移到"redis session"。"已完成回调"迁移到"redissession"。"已延迟回调"
*为读取密集型部署引入了新的"set_redis_ttl_readheavy"选项
-10/17/2017
*版本1.4.1
*修复了1.4.0上的部署错误，该错误的readme中包含非ascii字符
*忘记rUN Python3测试
-10/17/2017
*版本1.4.0
*更新的弃用警告
*准备不在每个访问上创建会话。不使用会话的机器人程序对redis进行spidered会损害redis。
*将"util.get_unique_session_id"重命名为"util.create_unique_session_id`
*添加了"util.empty_session_payload`
*将一些redis session factory函数迁移到了一个更全局（不是每个请求）的块中
*将"func_invalid_logger"添加到session factory，还r命名的内部异常。他们不是一个公共的API，所以不存在不推荐的问题。
*这在我们的生产使用中似乎很好，所以可以实时推送。
-1/24/2017:
*版本1.2.2
*合并了来自Chad Birch（@deimos）的大部分拉取请求https://github.com/jvanasco/pyramd_session_redis/pull/3
*澄清了文档中的假设_redis_ru，添加了tests
*将"force\u redis\u ttl"kwarg添加到"redisession.do\u refresh`
*添加了"set\u redis\u ttl"不赞成它是相反的："assume\u redis\u lru"。在1.4.0版本之前，将支持"assume_redis_lru"kwarg。
*添加了"use_int_time"作为会话工厂参数。这将把"created"时间转换为int（math.ceil（time）），节省一些空间
-1/17/2017:
*版本1.2.1
*修复了会话中的错误。使导致创建占位符会话的错误无效（https://github.com/jvanasco/pyramd\u session\u redis/issues/2）
*添加了防止上述错误的测试
*修复了一些白色错误空间问题（尾随空格，制表符不是空格）
*将pacakge version id从setup.py迁移到uuu init_uuu.py作为"uuu version_uuu"变量。
*迁移测试和代码以处理webob 1.7对cookie值的抨击
-12/23/2016:
*版本1.2.0
*合并了来自宏远1306的pr1（https://github.com/jvanasco/pyramid_session_redis/pull/1）
*使包python3兼容
*合并令牌/会话生成
*利用python3.6 stdlib的令牌/会话生成；否则返回。
*将令牌urlsafe上的位从32更新到48；这将编码为64个字符串
-11/10/2016:
*versIon 1.1.2
发布错误修复。
-11/10/2016:
*版本1.1.1
*集成/重写Pyramid_redis_会话中的PR，用于CDN上的会话泄漏
https://github.com/ericrasmussen/Pyramid_redis_会话/pull/74/files
*响应。vary现在将确保"cookie"
*会话工厂现在接受"func_che"ck_response_allow_cookies（response）`可调用，可禁用设置cookie。
*简化了utils中的一些工作
-11/09/2016:重命名为pyramid_session_redis
-2016年8月15日：jvanasco branch的更改
*添加了"反序列化失败"以处理反序列化错误
-2016年2月8日：jvanasco branch的更改
*使嵌套更改的检测可配置。默认设置为true。
-06/16/2016:jvanasco分行的更改
*通过棱锥体的"添加完成"回调将"按需"更改为单个回调
*通过棱锥体的"添加完成"回调将"刷新"更改为"按需"更改为单个回调d_callback`
*将活动"session"与"request"上的特定命名属性分离。
*删除了对redis'`exists'的初始调用。与"如果存在，那么获取"不同，我们只是获取活动会话，如果不存在，则创建一个新会话。
*用单个"setex"替换了对"set"和"expire"的单独调用
*添加了一个功能，假设redis作为lru缓存运行，因此不发送到期数据
*确保嵌套会话值在加载时通过计算序列化会话数据的MD5哈希值触发持久性；然后在完成的回调中再次执行
----
-初始版本
-09/24/2012:0.9 beta版本
-11/12/2012:如果需要，引发配置错误redis.sessions.secret设置
丢失。
-02/17/2013:新的API方法：调整会话的超时。此方法允许
永久更改给定会话的超时设置
会话的持续时间。
n
每次访问会话时都会重置超时的内部操作。
其他更改包括：
1）删除未使用的"period"设置
2）修复cookie-on-u异常的错误设置
3）使用asbool进行布尔设置
4）添加文档
5）添加新的配置选项（有关详细信息，请参阅文档）
>内部（非api）更改包括：
*重命名新会话标志从"_v_new"改为"_rs_new"
*删除util模块对cpickle的依赖关系
*始终将超时设置转换为int
*删除未使用的导入
*对docstring/comments的许多更新和添加
*将redis连接/客户端逻辑移动到新模块
-06/30/2013:新配置选项：
*redis.sessions.client廑callable（提供自己的redis客户端）
*redis.sessions.serialize（使用自己的pickling函数）
*redis.sessions.deserialize（使用自己的unpickling函数）
*redis.sessions.id_generator（可调用以生成会话ID）
*redis.sessions.prefix（在redis中向会话ID添加前缀）
中断更改：cookie_httpo现在才默认为true。如果您当前依赖外部脚本访问
会话cookie（这是一个坏主意），则需要显式设置：
redis.sessions.cookie\u httponly=false
f或者大多数（可能是所有）用户，您不会注意到任何差异。
reference:https://www.owasp.org/index.php/httponly
session id generation:session id现在由os.urandom的初始值生成，该值（根据t官方的（python文档）是"适合加密使用的"。以前的
实现主要关注完整性。这个
更新提高了完整性，但也增加了更高级别的
安全性。
-10/13/2013：许多文档改进和一些小的重构（更好的
注释、删除未使用的函数等）。
甚至在github主机上工作了几个月
，没有发布到pypi。它标志着另一个主要版本的升级，
这次升级到1.0a。从现在起，发行版将遵循一个更典型的版本控制模型（类似于金字塔的模型）。
-06/15/2014:1.0a2的更改
**breaking change**：the`.created``和`.timeou会话的t``属性
现在被序列化并存储在redis中，同时
会话dict存储在另一个dict中。这和对
`.created``和`.timeout``的其他更改意味着金字塔型的redis会话>；=1.0a2
能够反序列化使用
棱锥体redis会话创建的会话<；1.0a2。不需要更改代码，但在升级之前请准备清除现有会话数据。
*错误修复：``redissession.created``正在存储并返回当``redissession`实例处于初始化，而不是首次创建实际会话的时间。现在已经修复了这个问题。
*错误修复：由于"timeout"值不是会话的一部分（以前它存储在会话dict中的"timeout"键下），因此它已从会话中移出
例如，在清除会话时丢失。）
*错误修复：会话现在支持在`.invalidate（）```之后的同一请求中启动新会话（使用
新会话id）。
（以前这是不可能的，因为``.invalidate（）``已清除会话dict，但未更改会话id，并设置
头以删除cookie，这意味着在`.invalidate（）``丢失之后对
会话所做的任何更改。）
删除cookie
也意味着同一个cookie名称将有多个cookie头集
，这不应该根据
rfc 6265发生。已修复此问题以设置一个正确的set cookie
头，并且仅在必要时（例如，在同一请求中无效的新
会话无需设置任何cookie即可访问该会话）。
``.invalidate（）``现在也从redis中删除会话，而不是仅依赖会话过期。
*错误修复：``cookie\u path``设置无效，因为它不用于设置和删除cookie。已修复此问题，我们现在按照预期设置并删除具有指定"cookie路径"的cookie。
*错误修复：在将头设置为删除cookie时未使用"cookie域"设置值
，这意味着任何cookie即
没有删除与默认域不同的域（因为只有当路径和域与设置cookie时使用的路径和域匹配时，
cookie才会被删除）。现在已修复。
*修复了
docstring中"cookie_httponly"设置的默认值，其中默认值以前已从
从false更改为true，但docstring未使用
进行更新。
*棱锥体redis会话已放弃对python 2.6的支持，现在需要python>；=2.7。
已被删除，因为在新会话开始时，
工厂已将超时插入到redis中，因此不再需要更长的时间。
*添加了与cookie相关的工厂参数的测试。
*有组织地导入到pep 8。
上游包问题：redis py在redis==2.10中引入了中断（和
未记录的）api更改（有关
详细信息，请参见
https://github.com/andymccurdy/redis-py/issues/510）。固定到redis<；=2.9.1，直到确认
这是否是一个将被修复的错误，或者我们是否需要
适应两个不同的api以使用更新的版本。
-02/20/2015:1.0.1的更改
*删除了redis py支持新版本redis py的上限
*不再将未使用的设置传递给"stricredis.from_url"（不
行为更改，因为如果在忽略这些设置之前传递这些设置
）
*更新为成功
alpha周期后的正式/稳定版本，以支持pip安装
欢迎加入QQ群-->： 979659372
