当前位置:首页 > 人工智能

后端缓存的23个关键关注点

发布时间:2019-05-08 18:05:55   编辑:it技术学习网   阅读次数:

23个重点关注的后端缓存
摘要:建议使用缓存操作分离使用不同的缓存实例核心和非核心业务服务进行物理隔离,如果某些条件下,使用一个单独的实例为每个服务,或群集,以减少应用程序之间相互影响的可能性。关键词:后端缓存

▌1:简约缓存架构

通过JSR107说明书中,我们将定义为客户机层的框架,设置在缓冲层,缓冲管理,高速缓冲存储器层。其中,基本层被划分为存储层,所述LRU弱存储层和存储层,的高速缓冲存储器,如图。

\

高速缓存层次结构图

其中:

客户端层:一个用户直接与通过该层的数据进行交互。

Cach?提供层:主要的缓存管理生命周期的维护,缓存管理负责创建,保存,访问和破坏。

缓存管理:主要是客户端的缓存生命周期维护,负责缓存客户端创建,保存,检索和销毁

高速缓存层:负责储存在什么样的形式数据。

基本存储层:的ConcurrentHashMap是共同的存储核心数据没有被消除。

LRU存储层:根据数据的存储和高速缓存机制消除最近最少使用的原则进行。

弱存储层:是弱引用的数据存储和高速缓存机制消除的原理。

▌2:能力评估

缓存系统主要由服务器上的存储器消耗,需要因此,必须在应用程序的数据大小来评价,在使用高速缓冲存储器的被高速缓存,包括高速缓冲存储器的数据结构,高速缓存大小,高速缓存的数量,高速缓存根据在未来一段时间内的服务情况估计的容量使用过期时间,然后自己,容量应用评估和缓存资源分配的结果,否则会造成资源或缓冲空间不足的浪费。

▌3:业务隔离

推荐使用缓存的操作分离的核心,并使用不同的缓存实例非核心业务服务进行物理隔离,如果某些条件下,使用一个单独的实例为每个服务或集群应用之间,以减少相互影响的可能性。我经常听到一些企业使用共享高速缓存,从而导致缓存数据被覆盖和高速缓存的数据乱码线事故。

▌4:监控为王

所有缓存实例需要添加监测,这是非常重要的,我们需要查询速度慢,大对象,内存使用情况的可靠的监控。

▌5:无故障时间

任何缓存键必须设置缓存过期时间和过期时间在某些时候无法集中注意力,否则会导致高速缓冲存储器或高速缓存填充雪崩。

▌6:大量的时间关键的危害的同时失效

当使用超高速缓冲存储器需要设计充分考虑如何避免常见的缓冲渗透,雪崩缓存,缓存并发的问题,特别是对高并发使用缓存,开展随机密钥设置所需的到期时间,例如,到期时间设置为10秒+随机(2),到期时间被设定为10到随机12秒。

我看到的情况:大量具有固定到期时间,设置应用程序键一起使用时高速缓存未命中会造成一段时间的数据库同时访问,从而导致更大的压力对数据库缓冲区。

▌7:在更新数据库更新缓存有啥问题?

试想一下,如果两个线程同时执行更新操作,更新数据库线程1,线程2也更新了数据库,然后开始写高速缓存,但是线程2做手术更新缓存,而线程1在规定的时间执行更新缓存把线程2更新数据覆盖,所以会出现数据不一致。

▌8:先删除缓存,没关系?

“先删除缓存,然后执行数据库事务”这一方案进行了讨论,但这种操作等商品的查询是经常出差不适用,因为在同一时间删除缓存已经有另外一个系统读取高速缓存,而这次交易尚未提交。当然,对于这样的用户的服务尺寸预期。

▌9:数据库和缓存数据的一致性

方法京东通过缓存原子管使用,如图。

\

最终方案的一致性

几个关注点:

使用更新版本的时间戳或更新数据比较。

使用如运河订阅数据库二进制日志; 这里MySQL作为出版商,二进制日志的内容是公开的,管(渠增量二进制日志mysql数据库订阅阿里巴巴和消耗组件)作为消费者,运河,然后更新订阅的binlog的Redis。

根据分散到多个队列中,每个单线程和更新队列,在数据存储更新到拉相应的规则的更新请求; 获得相关的锁,然后在更新前更新。

▌10。实践更新数据库,然后删除缓存

过程如下所示:

\

过程不赘述,但他强调,一个数据库更新更改将同步发送一条消息,该消息被删除缓存。如果删除失败,有消息重试机制保证。另外除了极端的情况下,缓存是更新更及时。

▌11:本地缓存挑战

如果性能要求不是很高的话,尽量使用,而不是本地缓存分布式缓存,因为每个节点服务的本地缓存的复制,在复制之间的某一点是不一致的,如果缓存代表的开关,并有在分布式系统中的请求可以重复,造成了重复的请求会去两个节点,一个节点开关打开后,节点开关是关闭的,如果请求不幂等过程,重复过程将导致严重者可引起经济损失。

▌12:热和多级缓存缓存

对于分布式缓存,我们需要在Nginx的+ Lua的应用程序访问的应用程序缓存以减少的Redis集群的影响; 也就是说,应用程序首先查询本地的缓存,如果缓存直接命中,如果不打它着眼于Redis的集群,回到源Tomcat的; 那么本地高速缓存的应用程序数据。如图14-8。

这里使用的Nginx负载机构采纳:通常使用一致的散列,如果用于特定类型业务的请求通过阈爆发被自动降级到轮询机制。除了一些热门的秒杀活动一样,我们可以提前知道时间,相关数据可推到预申请和负载均衡机制的Nginx降级一项民意调查。

\

分布式缓存方案

它可以另外考虑建立实时系统中找到发现热的热点,如下图所示:

\

实时热点检测程序

1)将请求转发到访问的应用程序的Nginx Nginx的;

2)应用的Nginx第一读取本地缓存; 如果直接打回,分布式高速缓存未读,回源到Tomcat进行处理;

3)应用请求的Nginx将上报实时系统中的热点,如直接使用UDP报告请求,或要求写入到本地卡夫卡,或者使用本地nginx的日志水槽认购; 实时热点发现系统报告后,会热统计(风暴可视为实时计算);

4)阈值设定数据将被推到热本地缓存Nginx的应用。

由于它的本地缓存中,这样的一致性数据,我们需要考虑的是,当出现故障或更新缓存:

1)如果你可以订阅数据的变化信息,您可以订阅更改消息缓存更新;

2)如果您不能订阅消息或订阅消息传递的成本比较高,和瞬态数据的一致性并不重要(如在产品详细信息页面,查看库存,不一致可能是短暂的,只要下单一致) ,然后您可以设置新的查询数据之前过期合理的过期时间;

3)如果尖峰或类似物,可以订阅事件启用消息相关的数据推送到推进应用程序的前端,并且负载均衡机制降级轮询;

4)建立实时热点寻找热点统一的系统和推送更新。

处理缓冲热门话题:数据复制模式

\

在Facebook上有一招,通过更key_index:解决热读出的数据的问题(键XXX#N)。解决的办法是发布所有热键所有Web服务器; 每个服务器都有相应的密钥别名,你可以通过一个客户端路由算法的服务器; 做删除操作,删除所有别名关键。这可以概括为同一组的一般模型。缓存群集被分成若干组(组),在同一组中,所有的缓存服务器,数据发布在热键。

对于大量的读操作,通过客户端的路由策略,可以自由地返回到一台机器; 和写入操作,有一个解决方案是通过定时任务来写的; Facebook正在采取删除所有别名关键战略。如何保护这个批处理操作成功?

(1)数据的版本容忍引起局部故障的问题

(2)只要有一个写操作,然后刷新由定时任务的高速缓存; 如果涉及到三个服务器,你是代表任务表此记录的任务圆满完成的成功运行,否则会重试。

▌13:缓存失效连接风暴

此问题的主要原因仍然是高并发的时间,通常当我们设置一个缓存过期时间,可以设置1分钟,5分钟,可以通过高复杂,而在一定的时间和到期日期产生大量的缓存都是一样的,这时候就可能导致到期时间,这些缓存在同一时间不能转发到数据库中的所有请求,DB可能过于沉重的压力。如何解决这些问题,?

一个简单的解决办法是高速缓存期满分散,例如,我们可以添加基于原始到期时间的随机值,如1-5分钟随机的,使得每个的高速缓存期满时间的重复率会降低,以困难的集体失败导致该事件。

如果缓存集中在一段时间已过,压力DB亮点。这不是一个完美的解决方案,但可以分析用户的行为,尽量使点甚至失效时间分布。

以上是通过渗透,同时失效的过程中缓存频繁遇到复杂。一般情况下,我们解决这些问题的方法是引入一个空值,锁定机构和随机缓存过期时间。

▌14:高速缓存预热

提前读入的数据缓存方法实现数据的预热。数据预热要注意一些细节:

(1)是否有一个监督机制,以确保所述预写入的数据的成功!我遇到了一些数据成功案例影响业务的高峰期;

操作(2)易于装配有预热器数据回滚机制,回滚紧急。对于新的缓存服务器集群,您还可以通过预热模式的数据做了一些手脚。下面获取的密钥冷启动簇,如果没有取得,则集群从热获取。虽然获取的关键放入冷水集群。如下所示

\

数据预热

(3)预热的数据量来考虑,做能力评估。预热该范围中的全部金额的容量允许,或高量的热身访问。

如果(4)热身过程需要因为缓慢或批数据库操作等引起的SQL数据库性能问题的关注。

▌15:超时设计

当使用远程高速缓存(如Redis的,Memcached的),一定要设置的操作,这是非常关键的,我们一般设计为加快数据库缓存读取的手段超时,会做缓存操作的降级,它建议缩短缓存超时,如果一定要给出一个数,100毫秒或更短希望。

我曾经遇到过一个案例:一个突然的闹铃应用程序正在运行的线程数过高,不久之后内存溢出的出现。

分析其原因是:因为缓存限制连接的最大数目,应用程序不能缓存连接高速缓存和超时设置过大,导致在操作等待高速缓存访问缓存服务的回报,由于高负荷,一个永无止境的所有请求,但这些服务在等待服务的等待缓存操作的回报,这个时候,并没有超时,你不能降级,并继续访问数据库。这线程池将支持全在BIO模式,使用线程池党也支持全; 增加负载在相同的模式将NIO服务,服务响应慢,甚至服务被压碎。

▌16:不要缓存来存储

我们都知道,一个颠扑不破的真理:在分布式架构中,所有系统都可能会失败,它是否被缓存,或者存储在包括应用服务器的数据库,以及一些缓存本身并不提供持久性的机制,例如分布式缓存的。即使持久性机制缓存,应谨慎使用,因为如果只有存储的话。

▌17:缓存道路交通事故的解决方案

当我们使用分布式缓存应该考虑如何为局势作出反应,其中停工的缓存实例的一部分。常用的算法下一节介绍了分布式缓存。而当缓存的数据可能丢失的话,我们可以选择一致性哈希算法。

对于模机制如果一个坏榜样,如果去除这种情况下会导致大量的高速缓存未命中的,瞬时流量可能会导致大问题后端DB /服务出现。在这种情况下,可以采用的主要机制,以避免不良例子的问题,一个例子,其中可以从/断的主顶。但在模机制,如果加入大量的节点将导致缓存未命中,通常是根据另一个群集,然后将数据迁移到新的集群,然后迁移过去交通。

一致性哈希

对于一致性哈希机制,如果一个坏榜样,如果去除这种情况下将一致性哈希环上影响到高速缓存中的一部分不打,不会导致大量背到后端数据库的瞬间源/服务,同时也将产生一定的影响。

▌18。缓存崩溃后快速恢复

如果一些问题涉及到出现之前,请考虑以下情形:

1)主从机制,良好的冗余,我。e。,其中,所述对等体不可用的一部分填充部分;

2)如果原因是因为缓存应用程序的可用性已经拒绝考虑:

有些用户降级,然后逐步减少降解量;

由工人后台热身缓存数据。

也就是说,如果整个缓存集群被打破,并且没有备份,你只能去慢慢重建缓存; 为了允许一些用户仍然可用,根据该系统的容量,通过降级允许某些用户使用这些用户来重建相关联的缓存; 高速缓存数据通过后台工作进一步预热。

▌19。打开Nginx的代理缓存性能不升反降

打开Nginx的代理缓存,性能下降,并在一段内存使用情况的后达到98%; 解:

1)对于高内存使用率的问题是核心问题,内核采用LRU机制本身是没有问题的,但你可以修改内核参数:

sysctl的-wvm。extra_free_kbytes = 6436787

sysctl的-wvm。vfs_cache_pressure = 10000

2)上的机械磁盘高速缓存的性能较差使用代理缓存可以通过的tmpfs或nginx的字典高速缓存元数据被共享,或者使用SSD,我们目前使用的存储器的文件系统。

▌20:“当网络抖动,返回502错误”因超时而

Twemproxy配置的超时时间太长,设置5秒,但对于连接没有区别之前,读,写超时设置。然后,我们减少超时,网络设置,在不到150毫秒,动态访问服务时超时。

▌21:在处理恶意刷经验

产品详细信息页面库存接口2014恶意刷,600瓦特超过一分钟,tomcat的定时重启的唯一机访问; 详细信息页面,因为数据显示,缓存几秒钟是可以接受的,因此开放nginxproxy缓存以解决此问题,打开下降到正常水平后, 然后我们用的Nginx + Lua的基础设施改造服务,数据过滤,URL重写,等。Nginx的层完成后,通过URL一致性哈希重写+负载均衡,怕随机URL中,一些服务提高+ 10%高速缓存命中率。

▌22:卡应该出场?

随着Redis的有一个很麻烦的问题是,Redis的卡有问题打,由于高性能的Redis,在大并发请求,很容易扑克牌。通常情况下,一台服务器上的几十个Redis的实例上运行,一旦卡上播放,很容易与可用性的应用层干扰。因此,我们基于开源项目Contiv netplugin,限制使用的卡,主要功能是提供基于策略的网络和存储管理。Contiv更“诱人”的是,它的网络管理功能,无论是L2(VLAN),L3(BGP),有重叠(VXLAN),有了它,你可以忽略底层网络基础设施上容器它提供了一个一致的虚拟网络。最主要的一点是,不仅满足了业务场景,并与以前的网络架构兼容。在转发性能,它可以接近物理网络适配器的性能,特别是可以在老屋里没有千兆网络非常好。在监控网络流量方面,我们通过在主机上使用的所有网络流量的sFlow OVS的抓取,然后从一个简单的sFlow集气开发,sFlow的服务器接收到数据包解析,过滤出关键数据,然后荟萃分析,所需的数据要被监视。通过这种定制的网络插件,我们可以自由控制的Redis,交通量的流动,也不会影响其他项目,如果一个Redis的服务器上的流量是非常低的,我们也可以降低其配额,提供给其他的程序需要本机,其通过监视程序的背景可以完全自动化的大流量。

▌23:选择高速缓存组件

许多类型的高速缓存,当我们实际使用,需要缓存位置(前端系统),其中,要被存储的数据类型,访问模式,内存效率来选择最合适的高速缓存组件。本节讨论如何选择下一个将在应用层分布式缓存后端组件。

通用操作系统,大部分的数据KV的是简单数据类型,如微博客的进给系统饲料含量,饲料列表,用户信息。这些简单的数据类型只需要设置,获取,删除等操作,没有做到底在缓存中的计算操作,缓存是最合适的组件的memcached。

其次需要获得部分,事物的变化类型,高速缓存端计算数据集合,富含数据结构和访问接口Redis的可能更适合。Redis的也支持从主(主 - 从)的数据备份,以支持持久性数据,在存储器中的数据可以被保持在磁盘上,再次使用所述负载重新启动。由于性能问题磁盘高速缓存(diskstore)模式,Redis的数据的基础上只适合在存储器中,所产生的问题是:在某些业务场景中,如果要被缓存的数据量特别大,而不是业务数据或区分冷热也必须在内存中的所有数据,缓存成本(特别是机器的成本)将是特别高。如果企业遇到这种情况,可以考虑使用鼠兔,SSDB其他缓存组件。鼠,SSDB Redis的兼容协议,而使用多线程程序,并支持持久的复制,单个高速缓存可高速缓存数据实例数百G,其中所述热数据存储存储器的一小部分,大部分的热或冷的数据可以是盘面上,从而降低以及对数据高速缓存的成本。

提到的前公共缓冲部件的后端,下表,可以选择。

\

最后,对于要求更高的业务方案的存储效率,接入性能,服务功能定制设计和缓存组件的发展相结合,也是一个不错的选择。

总之,高速缓存组件的选择要考虑的数据模型,访问方法,高速缓存的成本结构和知识工作者,因地制宜地进行取舍,甚至发展,不要盲目引进不熟悉的,无效的,不成熟的缓存组件,或中途频繁调整缓存方案,将给予开发和运营维护成本带来更大的挑战。

本文链接:后端缓存的23个关键关注点

友情链接: 心经结缘 大悲咒 大悲咒功德
网站地图
it技术学习网版权所有   苏ICP备18043316号