英文:
Is there a point in using Redis for small sized Gorilla sessions
问题
我觉得，只要你只想存储简单的值，比如最后访问的时间戳和可能的用户ID，使用Redis作为Gorilla会话持久化似乎没有任何意义，因为它们似乎已经将其存储在客户端的cookie中。
我的假设是正确的吗？
我知道有一个大小限制，而且如果我将会话存储在文件中（Gorilla会话的另一个可用存储选项），就无法在超出该机器范围内进行扩展，但是使用Gorilla会话cookie存储，这个"会话存储"问题是否不存在？
顺便说一下，我在这里看到了这个问题，不，它没有解决这个问题，所以不是重复的。https://stackoverflow.com/questions/22999148/what-is-the-advantage-of-using-gorilla-sessions-custom-backend
英文:
It seems to me that as long as you only want to store simple values like a timestamp for last visit and maybe a userid in the session, there's really no point at all in using Redis as a session persistence with Gorilla sessions since they seem to be storing it in cookies on the client side anyways.
Am I correct or not in this assumption?
I understand that there's a size limit and also that if I were to store sessions on file (the other available storage option with gorilla sessions), it'd be impossible to scale beyond that machine but again, is this whole "session store" a non issue with gorilla sessions cookie store?
Btw, I've seen this question here and NO it doesn't address this issue so it's not a duplicate. https://stackoverflow.com/questions/22999148/what-is-the-advantage-of-using-gorilla-sessions-custom-backend
答案1
得分: 3
使用Redis（或任何其他服务器端存储）可以避免一整类问题，包括：
- 大型cookie大小增加每个请求的开销 - 即使每个请求额外增加4K的开销，在移动连接上也可能很大。
- 严重降低cookie数据在存储在服务器端时被篡改的风险。
- 能够在会话中存储超过4K的数据（例如来自多步表单的表单数据）。
- ...而对于Redis来说，能够轻松地使服务器端会话过期（这在使用MySQL或文件系统存储时更容易出错）。
仍然需要一个cookie，因为它必须存储一个标识符，以便将用户与他们的服务器端会话关联起来。这与gorilla/sessions无关，几乎所有其他服务器端会话实现都是如此。
如果你认为你的用例很简单，那么当然可以继续使用基于cookie的会话。gorilla/sessions使得在以后更换后端存储变得很容易。
英文:
Using Redis (or any other server-side store) can help avoid a whole class of problems, namely:
- Large cookie sizes adding per-request overhead - even an additional 4K per request can be a lot on mobile connections.
- Severely reducing the risk of cookie data being manipulated as it is stored server-side.
- Ability to store more than 4K in the session (i.e. form data from a multi-step form)
- ... and in Redis' case, the ability to easily expire the server-side sessions (something that's more error prone with mySQL or a filesystem store.
A cookie is still required as it must store an identifier so the user can be associated with their server-side session. This isn't particular to gorilla/sessions whatsoever and is how nearly all other server-side session implementations behave.
If you think your use case is simple then sure, stick with cookie-based sessions. gorilla/sessions makes it easy enough to change out the backing store at a later date.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论