具有负载平衡的REST服务

我一直在考虑REST服务的优点,整个无状态和会话亲和力“东西”.令我印象深刻的是,如果您的基础架构中的许多计算机上有多个部署的服务版本,并且它们都在给定资源上运行,那么该资源的状态存储在哪里?

在基础设施中使用分布式缓存的单个主机,以及在服务内部进行更改的任何状态,它只是获取/放入缓存是否有意义?这将允许任何数量的已部署服务用于加载平衡原因,所有服务都看到相同的资源状态视图.

如果您正在设计一个高负载系统(通常意味着高可靠性),那么单点故障绝不是一个好主意.如果提供一致视图的服务出现故障,那么随着数据库查询所有内容,性能会急剧下降,最糟糕的是,整个应用程序将停止工作.

在你的问题中,你似乎担心一致性.如果有关于eBay’s architecture的东西需要学习,那就是有一个trade-off to be made between availability/redundancy/performance vs consistency.你可能会发现不需要100%的一致性,你可以摆脱一点“混乱”.

分布式缓存(如memcache)可用作distributed hashtable的后备,distributed hashtable已广泛用于创建可扩展的基础架构.如果正确实现,缓存可以是冗余的,缓存可以动态加入和离开环.

REST本身也是可缓存的,因为可以通过适当使用头(ETags)和软件(例如Squid代理作为Reverse proxy)来缓存HTTP层.通过标头指定缓存的一个缺点是它依赖于客户端解释并尊重它们.

但是,请注释Phil Karlton,caching is hard.您必须对缓存的数据,缓存数据以及如何使缓存无效进行选择.无效可以通过以下方式完成:

>通过基于计时器的手段(缓存2分钟,然后重新加载)
>更新进入时,使包含相关数据的所有缓存无效.

我偏向基于计时器的方法,因为它更容易实现,你可以相对确定地说系统中存在多长时间的数据(例如,公司详细信息将在2小时内更新,股票价格将在10秒内更新) .

最后,高负载还取决于您的使用情况,并且根据交易量,这可能不适用.方法(如果您愿意)可能如下:

>确保系统在没有缓存的情况下正常运行(是否有效)
>它是否符合性能标准(例如请求/秒,正常运行时间目标)
>优化瓶颈
>在需要时实施缓存

毕竟,您可能首先没有性能问题,并且您可以使用单个数据库和良好的备份策略.

相关文章
相关标签/搜索