TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Scaling a High-Traffic Rate Limiting Stack with Redis Cluster

213 点作者 momonga大约 7 年前

13 条评论

jihadjihad大约 7 年前
Redis IMHO is in the pantheon of excellent open-source projects, right up there with the likes of HAProxy in terms of code quality, speed, and downright reliability. 100% agree with the notion that more such building blocks need to be built.
评论 #16942605 未加载
papercruncher大约 7 年前
We use Redis Cluster quite extensively. The one thing to be very cautious and load test if running in a cloud environment is failover of nodes that are very loaded in terms of keys. If your nodes are holding multiple GBs of data, and depending on your persistence and other configuration settings, Redis may need to hit the disk to recover. If you don't have enough IOPS provisioned, be prepared for a long recovery time. The other thing that used to be problem but is getting much better now is the maturity of the different client libraries with respect to handling Redis Cluster specific idiosyncrasies.
评论 #16944326 未加载
评论 #16946082 未加载
chucky_z大约 7 年前
Excellent article! The use of Lua solves a lot of potential issues here with competing writes to similar spaces for rate limiting, causing potential bizarre errors.<p>The one thing I would note that doesn&#x27;t seem to be covered is if you are using a relatively large Lua script and running eval over and over it&#x27;s getting cached every time, instead `SCRIPT LOAD ...` can be ran, which spits out a sha1 which can then be ran with `EVALSHA (sha1) (keys) (args)`. This can potentially speed stuff up as well as cutting back on memory.
评论 #16942659 未加载
baconomatic大约 7 年前
I couldn&#x27;t agree more with &quot;We need more building blocks like Redis that do what they’re supposed to, then get out of the way.&quot; Redis has become such a foundational piece of software for me and the projects I work on.<p>Plus, it&#x27;s just plain fun to use.
评论 #16942287 未加载
dividuum大约 7 年前
I wonder if this would also be a use case for foundationdb. All the &quot;clustering&quot; would be built-in and performance seems to be quite good (<a href="https:&#x2F;&#x2F;apple.github.io&#x2F;foundationdb&#x2F;performance.html" rel="nofollow">https:&#x2F;&#x2F;apple.github.io&#x2F;foundationdb&#x2F;performance.html</a>), although probably not comparable to redis with configuration that accepts data loss. Anyone has experience with that?
评论 #16944162 未加载
sciurus大约 7 年前
It&#x27;s nice to hear a success story about Redis Cluster. When I worked at Eventbrite we used Redis heavily, both for the usual use cases (caching, ephemeral storage like sessions) as well as at the core of services like reserved seating. We did our own sharding client side as a layer on top of the redis-py library and relied on sentinel to handle failover. After Redis Cluster was released, we had some interest in it, but were were nervous enough about the limitations in its capabilities and the additional complexity of operating it that we never experimented with it.
ttul大约 7 年前
I fucking love Redis. We use it inside a large scale email sending platform to do all manner of rate limiting and real time analysis of streaming data to make routing decisions. Could not live without Redis.
garganzol大约 7 年前
Author has an enjoyable writing style. Thumbs up for quality writing.
评论 #16944124 未加载
shizcakes大约 7 年前
Another approach to this problem is to use Twemproxy: <a href="https:&#x2F;&#x2F;github.com&#x2F;twitter&#x2F;twemproxy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;twitter&#x2F;twemproxy</a>, which can be used like a sidecar Redis load-balancer.
评论 #16943681 未加载
评论 #16947479 未加载
abalone大约 7 年前
Silly question but any idea what tools were used to create the diagrams in this post?
评论 #16942332 未加载
pulkitsh1234大约 7 年前
More details on Stripe&#x27;s rate limiter(s): <a href="https:&#x2F;&#x2F;stripe.com&#x2F;blog&#x2F;rate-limiters" rel="nofollow">https:&#x2F;&#x2F;stripe.com&#x2F;blog&#x2F;rate-limiters</a>. An awesome gist is given at the bottom too, which has implementations of the different rate limiters, And also the `EVAL` part this post talks about.
xstartup大约 7 年前
In adtech, we average over a 100 million operations per second and we don&#x27;t even touch redis.<p>We&#x27;ve been using Memcache all while and have no desire to change that.
评论 #16947377 未加载
评论 #16947351 未加载
评论 #16944064 未加载
sandGorgon大约 7 年前
isnt this the exact usecase that kafka solves ? Its great to see redis being able to do it just as well as kafka probably.<p>I&#x27;m quite interested to see how they implemented a queueing solution without the new Redis Streams infrastructure.