备份持久性存储。 我有什么选择？
我有一项接受来自提供商的回调的服务。 动机：我不想丢失任何回调（当然，除非我的网络无法访问）。
假设不可能的事情发生了，我的 mysql 服务器在一段时间内无法访问， 一旦我重试多次但失败，我想回退到辅助持久性存储。
我有什么选择？ 队列、内存缓存？
I have a service that accepts callbacks from a provider.
Motivation: I do not want to EVER lose any callbacks (unless of course my network becomes unreachable).
Let's suppose the impossible happens and my mysql server becomes unreachable for some time,
I want to fallback to a secondary persistence store once I've retried several times and fail.
What are my options? Queues, in-memory cache ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以拥有一台备份 MySQL 服务器，并在主服务器发生故障时将连接切换到该服务器。 如果它只是故障转移存储，您可能可以在应用程序服务器上本地运行它。
You can have a backup MySQL server, and switch your connection to that one in case primary one breaks down. If it's going to be only fail-over store you could probably run it locally on the application server.
我之前已经在 SQLite 中为此设置了一个队列。 不过，就我而言，这是为了防止与 MySQL 服务器的网络链接丢失——数据是本地生成的。
I've put a queue in SQLite for this before. Though, in my case, it was to protect against loss of the network link to the MySQL server — the data was locally-generated.
我推荐某种作业队列服务器。 我个人使用 Starling 并取得了很好的效果。 它采用内存缓存协议，因此很容易用作持久队列。
Github 上的 Starling
I recommend some sort of job queue server. I personally use Starling and have had great results with it. It speaks the memcache protocol so it is easy to use as a persistent queue.
Starling on Github
你说你收到了“回调”——你没有说清楚它们是什么。 协议是什么？ 是通过网络吗？
如果是 HTTP，那么我想说最好的方法是，如果您的应用程序无法将数据写入永久存储，它应该向调用者返回一个错误（如果协议中存在“稍后再试”），调用者应该稍后再试。
像回调这样的异步进程应该始终能够应对下游的故障并将其请求排队。
我曾与一家支付提供商合作，就出现过这种情况（Paypal）。 如果您无法完全处理请求，只需将错误发送回调用者即可。
You say you're receiving "Callbacks" - you've not made clear what they are. What is the protocol? Is it over a network.
If it were HTTP, then I would say the best way is that if your application is unable to write the data into permanent storage, it should return an error ("Try again later" if that exists in the protocol) to the caller, who should try again later.
An asynchronous process like a callback should always be able to cope with failures downstream and queue its requests.
I've worked with a payment provider where this has been the case (Paypal). If you're unable to completely process the request, just send an error back to the caller.