isN*_*247 1 couchdb rate-limiting redis
我用CouchDB后端编写了一个应用程序.我花了很多时间在CouchDB上,所以我不愿意把所有东西都移到不同的NoSQL数据库(比如Redis).
问题是我现在需要实现速率限制(基于IP地址)功能.
有很多关于Redis如何用于此类任务的示例,但是因为我不想将CouchDB丢弃用于其他任务,这意味着我基本上将运行(并支持)两个数据库(1个用于大多数数据,1个用于限速)等......
是否与Redis一起运行CouchDB闻所未闻？
Redis通常用于补充其他存储解决方案(MySQL,PostgreSQL,MongoDB,CouchDB等).与许多其他NoSQL解决方案一样,Redis不适用于所有类型的工作负载或情况.Redis的作者是务实和开放的人,当他们更适应这种情况时,他们通常建议使用其他解决方案而不是Redis.
因此,Redis是一个优秀的团队合作者,通常很容易集成到现有的基础架构中.
CouchDB本身是否适合处理速率限制本身？
CouchDB有许多有用的功能来实现Chris O'Hara的文章中描述的速率限制策略.例如,它支持对多个文档进行批量操作(具有可选的原子性)."桶跨度"可以存储在单个文档中.可以使用更新处理程序覆盖计数器的就地增量.
IMO,主要的缺失功能是自动项目到期(CouchDB不提供AFAIK).所以你必须设计一个聪明的机制来摆脱CouchDB之上的过时数据.
主要问题是CouchDB并非真正针对这种工作负载而设计:它是一个面向日志结构化文档的数据库.每次计数器必须递增时,它将涉及JSON解包/打包操作,要执行的一些Javascript代码,以及仅附加文件来编写整个文档的新修订版.你可以找到一个很好的文章描述的CouchDB如何将其数据存储在这里.
我怀疑在CouchDB之上实现的速率限制策略不能很好地扩展(太多的I/O,太多的CPU消耗,低效的网络协议).例如,CouchDB是一个RESTful服务器; 我不习惯启动客户端HTTP操作(对CouchDB的REST查询)来限制我的系统的每个传入HTTP查询.
Redis更适应这种工作负载(快速,内存中,没有I/O,高效的客户端协议,没有JSON解析/格式化,增量是本机原子操作等等)
| 归档时间： |
|
| 查看次数： |
1316 次 |
| 最近记录： |