电商网站seo优化目标分解,wordpress 4.3.4,oa软件开发,云匠网什么是热key#xff1f;
1 、MySQL等数据库会被频繁访问的热数据
如爆款商品的skuId。
2 、redis的被密集访问的key
如爆款商品的各维度信息#xff0c;skuId、shopId等。
3 、机器人、爬虫、刷子用户
如用户的userId、uuid、ip等。
4 、某个接口地址
如/sku/query或…什么是热key
1 、MySQL等数据库会被频繁访问的热数据
如爆款商品的skuId。
2 、redis的被密集访问的key
如爆款商品的各维度信息skuId、shopId等。
3 、机器人、爬虫、刷子用户
如用户的userId、uuid、ip等。
4 、某个接口地址
如/sku/query或者更精细维度的。
5、 用户id接口信息
如userId /sku/query这代表某个用户访问某个接口的频率。
6 、服务器id接口信息
如ip /sku/query这代表某台服务器某个接口被访问的频率。
7 、用户id接口信息具体商品
如userId /sku/query skuId这代表某个用户访问某个商品的频率。 以往热key问题怎么解决
我们分别以redis的热key、刷子用户、限流等典型的场景来看。
redis热key
这种以往的解决方式比较百花齐放比较常见的有
1上二级缓存读取到redis的key-value信息后就直接写入到jvm缓存一份设置个过期时间设置个淘汰策略譬如队列满时淘汰最先加入的。或者使用guava cache或caffeine cache进行单机本地缓存整体命中率偏低。
2改写redis源码加入热点探测功能有热key时推送到jvm。问题主要是不通用且有一定难度。
3改写jedis、letture等redis客户端的jar通过本地计算来探测热点key是热key的就本地缓存起来并通知集群内其他机器。
4其他
刷子爬虫用户
常见的有
1日常累积后将这批黑名单通过配置中心推送到jvm内存。存在滞后无法实时感知的问题。
2通过本地累加进行实时计算单位时间内超过阈值的算刷子。如果服务器比较多存在用户请求被分散本地计算达不到甄别刷子的问题。
3引入其他组件如redis进行集中式累加计算超过阈值的拉取到本地内存。问题就是需要频繁读写redis依旧存在redis的性能瓶颈问题。
限流
1单机维度的接口限流多采用本地累加计数
2集群维度的多采用第三方中间件如sentinel
3网关层的如Nginxlua
综上我们会发现虽然它们都可以归结到热key这个领域内但是并没有一个统一的解决方案我们更期望于有一个统一的框架它能解决所有的对热key有实时感知的场景最好是无论是什么key、是什么维度只要我拼接好这个字符串把它交给框架去探测设定好判定为热的阈值如2秒该字符串出现20次则毫秒时间内该热key就能进入到应用的jvm内存中并且在整个服务集群内保持一致性要有都有要删全删。 热key进内存后的优势
热key问题归根到底就是如何找到热key并将热key放到jvm内存的问题。只要该key在内存里我们就能极快地来对它做逻辑内存访问和redis访问的速度不在一个量级。
譬如刷子用户我们可以对其屏蔽、降级、限制访问速度。热接口我们可以进行限流返回默认值。redis的热key我们可以极大地提高访问速度。
以redis访问key为例我们可以很容易的计算出性能指标譬如有1000台服务器某key所在的redis集群能支撑20万/s的访问那么平均每台机器每秒大概能访问该key200次超过的部分就会进入等待。由于redis的瓶颈将极大地限制server的性能。
而如果该key是在本地内存中读取一个内存中的值每秒多少个万次都是很正常的不存在任何数据层的瓶颈。当然如果通过增加redis集群规模的形式也能提升数据的访问上限但问题是事先不知道热key在哪里而全量增加redis的规模带来的成本提升又不可接受。 热key探测关键指标
1、实时性
这个很容易理解key往往是突发性瞬间就热了根本不给你再慢悠悠手工去配置中心添加热key再推送到jvm的机会。它大部分时间不可预知来得也非常迅速可能某个商家上个活动瞬间热key就出现了。如果短时间内没能进到内存就有redis集群被打爆的风险。
所以热key探测框架最重要的就是实时性最好是某个key刚有热的苗头在1秒内它就已经进到整个服务集群的内存里了1秒后就不会再去密集访问redis了。同理对于刷子用户也一样刚开始刷1秒内我就把它给禁掉了。
2、准确性
这个很重要也容易实现累加数量做到不误探精准探测保证探测出的热key是完全符合用户自己设定的阈值。
3、集群一致性
这个比较重要尤其是某些带删除key的场景要能做到删key时整个集群内的该key都会删掉以避免数据的错误。
4、高性能
这个是核心之一高性能带来的就是低成本做热key探测目的就是为了降低数据层的负载提升应用层的性能节省服务器资源。不然大家直接去整体扩充redis集群规模就好了。
理论上在不影响实时性的情况下要完成实时热key探测所消耗的机器资源越少那么经济价值就越大。
