对于这个问题,我特别纠结于如何构造这个:
我的问题是,多个人可能同时出现在网站上,并单击按钮--我希望确保每个用户都能够单击该按钮,更新该值并读取递增的值,但我不知道如何避免任何同步/并发问题。
我正在使用烧瓶运行我的网站后端,我正在考虑使用MongoDB或Redis来存储我需要更新的单个值。
如果我的问题不够清晰,请发表评论,但这是我一直在努力解决的问题。
谢谢:)
发布于 2022-07-08 16:08:07
为了解决这个问题,我建议您遵循一个微服务体系结构。
名为worker的服务将处理当用户单击网站上的链接/按钮时调用的烧瓶路径。它将生成一条消息,发送给另一个名为队列管理器( queue manager )的服务,该服务维护来自工作服务的增量/递减消息队列。
可以同时运行多个辅助服务实例,但是队列管理器是一个单例服务,它从每个服务获取消息并将它们添加到队列中。如果队列管理器繁忙,员工服务将超时并重试或将失败消息返回给用户。如果队列已满,则会将响应发送回工作人员以重试n次,您可以将其计数为n。
当队列不为空时,将运行第三个称为存储管理器的服务,该服务将消息发送到存储解决方案(不管是mongo、redis、good ol‘sql),它将确保按照队列中接收到的消息的顺序来处理增量/减少消息。如果要使用该时间戳对队列进行排序,还可以在消息中包含来自员工服务的时间戳。
通常,用于烧瓶的任何托管环境都将使用gunicorn作为生产web服务器,并支持多个并发工作实例来处理http请求,这自然就是您的工作人员服务。
如何构建和协调队列管理器和存储管理器取决于实现偏好,例如,您可以使用像Google pub/子系统这样的工具在不同部署的服务之间发送消息,但这完全是头等大事。做这件事有很多不同的方法,你最有能力决定这一点。
如果不知道您试图实现什么以及并发通信的要求,我就不能详细说明,但这大概是我过去处理此类问题的方式。如果您需要在网站上处理更多并发用户,您可以选择一个具有更多并发工作人员的托管解决方案。如果需要更长的队列,可以选择内存更多的主机,或者将队列写入中间存储器。这将减缓它的速度,但将使从崩溃中恢复更容易。
您还需要考虑如何处理不同服务之间的消息失败、如何从服务崩溃或队列填充中恢复。
编辑:周末一直在考虑这个问题,一个简单得多的解决方案就是直接从处理用户点击的烧瓶路径中在表中创建一个新记录。那么,要得到你的总数,你只需从这张桌子上数一数。您的瓶颈将是您的烧瓶宿主环境支持多少并发工作人员,以及您的存储支持多少并发连接。这两个问题都可以通过向他们投入更多的资源来解决。
发布于 2022-07-11 09:30:26
https://stackoverflow.com/questions/72909844
复制相似问题