1605079781
Implementing a sliding log rate limiter with Redis and Golang
Introduction
I work on an application that communicates with multiple payment providers. Each provider has their own rate limit for us. We did not want to exhaust our rate limit with any of the payment providers, while also making the most of what limits we are allowed. We could afford to delay requests to the payment provider for a small amount of time, as bulk payments are processed offline as async jobs.
During an average billing day, we run a large number of payments in a short span of time. Are we breaching our payment processors’ rate limits? Should we do something about that? I’ve heard about something called a rate limiter.
What is a rate limiter? A rate limiter caps the number of requests a sender can issue in a specific time window. It then blocks requests once the limit is reached.
Usually the rate limiter component is at the receiving system, but since we depend so heavily on third party processors, it also makes sense to accommodate the provider’s rate limit and control outbound requests so as to not get too many — or optimistically, even a single
We started designing the rate limiter with these requirements in mind:
- It should limit the number of requests in a given time period to a particular payment provider
- Since our systems run on a cluster (as opposed to a single server), the rate limit should apply on the sum total of requests made, and not per application process.
- Our late limiting logic should be atomic, and not fail even if multiple requests land on our systems concurrently
#rate-limiting #golang #lua #redis
What is GEEK
Buddha Community
1605079781
Implementing a sliding log rate limiter with Redis and Golang
Introduction
I work on an application that communicates with multiple payment providers. Each provider has their own rate limit for us. We did not want to exhaust our rate limit with any of the payment providers, while also making the most of what limits we are allowed. We could afford to delay requests to the payment provider for a small amount of time, as bulk payments are processed offline as async jobs.
During an average billing day, we run a large number of payments in a short span of time. Are we breaching our payment processors’ rate limits? Should we do something about that? I’ve heard about something called a rate limiter.
What is a rate limiter? A rate limiter caps the number of requests a sender can issue in a specific time window. It then blocks requests once the limit is reached.
Usually the rate limiter component is at the receiving system, but since we depend so heavily on third party processors, it also makes sense to accommodate the provider’s rate limit and control outbound requests so as to not get too many — or optimistically, even a single
We started designing the rate limiter with these requirements in mind:
- It should limit the number of requests in a given time period to a particular payment provider
- Since our systems run on a cluster (as opposed to a single server), the rate limit should apply on the sum total of requests made, and not per application process.
- Our late limiting logic should be atomic, and not fail even if multiple requests land on our systems concurrently
#rate-limiting #golang #lua #redis
1596679140
Redis Transactions & Long-Running Lua Scripts
Redis offers two mechanisms for handling transactions – MULTI/EXEC based transactions and Lua scripts evaluation. Redis Lua scripting is the recommended approach and is fairly popular in usage.
Our Redis™ customers who have Lua scripts deployed often report this error – “BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE”. In this post, we will explain the Redis transactional property of scripts, what this error is about, and why we must be extra careful about it on Sentinel-managed systems that can failover.
Transactional Nature of Redis Lua Scripts
Redis “transactions” aren’t really transactions as understood conventionally – in case of errors, there is no rollback of writes made by the script.
“Atomicity” of Redis scripts is guaranteed in the following manner:
- Once a script begins executing, all other commands/scripts are blocked until the script completes. So, other clients either see the changes made by the script or they don’t. This is because they can only execute either before the script or after the script.
- However, Redis doesn’t do rollbacks, so on an error within a script, any changes already made by the script will be retained and future commands/scripts will see those partial changes.
- Since all other clients are blocked while the script executes, it is critical that the script is well-behaved and finishes in time.
The ‘lua-time-limit’ Value
It is highly recommended that the script complete within a time limit. Redis enforces this in a weak manner with the ‘lua-time-limit’ value. This is the maximum allowed time (in ms) that the script is allowed to run. The default value is 5 seconds. This is a really long time for CPU-bound activity (scripts have limited access and can’t run commands that access the disk).
However, the script is not killed when it executes beyond this time. Redis starts accepting client commands again, but responds to them with a BUSY error.
If you must kill the script at this point, there are two options available:
- SCRIPT KILL command can be used to stop a script that hasn’t yet done any writes.
- If the script has already performed writes to the server and must still be killed, use the SHUTDOWN NOSAVE to shutdown the server completely.
It is usually better to just wait for the script to complete its operation. The complete information on methods to kill the script execution and related behavior are available in the documentation.
#cloud #database #developer #high availability #howto #redis #scalegrid #lua-time-limit #redis diagram #redis master #redis scripts #redis sentinel #redis servers #redis transactions #sentinel-managed #server failures
1604285631
Custom Rate Limiting in GoLang using Redis with Docker
Introduction
The world is moving towards a micro-service oriented Systems. It’s really important to prevent web services from attacks such as DOS(Denial of service). Rate limiting is generally put in place as a defensive measure for services. To protect services from excessive use whether intended or unintended. It also helps to ensure service availability to all the clients in a fair manner.
While this capability can be easily integrated using Reverse proxy servers with the applications. Generally, Reverse Proxy servers do rate limiting based on the number of times client has hit the service. But, there might be scenarios where you want to enable rate-limiting based on other attributes. For e.g. say, you might want to rate-limit a client based on the number of records requested by the client from the database. So, it’s always an add on to understand how this capability can be extended in the applications.
Let’s try to create a custom implementation of Rate Limiting.
Prerequisites
Having a fair understanding of:
- GoLang
- Docker
- Redis — For caching IP to count mapping
#golang #redis #rate-limiting #docker
1665072840
Redis_rate: Rate Limiting for Go-redis
Rate limiting for go-redis
❤️ Uptrace.dev - distributed traces, logs, and errors in one place
This package is based on rwz/redis-gcra and implements GCRA (aka leaky bucket) for rate limiting based on Redis. The code requires Redis version 3.2 or newer since it relies on replicate_commands feature.
Installation
redis_rate supports 2 last Go versions and requires a Go version with modules support. So make sure to initialize a Go module:
go mod init github.com/my/repo
And then install redis_rate/v9 (note v9 in the import; omitting it is a popular mistake):
go get github.com/go-redis/redis_rate/v9
Example
package redis_rate_test
import (
"context"
"fmt"
"github.com/go-redis/redis/v8"
"github.com/go-redis/redis_rate/v9"
)
func ExampleNewLimiter() {
ctx := context.Background()
rdb := redis.NewClient(&redis.Options{
Addr: "localhost:6379",
})
_ = rdb.FlushDB(ctx).Err()
limiter := redis_rate.NewLimiter(rdb)
res, err := limiter.Allow(ctx, "project:123", redis_rate.PerSecond(10))
if err != nil {
panic(err)
}
fmt.Println("allowed", res.Allowed, "remaining", res.Remaining)
// Output: allowed 1 remaining 9
}Download Details:
Author: Go-redis
Source Code: https://github.com/go-redis/redis_rate
License: BSD-2-Clause license
1633584720
jQueryのSlideToggleアニメーション効果メソッド
このチュートリアルでは、html要素またはWebページでこのメソッドを使用する方法を学習します。
このチュートリアルでは、jQueryのslideToggleアニメーション効果とは何かを、この効果の使用方法の簡単な例とともに示します。また、slideToggleメソッドを使用して非表示のHTML要素を表示する方法を学習します。
jQuerySlideToggleアニメーション効果
SlideToggle（）アニメーションメソッドはslideToggle()、選択したHtml要素を（非表示/表示）するために使用されます。jQueryslideToggle()メソッドは、選択した要素の高さを増減することにより、要素を表示または非表示にします。
slideToggle（）メソッドは、選択したhtml要素のslideUp（）とslideDown（）を切り替えます。
構文
$（selector）.slideToggle（）;
$（selector）.slideToggle（speed、callback）;
$（selector）.slideToggle（speed、easing、callback）;slideToggleメソッドのパラメーター
- speed：-引数 'speed'は、この効果の持続時間を決定します。
- イージング：-遷移に使用するイージング機能を指定します。
- コールバック：-Ihisはオプションのパラメータです。slideToggle（）メソッドが呼び出された後に何をするかを指定できます。
jQuery slideToggle（）の例
以下の例では、slideToggle（）メソッドの効果を確認できます。
<!DOCTYPE html>
<html>
<title>jQuery Slide Toggle</title>
<script src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
<script>
$(document).ready(function(){
$("button").click(function(){
$("#slide_div").slideToggle("slow");
});
});
</script>
<style>
#slide_div{
padding: 5px;
text-align: center;
background-color: #00FFFF;
border: solid 1px #c3c3c3;
}
#slide_div {
padding: 50px;
display:none;
}
</style>
</head>
<body>
<button id="btn-up">Click Me to slide Toggle</button>
<div id="slide_div"><b>Hello</b> <br><br>Thank for trying this</div>
</body>
</html> slideToggleとコールバックの例
<!DOCTYPE html>
<html>
<title>jQuery Slide Toggle</title>
<script src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
<script>
$(document).ready(function(){
$("button").click(function(){
$("#slide_div").slideToggle("slow", function(){
alert("The slideToggle effect is completed.");
});
});
});
</script>
<style>
#slide_div{
padding: 5px;
text-align: center;
background-color: #00FFFF;
border: solid 1px #c3c3c3;
}
#slide_div {
padding: 50px;
display:none;
}
</style>
</head>
<body>
<button id="btn-up">Click Me to slide Toggle</button>
<div id="slide_div"><b>Hello</b> <br><br>Thank for trying this</div>
</body>
</html> コールバックを使用したslideToggle（）メソッドの上記の例では、html要素に対するコールバックを使用したslideToggle（）の効果を確認できます。