得物热点探测技术架构设计与实践

说到热点问题，首先我们先理解一下什么是热点？,热点通常意义来说，是指在一段时间内，被广泛关注的物品或事件，例如微博热搜，热卖商品，热点新闻，明星直播等等，所以热点产生主要包含2个条件：1.有限时间， 2流量高聚。,,而在互联网领域，热点又主要分为2大类：,1. 有预期的热点：比如在电商活动当中推出的爆款联名限量款的商品，又或者是秒杀的会场活动等,2. 无预期的热点：比如受到了，网络爬虫频繁访问，又或者突发新闻带来的流量冲击等,针对于有预期的热点可以通过热点数据预热， 流量限制和异步队列进行处理。但是对于突发性无感知的热点数据流量，往往由于请求过于集中，导致访问数据流量超出的server的正常负载水位，从而出现服务过载不可用的情况，这种问题被称之为热点问题。,看完关于热点问题的简单介绍，我们已经理解了热点产生的条件是短时间内被频繁访问导致流量高聚，而流量高聚就会出现一系列的热点问题。那被频繁访问的Key，就是我们通常所说的热Key。,接下来我们来看一下哪些场景会导致热点问题以及对应的热Key：,了解完什么是热点问题和热Key出现的场景以后，我们会提出一个疑问，如何去提前感知这些热点数据？这里就需要聊到热点探测技术。,解决热点问题通常会使用分布式缓存，但是在读取时还是需要进行网络通讯，就会有额外的时间开销。那如果能对热点数据提前进行本地缓存，即本地预热，就能大幅提升机器读取数据的性能，减轻下层缓存集群的压力。,对于无预期的热数据（即突发场景下形成的热Key），可能会对业务系统带来极大的风险，可将风险分为两个层次：,正常情况下，Redis 缓存单机就可支持十万左右 QPS，并能通过集群部署提高整体负载能力。对于并发量一般的系统，用 Redis 做缓存就足够了。但是对于瞬时过高并发的请求，因为Redis单线程原因会导致正常请求排队，或者因为热点集中导致分片集群压力过载而瘫痪，从而击穿到DB引起服务器雪崩。,每个应用在单位时间所能接受和处理的请求量是有限的，如果受到恶意请求，让恶意用户独自占用了大量请求处理资源，就会导致其他人畜无害的正常用户的请求无法及时响应。,因此，需要一套动态热Key 检测机制，通过对需要检测的热Key规则进行配置，实时监听统计热Key数据，当无预期的热点数据出现时，第一时间发现他，并针对这些数据进行特殊处理。如本地缓存、拒绝恶意用户、接口限流 / 降级等。,首先我们要定义一下如何才能算是一个热点，我们知道热点产生的条件是2个：一个时间，一个流量。那么根据这个条件我们可以简单定义一个规则：比如 1 秒内访问 1000 次的数据算是热数据，当然这个数据需要根据具体的业务场景和过往数据进行具体评估。,对于单机应用，检测热数据很简单，直接在本地为每个Key创建一个滑动窗口计数器，统计单位时间内的访问总数（频率），并通过一个集合存放检测到的热 Key。,,而对于分布式应用，对热 Key 的访问是分散在不同的机器上的，无法在本地独立地进行计算，因此，需要一个独立的、集中的热 Key 计算单元。,我们可以简单理解为：分布式应用节点感知热点规则配置，将热点数据进行上报，工作节点进行热点数据统计，对于符合阈值的热点进行推送给客户端，应用收到热点信息进行本地缓存等策略这五个步骤：,1. 热点规则：配置热Key的上报规则，圈出需要重点监测的Key,2. 热点上报：应用服务将自己的热Key访问情况上报给集中计算单元,3. 热点统计：收集各应用实例上报的信息，使用滑动窗口算法计算Key的热度,4. 热点推送：当Key的热度达到设定值时，推送热Key信息至所有应用实例,5. 热点缓存：各应用实例收到热Key信息后，对Key值进行本地缓存（此步骤根据具体业务策略调整）,,理解完热点探测原理以后，我们来聊聊得物的热点探测中间件Burning。,作为潮流互联网电商平台，得物的电商业务高速发展，突发性的热点数据不断的冲击着我们的系统服务，比如大促秒杀，热点商品，等等。针对于这种突发性的大流量，单纯的机器扩容并不是一个有效的解决手段，我们需要一个集热点探测，热点感知，热点数据推送，热点数据预热，热点监控分析等功能于一体的热点探测中间件，因此Burning应运而生。,Burning作为得物的热点探测中间件，提供可供业务方接入的SDK包和管理台规则配置，用于对热点数据的实时性监控，探测，操作和本地缓存等。主要解决了以下问题：,为满足高并发场景，热点探测中间件Burning在设计的时候，重点关注了如下指标：,1.实时性：热点问题往往具备突发性，客户端必须能够实时发现可疑热Key并推送给计算单元进行探测,2.高性能：热点探测往往需要处理大量的热点探测请求和热点计算，因此热点探测中间件的性能要求较高，才能满足巨量的并发并有效降低成本,3.准确性：热点探测需要精准的探测符合规则热Key，实时监听规则的变化，正确的进行热Key上报和热Key计算,4.一致性：热点探测需要保证应用实例的本地缓存热Key一致，当热Key变更导致value失效时，应用需要同时进行失效来保证数据一致性，不能出现数据错误,5.可扩展：热点探测需要统计和计算的Key量级很大，而且存在突发流量的情况，统一计算集群需要具备水平扩展的能力,,Burning的架构设计遵循了以上热点探测的技术原理，同时借鉴了jd-hotKey的设计思路，主要分为Burning-Admin、Burning-Worker、Burning-Config、Burning-Client四个模块：,,热点探测主要包含以下几个主要流程：,,Burning提供了2种使用方式，一是通过原生方法调用，二是通过声明式注解@EnableBurning ， 以下对使用注解进行热点探测的部分场景提供最佳实践：,1. 进行热点判断，用于热点拦截和自定义处理实现,2. 命中热点规则处理类，可进行自定义实现hitHandler接口（注意cache=false）,3. 用于Redis缓存热点探测,4. 用于MySQL热数据缓存,,压测结果：1个4C8G工作节点每秒可平稳处理约15W个key的热点探测，成功率大于99.999%，worker节点CPU平均占用为80%，内存占用60%,Client配置为4C8G，120个并发请求，压测时长10min​,,压测结果：未接入burning，处理总请求数约112万，平均TPS约1500，平均RT约63MS。CPU在压测满载情况下100%，内存平均使用48%,,压测结果：接入burning后，处理总请求数457万（对比未接入Burning增加345万），平均TPS约5800（对比未接入Burning增加4300），平均RT约8MS（对比未接入Burning下降55MS）。CPU在压测满载情况下100%，内存平均使用50%（对比未接入上升2%，本地缓存消耗）,Client配置为4C8G，120个并发请求，压测时长10min,
,,压测结果：未接入burning，处理总请求数约298万，平均TPS约3800，平均RT约14MS。CPU在压测满载情况下100%，内存平均使用48%,,压测结果：已接入burning，处理总请求数约443万（对比未接入增加145万），平均TPS约5700（对比未接入上升1900），平均RT约8MS（对比未接入下降6ms）。CPU在压测满载情况下100%，内存平均使用48%，基本持平,热点问题在互联网场景中屡屡出现，特别是电商业务的需求场景，例如对于大促期间或者活动抢购期间的某个爆品，可能会出现在几秒时间内流入大量的流量，由于商品数据在Redis cluster场景下会按照hash规则被存放在某个Redis分片上，那么这个瞬间流量也有可能出现打挂Redis分片，导致系统雪崩。所以我们要善于利用热点探测中间件进行热Key探测，通过预置本地缓存解决突发流量导致的系统瓶颈，也能通过热点数据监控分析进行针对性的系统调优。,得物热点探测组件Burning上线至今，支持了数十个交易核心链路服务，在满足基础热点探测的前提下，Burning还支持本地缓存压测标/染色标识别能力，客户端本地Ecache/Caffeine缓存模式选择，热点规则Group聚合统计等扩展能力。应用服务接入Burning后对于热点数据探测及数据获取性能显著提高，通过预热&实时本地缓存，极大的降低了下层缓存集群和数据库的负载压力，为业务服务的健康运作保驾护航。​