共计 5726 个字符，预计需要花费 15 分钟才能阅读完成。
云妹导读：
在《会展云技术解读》专题中，咱们曾经推出了平安篇与设计篇，别离介绍了如何应答云上会展最严保障要求与线上展览中基于服务设计的办法，本篇文章云妹将持续为大家带来会展云中十分重要的一环——智能举荐零碎。
在现在的互联网产品中智能举荐堪称无处不在，它能够依据用户每个人的性别、年龄、喜好等维度塑造动态用户画像，和用户每一次点击、点赞、评论、珍藏等行为数据造成的动静用户画像相结合，来联合开掘用户深层次趣味需要维度。
咱们常见的有新闻举荐和电商场景的商品举荐，展会场景举荐零碎与之不同的是，它须要满足 参展商 、 采购商 和个人用户 各方需要，尤其是像前不久举办的永不闭幕的云上服贸会，首次采纳线上 + 线下联合的模式，将服贸会影响辐射周期从集中的一周拉长至一整年，参展商、采购商以及正在寻找商机有需要的个人用户都能够随时随地浏览云上服贸会寻找有价值的商机。
服贸会注册展商近万家，波及展品数量宏大，波及 200 多 个子行业。如何让线上用户从大量的展商信息中疾速找到本人想要的商机？如何放弃无效商机的继续获取？这些问题是晋升观展体验和逛展效率的要害口头。在这个过程中，京东智联云机器学习团队承当了 云上服贸会智能举荐性能的开发。
从上图能够看到，整个服贸会智能举荐零碎包含四个模块的性能，同时服务官网 2D 店铺和手机 APP 端，能够做到用户级别的个性化举荐。针对服贸会的 展商 、 展台 、 展品 、 我的项目 四项重要信息，智能举荐零碎有对应的 展商举荐 、 展台举荐 、 展品举荐 和我的项目公布举荐 四个模块。
其中，展商、展台和展品举荐三个模块的性能引入了采购商和集体的用户画像、趣味标签和行为等维度数据进行精准匹配。比拟难实现的是我的项目公布的举荐，因为除了要思考用户画像和趣味标签等维度数据外，思考到我的项目的及时性和强目的性，还须要高权重的引入内容维度的数据做举荐。
本次智能举荐性能落地过程中除了对于如何更精准的实现我的项目公布的举荐外，还有 3 大难题：
- 整个云上服贸，智能举荐出现的内容承载近 80% 的用户“第一眼”，所以如何在第一工夫给用户带来最佳的精准举荐是一个比拟辣手的问题。加上本次是第一届云上服贸会，没有历史信息能够应用。怎么做能力最大价值用户的第一工夫流量是整个我的项目期间继续思考的问题；
- 尽管整个云上服贸会注册参展商不如电商平台的量级大，然而在 9 月 5 日 - 9 月 9 日线下展会期间是同样须要面对高并发和性能的挑战，好的架构零碎设计是扛得住测验的松软防线；
- 解决了“第一眼”的举荐，如何做好第二眼、第三眼……的举荐，除了做好用户画像，在参展内容刻画的一直摸索。
同时，咱们也在一直思考：对于“永不落寞的服贸会”如何继续做好后续的举荐？不同于互联网产品新闻举荐和电商场景的商品举荐，展会场景的举荐如何做出满足各方（参展商、采购商和个人用户）需要的举荐之路？
目前市场上面向 C 端的用户产品如头条、淘宝和各家音乐 APP 等为了做好举荐过程的冷启动堪称各显神通——通过多路径尽可能地获取数据，比方首次注册的“关联微博 / 微信 /QQ”账户；比方询问用户的偏好和感兴趣内容；比方根底的用户信息收集（性别、年龄、地区和所属行业等）。无论通过被动的信息获取还是被动的用户动向抉择，都旨在补全对用户的认知，加上对散发内容精细化粒度的标签特征提取，能够实现冷启动的个性化举荐。
而冷启动举荐的另一个较高的门槛是：对用户场景和行为动机的深层了解，足够的知识库积淀。
但云上服贸会的智能举荐场景，以上两条路仿佛都不怎么好走。因为是首次参加展会类场景的举荐，即便看似举荐的产品和京东的商品类似，有展台和展品的划分，然而用户的群体画像和逛展用意有天壤之别。好在京东智联云长期以来始终赋能于 ToB 的业务，积淀了对 B 端企业洽购场景的认知。
尤其在 2020 年年初的疫情期间，为了给企业和政府提供高效的防疫配备采买，京东智联云推出了 “应急资源信息公布平台”。提供 洽购 和公布 供需信息的通道的同时，还为平台用户提供了基于 供需诉求 、 地理位置 、 产品匹配度与数量 、 生产力 和运输效率 等多维度的精准举荐。这些积淀的供需场景常识刚好能够利用于本次云上服贸会的举荐。另一方面，咱们对于用户画像和散发内容画像的了解和补全也做了很多功课，最终确保本次云上服贸会智能举荐的性能到胜利亮相。
面对高并发下的高性能要求，咱们设计了基于 Caffeine 和 Redis 的多重缓存架构，接下来将从两个方面来介绍：
1，技术选型
为什么应用 Caffeine+Redis？Redis 不必多说，大家都太相熟了。这里重点介绍下 Caffeine，Caffeine 是一个基于Java8 开发的提供了近乎最佳命中率的高性能缓存库。
这里有人又会产生疑难，为什么不必 Guava Cache 呢？这种大家更相熟基于 LRU（The Least Recently Used）算法实现的本地化缓存难道不好吗？
尽管 Guava Cache 在过来利用更宽泛，性能也还不错，但在突飞猛进的明天，总是会有更优良、性能更好的缓存框架呈现——就像 Caffeine。另外再补充下，从 Spring5（SpringBoot2）开始也应用 Caffeine 来取代 Guava Cache。
为什么 Caffeine 的性能更好？
首先从淘汰算法说起，Guava Cache 应用的是 LRU。LRU 实现比较简单，日常应用时也有着不错的命中率，它能够 无效的爱护热点数据，但对于偶发或周期性的拜访，会导致偶发数据被保留，而真正的热点数据被淘汰，大大降低缓存命中率。为此 Caffeine 应用了 Window TinyLFU 算法。
在讲 Window TinyLFU 前，还须要再简略介绍下 LFU。LFU 算法解决了 LRU 对于突发或周期性拜访导致实在热点数据淘汰的问题， 但短时间对于某些数据的高频拜访，会导致这些数据长时间驻留在内存中，进而在触发淘汰时，新退出的热点数据被谬误的淘汰掉，最终导致命中率的降落。另外 LFU 还须要保护拜访频次，每次拜访都须要更新，造成微小的资源开销。Window TinyLFU 实际上汲取了 LRU 和 LFU 的长处，又躲避了各自的毛病。
具体做法是：首先 Window TinyLFU 保护了一个近期拜访记录的频次信息，作为一个过滤器，当新记录来时，只有满足 TinyLFU 要求的记录才能够被插入缓存。为了解决资源的高耗费问题，它通过 4-bit CountMinSketch 实现，这个算法相似于布隆过滤器，能够用很小的空间来寄存大量的拜访频次数据。这个设计给予每个数据项积攒热度的机会，而不是立刻过滤掉。这防止了继续的未命中，特地是在忽然流量暴涨的的场景中，一些短暂的反复流量就不会被长期保留。为了刷新历史数据，一个工夫衰减过程被周期性或增量的执行，给所有计数器减半。
而对于长期保留的数据，W-TinyLFU 应用了 Segmented LRU（缩写 SLRU）策略。在初始阶段，一个数据项会被存储在 probationary segment 中，在后续被拜访时，它会被移到 protected segment 中。当 protected segment 内存不够时，有的数据会被淘汰回 probationary segment，这也可能再次触发 probationary segment 的淘汰。这套机制确保了拜访距离小的热点数据被保留，而反复拜访少的冷数据则被回收。
除此以外，在 caffeine 中读写都是通过异步操作，将事件提交至队列实现的，而队列的数据结构应用的是 RingBuffer（高性能无锁队列 Disruptor 用的就是 RingBuffer），所有的写操作共享同一个 RingBuffer；而读取时，这块的设计思维是相似于 Striped64，每一个读线程对应一个 RingBuffer，从而防止竞争。
上面是官网性能测试比照：
1、读（100%）
2、读（75%）/ 写（25%）
3、写（100%）
2，多级缓存设计
Redis 作为罕用的缓存，尽管性能十分优良，但随着数据量的增长，数据结构的简单，在叠加高并发场景时，不论是网络 IO 的耗费，还是 Redis 单节点的瓶颈，都会对整个调用链的性能造成不可漠视的影响。所以咱们既须要 Caffeine 作为 JVM 级别的缓存，也须要 Redis 作为咱们的二级缓存，这种多级的缓存设计能力最终满足咱们的须要。
在 Java 世界中，咱们最罕用的就是基于 Spring Cache 来实现利用缓存，但 Spring Cache 仅反对繁多缓存起源，并无奈满足多级缓存的场景。因而咱们须要 通过实现 CacheManager 接口来定义本人的多级缓存 CacheManager，同时还须要实现本人的 Cache 类（继承 AbstractValueAdaptingCache），在这外面将 CaffeineCache 和 RedisTemplate 类以及相干的一些策略配置注入进去，这样咱们就能够本人实现想要的 get、put 办法：多级缓存的读和写。
在数据一致性的设计上，这块次要依赖于 Redis 的公布订阅模式， 也就是将所有的更新、删除都通过该模式告诉其余节点去清理本地缓存，当然因为 CAP 的关系，这种设计是无奈保证数据的强一致性的，所以咱们也只能尽可能的去保证数据的最终一致性。
在会展云中，咱们采纳了 用户画像 、 信息画像 、 关键词匹配 等技术实现个性化举荐。其中，用户画像是通过用户的注册信息、趣味标签、浏览偏好等数据进行构建。信息画像包含了展商画像、展台画像、展品画像和我的项目画像四局部，前三局部各自构建又相互利用了对方的信息，如展商的珍藏、浏览等数据会增加该企业对应展台和展品的数据，展品的行业信息须要从展商画像中获取，三局部数据交融建模，从而构建了更加丰盛的画像。
关键词匹配技术次要利用于 行业名称和交易类型关键词的匹配，通过该技术能够将不规范的信息规范化。该零碎还针对冷启动场景进行了优化，当用户和信息数据有余时，零碎能够依据仅有的用户注册信息和参展商的行业信息进行匹配，并思考信息的热度进行排序。
本次服贸会实现了对数十万用户提供个性化举荐服务，针对新注册的用户和新公布的信息也能够通过冷启动计划疾速实现智能举荐。举荐零碎采纳了通用的 召回 和排序架构 ，召回局部将采纳 协同过滤 、 矩阵合成 等模型，能够疾速从海量数据中粗筛出候选集；排序局部采纳更简单且准确率较高的 深度学习 模型，如业界罕用的 Wide&Deep、DeepFM 等先进模型，实现对候选集每个信息的精准排序，为服贸会的用户和参展商提供精确和稳固的服务。
在模型抉择上，咱们应用 DIN（Deep Interest Network）模型。在正式介绍模型之前，先来介绍一下 Attention 机制。
Attention 机制是 模拟人类注意力而提出的一种解决问题的方法，简略地说就是从大量信息中疾速筛选出高价值信息，即一种将外部教训和内部感觉对齐从而减少局部区域的察看精密度的机制。
例如人的视觉在解决一张图片时，会通过疾速扫描全局图像，取得须要重点关注的指标区域，也就是注意力焦点。而后对这一区域投入更多的注意力资源，以取得更多所须要关注的指标的细节信息，并克制其它无用信息。图 1 中对 Attention 机制进行了图示，其中亮红色区域示意更关注的区域。
▲图 1 注意力机制直观展现图▲
Attention 机制的具体计算过程见图 2。对目前大多数 Attention 办法进行形象，能够将其演绎为两个过程、三个阶段：
第一个过程是依据 query 和 key 计算权重系数：
（1）第一个阶段依据 query 和 key 计算两者的相似性或者相关性；
（2）第二个阶段对第一阶段的原始分值进行归一化解决。
第二个过程依据权重系数对 value 进行加权求和：
▲图 2 三阶段计算 Attention 过程▲
利用候选参展商品和用户历史行为之间的相关性计算出一个权重，这个权重就代表了“注意力”的强弱。DIN 设计了部分激活单元，激活单元会计算候选参展商品与用户最近 N 个历史行为商品的相关性权重，而后将其作为加权系数对 N 个行为商品的 embedding 向量做 sum pooling。
用户的趣味由加权后的 embedding 来体现。权重是依据候选参展商品和历史行为独特决定的，同一候选商品对不同用户历史行为的影响是不同的，与候选商品相关性高的历史行为会取得更高的权重。能够看到，激活单元是一个多层网络，输出为用户画像 embedding 向量、信息画像 embedding 向量以及二者的叉乘。
DIN 模型大抵分为以下五个局部：
- Embedding Layer：原始数据是高维且稠密的 0 - 1 矩阵，emdedding 层用于将原始高维数据压缩成低维矩阵；
- Pooling Layer：因为不同的用户有不同个数的行为数据，导致 embedding 矩阵的向量大小不统一，而全连贯层只能解决固定维度的数据，因而利用 Pooling Layer 失去一个固定长度的向量；
- Concat Layer：通过 embedding layer 和 pooling layer 后，原始稠密特色被转换成多个固定长度的用户趣味的形象示意向量，而后利用 concat layer 聚合形象示意向量，输入该用户趣味的惟一形象示意向量；
- MLP：将 concat layer 输入的形象示意向量作为 MLP 的输出，主动学习数据之间的穿插特色；
- Loss：损失函数个别采纳 Logloss；
DIN 认为用户的趣味不是一个点，而是一个多峰的函数。一个峰就示意一个趣味，峰值的大小示意趣味强度。那么针对不同的候选参展商品，用户的趣味强度是不同的，也就是说随着候选商品的变动，用户的趣味强度一直在变动。
总的来说，DIN 通过 引入 attention 机制，针对不同的商品结构不同的用户形象示意，从而实现了在数据维度肯定的状况下，更精准地捕获用户以后的趣味。
以上，是咱们为本次服贸会智能举荐板块提供的技术支持和思考，本次服贸会作为首届 “永不闭幕” 服贸会，同样，咱们在技术之路的深耕和追赶的脚步一刻也不敢懈怠，一直思考继续摸索，不忘初心将来可期。
举荐浏览：
- 基于服务设计的线上展览 | 会展云技术解读
- 多重平安保障护航云上会展 | 会展云技术解读
- 让黑产无处遁形：京东智联云推出危险辨认服务
欢送点击【京东智联云】，理解京东会展云服务
更多精彩技术实际与独家干货解析
欢送关注【京东智联云开发者】公众号
