缓存持久化
我正在将 Asp.Net 缓存机制用于频繁更改的 Web 应用程序。 缓存保存聊天参与者及其消息，并且需要跟踪 参与者的存在。
数据变化非常频繁，参与者进进出出，消息发送和接收。
缓存为我提供了以下解决方案： - 表现 - 减少数据库 (SQL Server) 中 DDL 操作的数量 - 我们遇到事务日志已满的问题。
我想继续以这种方式工作，但我不能依赖缓存（当缓存回收时我可能会丢失所有数据，或者当内存满时我可能会丢失一些数据）。
我现在看到的选项是每次缓存更改时将数据保存到数据库，否则我将丢失数据。
但这意味着许多 SQL 更新/插入语句。
有人建议我每 N 个消息/更改都持久保存到数据库，但这仍然不是一个可靠的解决方案。我仍然丢失数据。
有人有主意吗？
谢谢 亚龙
I am using the Asp.Net Caching mechanism for a highly frequent changing web app.
the cache holds chat participants and their messages, and it needs to keep track of
participants presence.
Data is changing very frequently, participants go in and out, and messages are sent and recieved.
The cache provides me with solutions for:
- performance
- reducing the number of DDL operations in the database (SQL Server) - we had a problem with the transaction log getting full.
I want to continue working this way, but I cannot rely on the cache (I can lose all data when the Cache recycles, or some of the data when the memory gets full).
The option I see right now is to save the data to the database every time the cache changes, otherwise I will lose data.
But this means many SQL update/insert statements.
someone adviced me to persist to the database evey N messages/changes, but it's still not a reliable solution. I still lose data.
Anyone has an idea?
Thanks
Yaron
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
解决数据库容量问题。如果您需要能够可靠地每秒保存 n 个更改，那么您的数据库需要能够每秒处理 n 个操作。
任何其他操作（包括保存每隔几次操作）都可能导致数据丢失。如果您可以接受数据丢失风险，那么这就可行。
分布式缓存（项目 Velocity 或其他）也可以提供帮助（数据至少保存到多台机器上）。但这需要额外的硬件，并且您可以将其花费在数据库的容量上。
最后，与其尝试缓存更改，寻找其他机会缓存数据库读取，不如减轻负载，从而允许写入继续进行。至少在您获得更多使用之前。
Fix your database capacity issues. If you need to be able to reliably save n changes per second, then your database needs to be able to handle n operations per second.
Anything else (including saving every few operations) will lead to some possibility of data loss. If you can accept that data loss risk, then that would work.
A distributed cache (project Velocity or otherwise) could also help (data is at least saved to multiple machines). But that needs extra hardware, and you could spend that on the capacity of the database.
Finally, rather than trying to cache changes look for other opportunities to cache database reads, taking that load off might allow the writes to go through. At least until you get more usage.