High scalability with Fanout and Fastly
转自:http://blog.fanout.io/2017/11/15/high-scalability-fanout-fastly/
Fanout Cloud is for high scale data push. Fastly is for high scale data pull. Many realtime applications need to work with data that is both pushed and pulled, and thus can benefit from using both of these systems in the same application. Fanout and Fastly can even be connected together!
Using Fanout and Fastly in the same application, independently, is pretty straightforward. For example, at initialization time, past content could be retrieved from Fastly, and Fanout Cloud could provide future pushed updates. What does it mean to connect the two systems together though? Read on to find out.
Proxy chaining
Since Fanout and Fastly both work as reverse proxies, it is possible to have Fanout proxy traffic through Fastly rather than sending it directly to your origin server. This provides some unique benefits:
Cached initial data. Fanout lets you build API endpoints that serve both historical and future content, for example an HTTP streaming connection that returns some initial data before switching into push mode. Fastly can provide that initial data, reducing load on your origin server.
Cached Fanout instructions. Fanout’s behavior (e.g. transport mode, channels to subscribe to, etc.) is determined by instructions provided in origin server responses, usually in the form of special headers such as
Grip-Hold
andGrip-Channel
. Fastly can cache these instructions/headers, again reducing load on your origin server.High availability. If your origin server goes down, Fastly can serve cached data and instructions to Fanout. This means clients could connect to your API endpoint, receive historical data, and activate a streaming connection, all without needing access to the origin server.
Network flow
Suppose there’s an API endpoint /stream
that returns some initial data and then stays open until there is an update to push. With Fanout, this can be implemented by having the origin server respond with instructions:
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 29
Grip-Hold: stream
Grip-Channel: updates
{"data": "current value"}
When Fanout Cloud receives this response from the origin server, it converts it into a streaming response to the client:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: Transfer-Encoding
{"data": "current value"}
The request between Fanout Cloud and the origin server is now finished, but the request between the client and Fanout Cloud remains open. Here’s a sequence diagram of the process:
Since the request to the origin server is just a normal short-lived request/response interaction, it can alternatively be served through a caching server such as Fastly. Here’s what the process looks like with Fastly in the mix:
Now, guess what happens when the next client makes a request to the /stream
endpoint?
That’s right, the origin server isn’t involved at all! Fastly serves the same response to Fanout Cloud, with those special HTTP headers and initial data, and Fanout Cloud sets up a streaming connection with the client.
Of course, this is only the connection setup. To send updates to connected clients, the data must be published to Fanout Cloud.
We may also need to purge the Fastly cache, if an event that triggers a publish causes the origin server response to change as well. For example, suppose the “value” that the /stream
endpoint serves has been changed. The new value could be published to all current connections, but we’d also want any new connections that arrive afterwards to receive this latest value as well, rather than the older cached value. This can be solved by purging from Fastly and publishing to Fanout Cloud at the same time.
Here’s a (long) sequence diagram of a client connecting, receiving an update, and then another client connecting:
At the end of this sequence, the first and second clients have both received the latest data.
Rate-limiting
One gotcha with purging at the same time as publishing is if your data rate is high it can negate the caching benefit of using Fastly.
The sweet spot is data that is accessed frequently (many new visitors per second), changes infrequently (minutes), and you want changes to be delivered instantly (sub-second). An example could be a live blog. In that case, most requests can be served/handled from cache.
If your data changes multiple times per second (or has the potential to change that fast during peak moments), and you expect frequent access, you really don’t want to be purging your cache multiple times per second. The workaround is to rate-limit your purges. For example, during periods of high throughput, you might purge and publish at a maximum rate of once per second or so. This way the majority of new visitors can be served from cache, and the data will be updated shortly after.
An example
We created a Live Counter Demo to show off this combined Fanout + Fastly architecture. Requests first go to Fanout Cloud, then to Fastly, then to a Django backend server which manages the counter API logic. Whenever a counter is incremented, the Fastly cache is purged and the data is published through Fanout Cloud. The purge and publish process is also rate-limited to maximize caching benefit.
The code for the demo is on GitHub.
High scalability with Fanout and Fastly的更多相关文章
- spring amqp rabbitmq fanout配置
基于spring amqp rabbitmq fanout配置如下: 发布端 <rabbit:connection-factory id="rabbitConnectionFactor ...
- 可扩展性 Scalability
水平扩展和垂直扩展: Horizontal and vertical scaling Methods of adding more resources for a particular applica ...
- RabbitMQ Exchange中的fanout类型
fanout 多播 在之前都是使用direct直连类型的交换机,通过routingkey来决定把消息推到哪个queue中. 而fanout则是把拿到消息推到与之绑定的所有queue中. 分析业务,怎样 ...
- RabbitMQ学习笔记4-使用fanout交换器
fanout交换器会把发送给它的所有消息发送给绑定在它上面的队列,起到广播一样的效果. 本里使用实际业务中常见的例子, 订单系统:创建订单,然后发送一个事件消息 积分系统:发送订单的积分奖励 短信平台 ...
- What is the difference between extensibility and scalability?
You open a small fast food center, with a serving capacity of 5-10 people at a time. But you have en ...
- Achieving High Availability and Scalability - ARR and NLB
Achieving High Availability and Scalability: Microsoft Application Request Routing (ARR) for IIS 7.0 ...
- Improve Scalability With New Thread Pool APIs
Pooled Threads Improve Scalability With New Thread Pool APIs Robert Saccone Portions of this article ...
- A Flock Of Tasty Sources On How To Start Learning High Scalability
This is a guest repost by Leandro Moreira. When we usually are interested about scalability we look ...
- SSIS ->> Reliability And Scalability
Error outputs can obviously be used to improve reliability, but they also have an important part to ...
随机推荐
- LOJ2001 SDOI2017 树点涂色 LCT、线段树
传送门 注意到每一次\(1\ x\)操作相当于一次LCT中的access操作.由LCT复杂度证明可以知道access的总次数不会超过\(O(nlogn)\),我们只需要模拟这个access的过程并在其 ...
- map小列
// 有关学生信息的头文件student.h代码如下 #include #include using namespace std; struct Student ...
- 【开发笔记】- Java中关于HashMap的元素遍历的顺序问题
今天在使用如下的方式遍历HashMap里面的元素时 for (Entry<String, String> entry : hashMap.entrySet()) { MessageForm ...
- 【转载】 C#中使用int.TryParse方法将字符串转换为整型Int类型
在C#编程过程中,将字符串string转换为整型int过程中,时常使用的转换方法为int.Parse方法,但int.Parse在无法转换的时候,会抛出程序异常,其实还有个int.TryParse方法可 ...
- 笔记本端查看以前的wifi密码
家里老人忘记密码了.好像是我改了从,我也忘了,手中安卓手机root后也没找到记录密码的文件,水果机懒得弄了,突然想起来电脑还有记录,应该可以找到. 此篇也顺带记录下怎么通过手中笔记本找到以前练过的wi ...
- mongos
官方文档:https://docs.mongodb.com/manual/reference/program/mongos/#bin.mongos mongos是MongoDB shard的缩写,它是 ...
- java-Ehcache缓存
springmvc配置文件: <beans .... xmlns:cache="http://www.springframework.org/schema/cache" xs ...
- StringUtils系列之StringUtils.isNotBlank()和StringUtils.isNotBlank()的区别
/** 1. * StringUtils.isNotBlank(); * 判断参数是否不为空. * 1.如果不为空返回true. * 2.如果为空返回false. * StringUtils.isNo ...
- Linux_安装maven
安装maven 1.首先要已经安装JDK 2.下载安装包,可以安装包下: 下载地址:https://mirrors.cnnic.cn/apache/maven/ wget https://mirror ...
- USB之hub3
============= 本系列参考 ============= <圈圈教你玩USB>.<Linux那些事儿之我是USB> 协议文档:https://www.usb.or ...