缓存 VS 会话 VS cookie？
缓存、会话、Cookie 的注意事项是什么？
例如：
我经常使用会话变量，有时当用户开始订购产品然后去吃午餐并在几个小时后回来并继续预订时，预订应用程序中有时会出现问题。 我将预订存储在会话中，直到用户确认或中止预订，因此当用户只需单击浏览器中的 X 并且不再返回时，我不需要与数据库通信并处理数据库中的中途预订。
我应该使用缓存或 cookie 或某种组合来实现此目的吗？
（此外，当应用程序中出现一些错误时，会话对象会自行重置，因此我会遇到更多问题）
我主要进行桌面编程，感觉我在这里缺乏很多知识，所以任何人都可以扩展在哪里使用缓存，会话，Cookies（或db）将不胜感激
编辑：从答案来看，DB和cookie的组合似乎是我想要的。
- 我必须将预订存储在连接到会话 ID 的数据库中 将会话
- ID 存储在 Cookie 中（加密）。
- 每个页面加载时都会检查 cookie 并从数据库中获取预订。
- 我有一个每周运行一次的清理程序，用于清除未完成的预订。
我无法将预订存储为 cookie，因为用户可以更改价格和其他敏感数据，而我必须验证所有内容（不能信任数据）。
我做对了吗？
感谢大家的精彩解释！
What are the do's and don'ts about Cache VS Session VS Cookies?
For example:
I'm using Session variables a lot and sometimes have problems in a booking-application when users start to order products and then go to lunch and come back some hours later and continue the booking. I store the booking in the session until the user confirms or aborts the booking so I don't need to talk to the database and handle halfway bookings in the database when users just click the X in the browser and never comes back.
Should I instead use cache or cookies or some combination for this?
(Also when there is some error in the app, the session-object resets itself and I get more problems because of that)
I'm mostly doing desktop-programming and feel I lack lots of knowledge here so anyone who can expand on where to use Cache, Session, Cookies (or db) would be appreciated
Edit: From the answers it seems that a combination of DB and cookies is what I want.
- I have to store the booking in the database connected to a session-id
- Store the session-id in a cookie (encrypted).
- Every page load checking the cookie and fetch the booking from the database
- I have a clean-up procedure that runs once a week that clears unfinished bookings.
I can't store the booking as a cookie because then the user can change prices and other sensitive data and I had to validate everything (can't trust the data).
Have I got it right?
And thanks for great explanations to all of you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
从桌面应用程序的角度来看，状态管理是进入 Web 世界时需要掌握的关键内容。
Session用于存储服务器上当前 Web 会话的每个用户信息。 它支持使用数据库服务器作为后端存储。Cookie应用于存储当前 Web 会话的每个用户信息或客户端上的持久信息，因此客户端可以控制 cookie 的内容。Cache对象在单个应用程序中的用户之间共享。 其主要目的是缓存数据存储中的数据，不应用作主存储。 它支持自动失效功能。Application对象在用户之间共享，用于存储应用程序范围状态，并应相应地使用。如果您的应用程序被许多未经身份验证的用户使用，我建议您将数据存储在 cookie 中。 如果需要身份验证，您可以手动将数据存储在数据库中或使用 ASP.NET 配置文件管理功能。
State management is a critical thing to master when coming to Web world from a desktop application perspective.
Sessionis used to store per-user information for the current Web session on the server. It supports using a database server as the back-end store.Cookieshould be used to store per-user information for the current Web session or persistent information on the client, therefore client has control over the contents of a cookie.Cacheobject is shared between users in a single application. Its primary purpose is to cache data from a data store and should not be used as a primary storage. It supports automatic invalidation features.Applicationobject is shared between users to store application-wide state and should be used accordingly.If your application is used by a number of unauthenticated users, I suggest you store the data in a cookie. If it requires authentication, you can either store the data in the DB manually or use ASP.NET profile management features.
Web 本质上是断开连接的模型，并且提到的所有选项（会话、应用程序、缓存……）都不够可靠。 会话会超时、工作进程回收等。
如果您确实需要长时间可靠地存储用户进度，那么数据库是您唯一的解决方案。 如果您有用户配置文件（如果用户必须登录），那么这很简单。 如果没有，则生成一个唯一的 ID，将其存储在 cookie（或 URL）中，并根据该标识跟踪用户。
只需确保 Id 已加密，然后是 Base64 编码的字符串，而不仅仅是数字值。
编辑：
在原始问题和 Mehrdad Afshari 的评论中进行附加解释后，对您来说好的解决方案是使用 Session 但将存储设置为 Sql Server 而不是 InProc。
以下是如何设置的更多详细信息和说明： http://msdn.microsoft .com/en-us/library/ms178586.aspx
请记住，您仍然会遇到会话超时，但它们会在应用程序池回收中幸存下来，甚至服务器重新启动也是如此。
如果您确实需要永久存储，那么使用数据库的自定义解决方案（正如我最初概述的那样）是唯一的解决方案。
Web is by nature disconnected model and none of the options mentioned (Session, Application, Cache, ...) are reliable enough. Session will timeout, worker process recycles, etc.
If you really need to store the users progress, reliably and through extended periods, the database is your only solution. If you have users profile (if the user must log in), then it's straightforward. If not, generate a unique Id, store it in the cookie (or URL) and track the user based on that identification.
Just make sure the Id is encrypted and then base64 encoded string and not just a numeric value.
EDIT:
After your additional explanation in the original question and comment from Mehrdad Afshari, good solution for you would be to use Session but set the storage to Sql Server instead of InProc.
Here's more details and instructions how to set it up: http://msdn.microsoft.com/en-us/library/ms178586.aspx
Have in mind that you will STILL have the session timeouts, but they will survive application pool recycles, even server restarts.
If you truly need a permanent storage, custom solution with the database, as I originally outlined is the only solution.
会话存储在服务器上默认会在 20 分钟内超时（这是可调的）。 我会将其存储在 cookie 中或视图状态（如果可用）中以防止超时。
如果您的状态存储在 InProc（默认设置）中，那么场中拥有多个服务器也会给您带来问题，除非您实现了某种“粘性会话”，使用户保持在场中的同一服务器上。农场以供后续调用。
我尝试尽可能避免会话（在服务器上增加额外的负载和内存使用），并尽可能保持视图状态关闭以保持页面大小较低。 Cookie 通常是最轻量级的选项，但您的用户可能已将其关闭，并且您将需要一个后备模式来仍然允许他们使用该网站。
编辑（根据询问者的响应添加说明）：
Viewstate 存储在隐藏字段中，是 Viewstate 存储中所有对象的序列化表示。 Viewstate 会自动用于存储页面的状态，但如果您愿意，也可以通过编程方式显式向 Viewstate 添加或检索自己的对象。
所以是的，数据集可以存储在 Viewstate 中。
Session is stored on the server will time out by default in 20 minutes (This is adjustable). I would store this in a cookie, or in viewstate(if available) to prevent the timeout.
If your state is stored InProc(the default setup), then having more than one server in a farm is going to cause you issues also unless you have implemented some sort of "sticky session" that will keep the user on the same server in the farm for subsequent calls.
I try to avoid session when possible(puts extra load and memory usage on the server), and keep viewstate turned off when possible to keep the page size low. Cookies are often the most lightweight option, but your users might have this turned off and you will need a fallback mode that still allows them to use the site.
Edit (adding clarification based on response from asker):
Viewstate is stored in a hidden field, and is a serialized representation of all objects in Viewstate storage. Viewstate is automatically used to store the page's state, but you can explicitly add and retrieve your own objects to and from Viewstate programatically if you choose to.
So yes, datasets can be stored in Viewstate.
首先你必须知道！ cookie 由会话使用！ 由于每次请求时客户端和服务器之间交换的 cookie，服务器知道谁是您的用户（这适用于 HTTP 标头 set-cookie 和 cookie）。
真正的问题是：
然后考虑您要在哪里存储会话：
如果您的站点必须具有高响应性和高性能，那么您不得将会话存储在进程内，而应存储在数据库内。 这样您就可以在多个网络服务器之间共享工作。
但是您会失去简单性（因为您在会话中存储的对象必须是可序列化的），并且您的网络服务器和数据库服务器之间又多了一次往返。
First thing you must know! cookies are used by session! The server knows who is your user thanks to the cookie which is exchanged between the client and server every request (this works with HTTP headers set-cookie and cookie).
The real question is:
Then consider where you want to store your session:
If your site must have high disponibility and high performance, then you must not store session inside the process but inside a database. This way you will be able to share the work among several web server.
But you will loose in simplicity (because objects you store in your session must be serializable), and you have one more round trip between your webserver and your database server.
我总是对 LocalStorage、SessionStorage 和 Cookie 感到困惑，但现在不再这样了。
只要链接这些词就可以自我解释它们想要做什么。
LocalStorage：本地存储，什么意思，只是你对技术一无所知，但本身你就能猜到。
它是一些在本地存储数据的存储。
就是这样。
IT 将数据
存储在浏览器中，不会过期，直到用户通过 JavaScript 代码或清除浏览器缓存清除数据。Session Storage：看起来它也存储数据，但与会话相关，那么它与 localStorage 有什么不同？
主要区别是
会话结束或浏览器选项卡关闭或浏览器关闭后，会话存储数据将被删除。您可以尝试在浏览器控制台中设置
，然后关闭选项卡并再次打开，您仍然可以找到 localStorage 数据，但找不到 sessionStorage 数据。
Cookie：所以这与以上两个。
通常用于服务器端目的的 cookie。
要求。
持续时间可以从服务器端或客户端设置（通常
从服务器端）。
也可以在客户端读取），localStorage 和 sessionStorage 可以
只能在客户端读取。
通过将该 cookie 的 httpOnly 标志设置为 true 来确保安全。
这会阻止客户端访问该 cookie
I was always confused between LocalStorage, SessionStorage and Cookie, but not anymore.
Just link the words are self explainable what they suppose to do.
LocalStorage: Local Storage, what does that mean, just thing you don't know anything about technology, but by the itself you can guess.
It is some storage which stores data locally.
that what it is.
IT stores data in Browser
without any expiration until user clear itthrough JavaScript code or Clear browser cache.Session Storage: It seems like it also stores data but related to a session then how different it is from localStorage?
The main difference is your
session storage data will be deleted once the session is finish or browser tab is closed or the browser is closed.You can just try in browser console by setting
and then close tab and open again, you can still find localStorage data but not sessionStorage data.
Cookie: So this is totally different from the above two.
A cookie generally used for the server-side purpose.
requests.
duration can be set from either server-side or client-side (normally
from server-side).
also be read on client-side), localStorage and sessionStorage can
only be read on client-side.
be made secure by setting the httpOnly flag as true for that cookie.
This prevents client-side access to that cookie
您不应该使用缓存对象来缓存会话数据，因为缓存在所有用户之间共享。 相反，您可以使用 Asp.Net 配置文件属性 来存储您的数据或您可以向 Session_End 事件添加一个事件处理程序，并在用户离开计算机时间过长时存储数据。
You should not use the Cache-object to cache session data, for the cache is shared between all users. Instead you could use Asp.Net Profile properties to store your data or you could add an event handler to the Session_End event and store the data if the user leaves the computer for too long.
Cookie 是在协作软件之间共享的一条信息，通过在客户端计算机上存储特定于客户端的信息并在以后检索以获得状态信息。
选择术语“cookie”，因为“cookie 是一个众所周知的计算机科学术语，用于描述中介持有的不透明数据片段” 。 这里的术语“不透明”意味着内容仅与服务器而不是客户端感兴趣和相关。 浏览器将自动将 cookie 包含在其向 cookie 的原始主机发出的所有后续请求中。 Cookie 具有名称和值以及其他属性，例如域和路径、到期日期、版本号和注释。 对于更多
Cookie 版本：
服务器-端会话数据可以存储大量数据，而客户端cookie数据从网站发送到服务器的大小受到限制，cookie通常包含参考代码，以此节省数据传输大小。 浏览器一关闭，会话就会关闭，但 cookie 的存在时间会更长。 浏览器将会话 ID 作为 URL 参数、cookie 甚至 HTTP 标头发送到服务器。
缓存是一种存储数据的硬件或软件组件，以便可以更快地满足未来对该数据的请求； 存储在缓存中的数据可能是早期计算的结果，也可能是存储在其他地方的数据的副本。
Cookie is a piece of information shared between co-operating pieces of software, by storing client-specific information on the client's machine and later retrieved to obtain the state information.
chose the term "cookie" as "a cookie is a well-known computer science term that is used when describing an opaque piece of data held by an intermediary". The term opaque here implies that the content is of interest and relevance only to the server and not the client. The browser will automatically include the cookie in all its subsequent requests to the originating host of the cookie. A cookie has a name and a value, and other attribute such as domain and path, expiration date, version number, and comments. for more
Cookie Version:
Server-side session data can store large data and a client-side cookie data are limited in size sent from a website to server, cookies usually contains reference code by this saving data transfer size. Session closes as soon as browser closed, but cookies are exist longer. Browser sends a session ID to the server as a URL param, cookie, or even HTTP headers.
Cache is a hardware or software component that stores data so future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation, or the duplicate of data stored elsewhere.
Cookies以文本文件格式存储在浏览器中。它存储的数据量有限。它只允许4kb[4096bytes]。它不保存多个变量饼干。
我们可以轻松访问 cookie 值。因此它安全性较低。setcookie() 函数必须出现在标签之前。
会话存储在服务器端。它存储无限量的数据。它在会话中保存多个变量。 我们无法轻松访问 cookie 值。因此它更安全。
Cookies are stored in browser as a text file format.It is stored limit amount of data.It is only allowing 4kb[4096bytes].It is not holding the multiple variable in cookies.
we can accessing the cookies values in easily.So it is less secure.The setcookie() function must appear BEFORE the tag.
Sessions are stored in server side.It is stored unlimit amount of data.It is holding the multiple variable in sessions. we cannot accessing the cookies values in easily.So it is more secure.