我正在建立一个网站，用户可以在这里观看视频并点击任意次数。对于那些了解它的人来说，这有点像Periscope的"Hearts"功能。
观众目前正在网络浏览器上观看视频。每个"赞"都被输入到heroku托管的REDIS实例中，所以写/读相当便宜。然而，由于许多用户同时观看视频，因此可能存在高的同时输入率。
在这种情况下，我面临两种选择：
- 每当用户"点赞"时，都会向REDIS实例发送一个事件。方便：立即用所有相关信息讲述"赞"。不便：服务器上同时有很多点赞
- 在本地缓存"点赞"，并仅在会话结束后发送到REDIS。问题：用户可以随时关闭浏览器（可能永远不会返回），因此"赞"信息可能会永久丢失
关于哪种选择更可取，有什么建议吗？
不要缓存。
首先，这是一个非常复杂的问题，因为你不知道会议什么时候真正结束。
其次，Redis的增量可能和你的缓存一样快。我敢打赌，你只关心Rails，而不是Redis。
你可能最终想要制作另一个端点——也许是一个简单的Sinatra应用程序——来简单地处理点赞。我注意到autosuggest gems有时会这样做（例如），它节省了rails请求的所有开销。
如果它是一个成功的应用程序，那么问题可能是有人写了一个脚本来不断地"点赞"。随着时间的推移，您可能需要设置一些限制，以允许有限数量的请求。