1. 体系介绍
阅读记载体系首要用来记载京东用户的实时阅读记载，并供给实时查询阅读数据的功用。在线用户拜访一次产品详情页，阅读记载体系就会记载用户的一条阅读数据，并针对该阅读数据进行产品维度去重等一系列处理并存储。然后用户能够经过我的京东或其他入口查询用户的实时阅读产品记载，实时功能够达到毫秒级。现在本体系能够为京东每个用户供给最近200条的阅读记载查询展现。
2. 体系规划与完成
2.1 体系整体架构规划
整个体系架构首要分为四个模块，包含阅读数据存储模块、阅读数据查询模块、阅读数据实时上报模块和阅读数据离线上报模块：
- 阅读数据存储模块：首要用来存储京东用户的阅读前史记载，现在京东有近5亿的活泼用户，按照每个用户保存最少200条的阅读前史记载，需求规划存储近千亿条的用户阅读前史数据；
- 阅读数据查询模块：首要为前台供给微服务接口，包含查询用户的阅读记载总数量，用户实时阅读记载列表和阅读记载的删去操作等功用；
- 阅读数据实时上报模块：首要处理京东一切在线用户的实时PV数据，并将该阅读数据存储到实时数据库；
- 阅读数据离线上报模块：首要用来处理京东一切用户的PV离线数据，将用户前史PV数据进行清洗，去重和过滤，最终将阅读数据推送到离线数据库中。
2.1.1 数据存储模块规划与完成
考虑到需求存储近千亿条的用户阅读记载，并且还要满意京东在线用户的毫秒级阅读记载实时存储和前台查询功用，咱们将阅读前史数据进行了冷热分离。Jimdb纯内存操作，存取速度快，所以咱们将用户的（T-4）阅读记载数据存储到Jimdb的内存中，能够满意京东在线活泼用户的实时存储和查询。而（T+4）以外的离线阅读数据则直接推送到Hbase中，存储到磁盘上，用来节省存储成本。假如有不活泼的用户查询到了冷数据，则将冷数据复制到Jimdb中，用来提高下一次的查询功能。
热数据采用了JIMDB的有序调集来存储用户的实时阅读记载,运用用户名做为有序调集的KEY，阅读产品SKU作为有序调集的元素，阅读产品的时刻戳作为元素的分数，然后针对该KEY设置过期时刻为4天。
这儿的热数据过期时刻为什么选择4天？
这是因为咱们的大数据渠道离线阅读数据都是T+1上报汇总的，等咱们开端处理用户的离线阅读数据的时分现已是第二天，在加上咱们自己的事务流程处理和数据清洗过滤进程，到最终推送到Hbase中，也需求履行消耗十几个小时。所以热数据的过期时刻最少需求设置2天，但是考虑到大数据使命履行失败和重试的进程，需求预留2天的使命重试和数据修复时刻，所以热数据过期时刻设置为4天。所以当用户4天内都没有阅读新产品时，用户检查的阅读记载则是直接从Hbase中查询展现。
冷数据则采用K-V格局存储用户阅读数据，运用用户名作为KEY，用户阅读产品和阅读时刻对应Json字符串做为Value进行存储，存储时需求保证用户的阅读顺序，避免进行二次排序。其中运用用户名做KEY时，因为大部分用户名都有相同的前缀，会呈现数据歪斜问题，所以咱们针对用户名进行了MD5处理，然后截取MD5后的中心四位作为KEY的前缀，然后处理了Hbase的数据歪斜问题。最终在针对KEY设置过期时刻为62天，完成离线数据的过期主动清理功用。
2.1.2 查询服务模块规划与完成
查询服务模块首要包含三个微服务接口，包含查询用户阅读记载总数量，查询用户阅读记载列表和删去用户阅读记载接口。
- 查询用户阅读记载总数量接口规划面临的问题
1.怎么处理限流防刷问题？
依据Guava的RateLimiter限流器和Caffeine本地缓存完成办法全局、调用方和用户名三个维度的限流。详细战略是当调用发第一次调用办法时，会生成对应维度的限流器，并将该限流器保存到Caffeine完成的本地缓存中，然后设置固定的过期时刻，当下一次调用该办法时，生成对应的限流key然后从本地缓存中获取对应的限流器，该限流器中保存着该调用方的调用次数信息，然后完成限流功用。
2.怎么查询用户阅读记载总数量？
首要查询用户阅读记载总数缓存，假如缓存命中，直接回来结果，假如缓存未命中则需求从Jimdb中查询用户的实时阅读记载列表，然后在批量补充产品信息，因为用户的阅读SKU列表可能较多，此处能够进行分批查询产品信息，分批数量能够动态调整，避免因为一次查询产品数量过多而影响查询功能。因为前台展现的阅读产品列表需求针对同一SPU产品进行去重，所以需求补充的产品信息字段包含产品名称、产品图片和产品SPUID等字段。针对SPUID字段去重后，在判别是否需求查询Hbase离线阅读数据，此处能够经过离线查询开关、用户清空标记和SPUID去重后的阅读记载数量来判别是否需求查询Hbase离线阅读记载。假如去重后的时分阅读记载数量现已满意体系设置的用户最大阅读记载数量，则不再查询离线记载。假如不满意则继续查询离线的阅读记载列表，并与用户的实时阅读记载列表进行兼并，并过滤掉重复的阅读SKU产品。获取到用户完整的阅读记载列表后，在过滤掉用户现已删去的阅读记载，然后count列表的长度，并与体系设置的用户最大阅读记载数量做比较取最小值，就是该用户的阅读记载总数量，获取到用户阅读记载总数量后能够依据缓存开关来判别是否需求异步写入用户总数量缓存。
3.查询用户阅读记载列表
查询用户阅读记载列表流程与查询用户阅读记载总数量流程根本一致。
2.1.2 阅读数据实时上报模块规划与完成
商详服务端将用户的实时阅读数据经过Kafka客户端上报到Kafka集群的音讯行列中，为了提高数据上报功能，用户阅读数据主题分成了50个分区，Kafka能够将用户的阅读音讯均匀的分散到50个分区行列中，然后大大提升了体系的吞吐才能。
阅读记载体系则经过Flink集群来消费Kafka行列中的用户阅读数据，然后将阅读数据实时存储到Jimdb内存中。Flink集群不仅完成了横向动态扩展，进一步提高Flink集群的吞吐才能，避免呈现音讯积压，还保证了用户的阅读音讯恰好消费一次，在异常发生时不会丢掉用户数据并能主动恢复。Flink集群存储完成运用Lua脚本兼并履行Jimdb的多个指令，包含插入sku、判别sku记载数量，删去sku和设置过期时刻等，将屡次网络IO操作优化为1次。
为什么选择Flink流式处理引擎和Kafka，而不是商详服务端直接将阅读数据写入到Jimdb内存中呢？
首要，京东商城做为一个7×24小时服务的电子商务网站，并且有着5亿+的活泼用户，每一秒中都会有用户在阅读产品详情页，就像是流水相同，连绵不断，十分符合分布式流式数据处理的场景。
而相对于其他流式处理框架，Flink依据分布式快照的方案在功用和功能方面都具有许多优点，包含：
- 低推迟：因为操作符状况的存储能够异步，所以进行快照的进程根本上不会堵塞音讯的处理，因而不会对音讯推迟发生负面影响。
- 高吞吐量：当操作符状况较少时，对吞吐量根本没有影响。当操作符状况较多时，相对于其他的容错机制，分布式快照的时刻间隔是用户自定义的，所以用户能够权衡过错恢复时刻和吞吐量要求来调整分布式快照的时刻间隔。
- 与事务逻辑的隔离：Flink的分布式快照机制与用户的事务逻辑是彻底隔离的，用户的事务逻辑不会依靠或是对分布式快照发生任何影响。
- 过错恢复价值：分布式快照的时刻间隔越短，过错恢复的时刻越少，与吞吐量负相关。
第二，京东每天都会有许多的秒杀活动，比如茅台抢购，预定用户可达上百万，在同一秒钟就会有上百万的用户改写商详页面，这样就会发生流量洪峰，假如悉数实时写入，会对咱们的实时存储形成很大的压力，并且影响前台查询接口的功能。所以咱们就利用Kafka来进行削峰处理，并且也对体系进行了解耦处理，使得商详体系能够不强制依靠阅读记载体系。
这儿为什么选择Kafka？
这儿就需求先了解Kakfa的特性。
- 高吞吐、低推迟：kakfa 最大的特色就是收发音讯十分快，kafka 每秒能够处理几十万条音讯，它的最低推迟只要几毫秒。
- 高伸缩性： 每个主题(topic) 包含多个分区(partition)，主题中的分区能够分布在不同的主机(broker)中。
- 耐久性、可靠性： Kafka能够允许数据的耐久化存储，音讯被耐久化到磁盘，并支撑数据备份避免数据丢掉，Kafka底层的数据存储是依据Zookeeper存储的，Zookeeper咱们知道它的数据能够耐久存储。
- 容错性： 允许集群中的节点失败，某个节点宕机，Kafka集群能够正常工作。
- 高并发： 支撑数千个客户端一起读写。
Kafka为什么这么快？
-
Kafka经过零复制原理来快速移动数据，避免了内核之间的切换。
-
Kafka能够将数据记载分批发送，从生产者到文件体系到消费者，能够端到端的检查这些批次的数据。
-
批处理的一起更有效的进行了数据压缩并减少I/O推迟。
-
Kafka采取顺序写入磁盘的方式，避免了随机磁盘寻址的糟蹋。
现在本体系现现已历屡次大促检测，且体系没有进行降级，用户的实时阅读音讯没有积压，根本完成了毫秒级的处理才能,办法功能TP999达到了11ms。
2.1.3 阅读数据离线上报模块规划与完成
离线数据上报处理流程如下：
-
商详前端经过子午线的API将用户的PV数据进行上报，子午线将用户的PV数据写入到数据集市的用户PV分区表中。
-
数据抽数使命每天清晨2点33分从阅读记载体系Mysql库的用户已删去阅读记载表抽数到数据集市，并将删去数据写入到用户删去阅读记载表。
-
离线数据核算使命每天上午11点开端履行，先从用户PV分区表中提取近60天、每人200条的去重数据，然后依据用户删去阅读记载表过滤删去数据，并核算出当天新增或许删去过的用户名，最终存储到离线数据分区表中。
-
离线数据出库使命每天清晨2点从离线数据分区表中将T+2的增量离线阅读数据经过数据清洗和格局转换，将T+2活泼用户的K-V格局离线阅读数据推送到Hbase集群。
作者：京东零售 曹志飞
来历：京东云开发者社区
