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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Ask HN: Options for handling state at the edge?

72 点作者 CaptainJustin大约 3 年前
With Cloudflare workers able to be called single digit ms away from customers on much of the planet now, I wonder how I can keep state as close to the workers &#x2F; lambdas as possible.<p>What are the options we have for handling state as the edge? What do you use in your business or service?

22 条评论

powersurge360大约 3 年前
I haven&#x27;t done this, but I&#x27;ve been thinking about it lately. Fly.IO has had some very interesting ideas on this if you want to use a relational database. There was an article about litestream that would allow you to replicate your SQLite database to an arbitrary number of nodes, which means that every application server would have a SQLite file sitting on it for read queries, and then you can capture write queries and forward them to a write leader and let that user continue talking to that server until it replicates across your application servers.<p>You can do basically the same idea with any relational database, have a write leader... somewhere and a bunch of read replicas that live close to the edge.<p>There&#x27;s also what you would call cloud native data stores that purport to solve the same issue, but I don&#x27;t know much about how they work because I much prefer working w&#x2F; relational databases and most of those are NoSQL. And I haven&#x27;t had to actually solve the problem yet for work so I also haven&#x27;t made any compromises yet in how I explore it.<p>Another interesting way to go might be CockroachDB. It&#x27;s wire compatible w&#x2F; PostgreSQL and supposedly automatically clusters and shares data in the cluster. I don&#x27;t know very much about it but it seems to be becoming more and more popular and many ORMs seem to have an adapter to support it. May also be worth looking into because if it works as advertised you can get an RBDMS that you can deploy to an arbitrary number of places and then configure to talk to one another and not have to worry about replicating the data or routing correctly to write leaders and all that.<p>And again, I&#x27;m technical, but I haven&#x27;t solved these problems so consider the above to be a jumping off point and take nothing as gospel.
评论 #31349781 未加载
don-code大约 3 年前
I recently had an opportunity to build an application on top of Lambda@Edge (AWS&#x27;s equivalent of Cloudflare workers). The prevailing wisdom there was to make use of regional services, like S3 and DynamoDB, from the edge. That, of course, makes my edge application depend on calls to a larger, further away point of presence.<p>While it&#x27;s possible to distribute state to many AWS regions and select the closest one, I ended up going a different route: packaging state alongside the application. Most of the application&#x27;s state was read-only, so I ended up packaging the application state up as JSON alongside the deployment bundle. At startup, it&#x27;d then statically read the JSON into memory - this performance penalty only happens at startup, and as long as the Lambda functions are being called often (in our case they are), requests are as fast as a memory read.<p>When the state does need to get updated, I just redeploy the application with the new state.<p>That strategy obviously won&#x27;t work if you need &quot;fast&quot; turnaround on your state being in sync at all points of presence, or if users can update that state as part of your application&#x27;s workflow.
评论 #31343048 未加载
评论 #31343820 未加载
评论 #31343126 未加载
评论 #31363841 未加载
lewisl9029大约 3 年前
A lot of great info here already, but I just wanted to add my 2c as someone who&#x27;s been chasing the fast writes everywhere dream for <a href="https:&#x2F;&#x2F;reflame.app" rel="nofollow">https:&#x2F;&#x2F;reflame.app</a>.<p>Most of the approaches mentioned here will give you fast reads everywhere, but writes only fast if you&#x27;re close to some arbitrarily chosen primary region.<p>A few technologies I&#x27;ve experimented with for doing fast, eventually consistently replicated writes: DynamoDB Global Tables, CosmosDB, Macrometa, KeyDB.<p>None of them are perfect, but in terms of write latency, active-active replicated KeyDB in my fly.io cluster has everything else beat. It&#x27;s the only solution that offered _reliable_ sub-5ms latency writes (most are close to 1-2ms). Dynamo and Cosmos advertise sub-10ms, but in practice, while _most_ writes fall in that range, I&#x27;ve seen them fluctuate wildly to over 200ms (Cosmos was much worse than Dynamo IME), which is to be expected on the public internet with noisy neighbors.<p>Unfortunately, I got too wary of the operational complexity of running my own global persistent KeyDB cluster with potentially unbounded memory&#x2F;storage requirements, and eventually migrated most app state over to use Dynamo as the source of truth, with the KeyDB cluster as a auto-replicating caching layer so I don&#x27;t have to deal with perf&#x2F;memory&#x2F;storage scaling and backup. So far that has been working well, but I&#x27;m still pre-launch so it&#x27;s not anywhere close to battle tested.<p>Would love to hear stories from other folks building systems with similar requirements&#x2F;ambitions!
评论 #31346115 未加载
kevsim大约 3 年前
CloudFlare just announced their own relational DB for workers today: <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;introducing-d1" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;introducing-d1</a><p>On HN: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31339299" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31339299</a>
评论 #31345564 未加载
michaellperry71大约 3 年前
There are many technical solutions to this problem, as others have pointed out. What I would add is that data at the edge should be considered immutable.<p>If records are allowed to change, then you end up in situations where changes don&#x27;t converge. But if you instead collect a history of unchanging events, then you can untangle these scenarios.<p>Event Sourcing is the most popular implementation of a history of immutable events. But I have found that a different model works better for data at the edge. An event store tends to be centrally localized within your architecture. That is necessary because the event store determines the one true order of events. But if you relax that constraint and allow events to be partially ordered, then you can have a history at the edge. If you follow a few simple rules, then those histories are guaranteed to converge.<p>Rule number 1: A record is immutable. It cannot be modified or deleted.<p>Rule number 2: A record refers to its predecessors. If the order between events matters, then it is made explicit with this predecessor relationship. If there is no predecessor relationship, then the order doesn&#x27;t matter. No timestamps.<p>Rule number 3: A record is identified only by its type, contents, and set of predecessors. If two records have the same stuff in them, then they are the same record. No surrogate keys.<p>Following these rules, analyze your problem domain and build up a model. The immutable records in that model form a directed acyclic graph, with arrows pointing toward the predecessors. Send those records to the edge nodes and let them make those millisecond decisions based only on the records that they have on hand. Record their decisions as new records in this graph, and send those records back.<p>Jeff Doolittle and I talk about this system on a recent episode of Software Engineering Radio: <a href="https:&#x2F;&#x2F;www.se-radio.net&#x2F;2021&#x2F;02&#x2F;episode-447-michael-perry-on-immutable-architecture&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.se-radio.net&#x2F;2021&#x2F;02&#x2F;episode-447-michael-perry-o...</a><p>No matter how you store it, treat data at the edge as if you could not update or delete records. Instead, accrue new records over time. Make decisions at the edge with autonomy, knowing that they will be honored within the growing partially-ordered history.
deckard1大约 3 年前
Doesn&#x27;t Cloudflare have a cache API and&#x2F;or cache fetch calls for workers?<p>A number of people are talking about Lambda or loading files, SQLite, etc. These aren&#x27;t likely to work on CF. CF uses isolated JavaScript sandboxes. You&#x27;re not guaranteed to have two workers accessing the same memory space.<p>This is, in general, the problem with serverless. The model of computing is proprietary and very much about the fine print details.<p>edit: CF just announced their SQLite worker service&#x2F;API today: <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;introducing-d1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;introducing-d1&#x2F;</a>
fwsgonzo大约 3 年前
Just build a tiny application alongside an open source Varnish instance, and use it as a local backend. It&#x27;s &quot;free&quot; if you have decent latency to the area of Internet you care about. For example, my latency is just fine to all of Europe so I host things myself.<p>If you want to go one step further you can build a VMOD for Varnish to run your workloads inside Varnish, even with Rust: <a href="https:&#x2F;&#x2F;github.com&#x2F;gquintard&#x2F;vmod_rs_template" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gquintard&#x2F;vmod_rs_template</a>
F117-DK大约 3 年前
R2, KV, D1 and Durable Objects. Many options in the Cloudflare Suite.
crawdog大约 3 年前
I have used card database files before with success. <a href="https:&#x2F;&#x2F;cr.yp.to&#x2F;cdb.html" rel="nofollow">https:&#x2F;&#x2F;cr.yp.to&#x2F;cdb.html</a><p>Have your process regularly update the CDB file from a blob store like S3. Any deltas can be pulled from S3 or you can use a message bus if the changes are small. Every so often pull the latest CDB down and start aggregating deltas again.<p>CDB performs great and can scale to multiple GBs.
评论 #31343108 未加载
rektide大约 3 年前
I don&#x27;t have a whole lot to say on this right now (very WIP), but I have a strong belief that git is a core tool we should be using for data.<p>Most data-formats are thick-formats, pack data into a single file. Part of the effort in switching to git would be a shift to trying to unpack our data, to really make use of the file system to store fine grained pieces of data.<p>It&#x27;s been around for a while, but Irmin[1] (written in Ocaml) is a decent-enough almost-example of these kinds of practices. It lacks the version control aspect, but 9p is certainly another inspiration, as it encouraged state of all things to be held &amp; stored in fine-grained files. Git I think is a superpower, but just as much: having data which can be scripted, which speaks the lingua-franca of computing- that too is a superpower.<p>[1] <a href="https:&#x2F;&#x2F;irmin.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;irmin.org&#x2F;</a> <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8053687" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8053687</a> (147 points, 8 years ago, 25 comments)
评论 #31343545 未加载
评论 #31345118 未加载
Joel_Mckay大约 3 年前
Depends what your problem scope entails, but in general it comes down to a few key design choices and trade-offs. 1. Application layer load-balancing which allows for high-latency out-of-band idempotent transaction state consolidation between peers (rabbitMQ or Kafka often used to handle backlogs). This is hard to do, as other teams will break what they don&#x27;t understand. 2. A non-polyglot solution like Erlang&#x2F;Elixir which has “peer-state-awareness” and channels (functionally act like microservices) baked into the distributed OTP. i.e. the state is shared among peers through a simple abstraction, and only the assigned roles differ in non-persistent “edge” instances. 3. If you think in terms of classic data-center AWS partitions or sequentially indexed databases... you are likely approaching this wrong... just give up an go with Hyperledger Fabric.<p>YMMV, I just discovered my favorite game on my phone was intended for cats. ;-)<p>Cheers, J
adam_arthur大约 3 年前
Depends on your product, but I&#x27;m able to do everything via Cloudflare workers, KV, DurableObjects, and use JSON files stored in Cloudflare CDN as source of truth (hosted for free btw)<p>Cloudflare KV can store most of what you need in JSON form, while DurableObjects let you model updates with transactional guarantees.<p>My app is particularly read heavy though, and backing data is mostly static (but gets updated daily).<p>Honestly after using Cloudflare feel like they will easily become the go to cloud for building small&#x2F;quick apps. Everything is integrated much better than AWS and way more user friendly from docs and dev experience perspective. Also their dev velocity on new features is pretty insane.<p>Honestly didn&#x27;t think that much of them until I started digging into these things.<p>Edit: And just today their S3 competitor entered open beta <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;r2-open-beta&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;r2-open-beta&#x2F;</a>
efitz大约 3 年前
AWS Lambda functions have a local temp directory. I have successfully used that in the past to store state.<p>In my application, I had a central worker process that would ingest state updates and would periodically serialize the data to a MySQL database file, adding indexes and so forth and then uploading a versioned file to S3.<p>My Lambda workers would check for updates to the database, downloading the latest version to the local temp directory if there was not a local copy or if the local copy was out of date.<p>Then the work of checking state was just a database query.<p>You can tune timings etc to whatever your app can tolerate.<p>In my case the problem was fairly easy since state updates only occurred centrally; I could publish and pull updates at my leisure.<p>If I had needed distributed state updates I would have just made the change locally without bumping version, and then send a message (SNS or SQS) to the central state maintainer for commit and let the publication process handle versioning and distribution.
ccouzens大约 3 年前
I&#x27;ve got a Fastly compute@edge service. My state is relatively small (less than a MB of JSON) and only changes every few hours. So I compile the state into the binary and deploy that.<p>I can share a blog post about this if there is interest.<p>It gives us very good performance (p95 under 1ms) as the function doesn&#x27;t need to call an external service.
评论 #31346440 未加载
tra3大约 3 年前
I never thought of this, but now I have a lot of questions. Do you have an application in mind where this would be useful? Most of my experience if with traditional webapps&#x2F;SaaS so I&#x27;d love to see an example.
jFriedensreich大约 3 年前
it really depends on the type of state:<p>cloudflare kv store is great if the supported write pattern fits<p>if you need something with more consistency between pops durable objects should be on your radar<p>i also found that cloudant&#x2F;couchdb is a perfect fit for a lot of usecases with heavy caching in the cf worker. its also possible to have multiple master replication with each couchdb cluster close to the local users, so you dont have to wait for writes to reach a single master on the other side of the world
Elof大约 3 年前
Check out Macrometa, a data platform that uses CRDTs to manage state a N number of pops and also does real time event processing. - <a href="https:&#x2F;&#x2F;macrometa.com" rel="nofollow">https:&#x2F;&#x2F;macrometa.com</a> (full disclosure, I work at Macrometa)
marzoeva大约 3 年前
We&#x27;re tackling this problem at ReadySet. TLDR, ReadySet connects to your existing relational database and caches SQL query results at the edge based on the actual traffic patterns in those regions. Our goal is to augment rather than replace the database as the source of truth. You can sign up for our early access list here: <a href="https:&#x2F;&#x2F;readyset.io" rel="nofollow">https:&#x2F;&#x2F;readyset.io</a>
innerzeal大约 3 年前
You can also look at Seaplane.io - provides a postgres compatible database at the edge
asdf1asdf大约 3 年前
You just developed your application from the cache inwards, instead of the application outwards.<p>Now on to develop the actual application that will host&#x2F;serve your data to said cache layer.<p>If you learn basic application architecture concepts, you won&#x27;t be fooled by sales person lies again.
rad_gruchalski大约 3 年前
Cloudflare Workers with k&#x2F;v store, R2 and their new D1 database.
weatherlight大约 3 年前
Fly.io