写点什么

中小企业如何做好推荐系统?

2018 年 6 月 14 日

有一个同学早段时间咨询我关于推荐的问题,我想了一下,本文仅从个人的角度来解答这个问题。

第一,推荐系统最初应该从人工运营的角度去思考,任何推荐都可以由人类来完成,只是人员成本大小的问题,机器只是在减少人力成本上起了很大作用。对于推荐,以人为本出发,如果是你作为一个秘书来服务一个客户,你会如何去处理?解答好这个问题,再将它交给机器。

第二,需要分清楚几个问题:采样策略、画像体系、推荐算法。而非盲目地尝试将海量特征强塞进一个模型中去。

采样策略在于确定线上真实数据和参与训练及测试的数据集之间的关系,即拿来研究和训练的样本是否能真实反应真实数据的分布。如果有时候离线 AUC 很高,但是上线后 A/B 测试没效果,那就表明两个数据分布不一致。如果说采样策略是骨,那画像体系即上面附着的肉,例如每个事物或人身上的标签,画像体系即用来描绘和区分事物与人的特征。最后一步才到推荐算法,它即轮廓来描绘群体间的边界,高级的模型用来拟合复杂的非线性边界,例如深度神经网络可以拟合几乎任何非线性函数,但这依赖于是否有清晰的画像去拟合。

第三,推荐系统的发展方向是降低熵,以降低不确定性作为下一步优化方向。捕捉越多的信息以降低对用户意图的不确定性,从而提升揣测其心理的准确性。比如对于一个新用户,没有其历史行为记录,那便需要利用他刚刚发生的实时动作和外部信息来降低熵,他点了一个视频但没有看完,他停留了 10 秒,这些信息收集难度会比离线统计有效点击的播放时长更难,但却是以降低熵为出发点的优化方向。

购物场景的模型迁移

当我们对一个新的场景比较陌生的时候,别忘了一个方法——迁移学习。把当前较为陌生的场景类比到自己熟悉的场景中去,增强在思索过程中大脑的联想召回能力,可以有效地提高头脑风暴的效率并降低思索过程中的熵(不确定性)。因此类比当前所在的公司面临的音频推荐场景,我们迁移到另外一个再熟悉不过的场景模型——购物场景。

首先得让自己站在商店老板的视角来看问题。

场景描述:“很多用户在外面走过,我要想方设法拉一个个用户来到了我的商店,可他们进来转一下,翻一些衣服和鞋子,然后好像什么也没买就走了,所以我们在想这是为什么?到底哪个环节出了问题?”

于是我们画了一张图:

确定主体——业务流程及主体关系

把上述一次可能发生的商业活动定义成上面的模型图,并确定了几大主体:用户(user),商家(server)、商品(item)。而商品上面隐藏的信息主体有主题(topic),以及商品背后的生产商(producer)。

清点货物——数据的人工标注

作为商家,必须在店里布置我的主题区,告诉用户“帽子在这”、“短裤在那”,绝对不能给用户乱糟糟的感觉。后续如有必要,我还要专门弄个区域来卖“阿尼玛”、“奥迪”这类牌子的货,因此在进货的时候就必需明确这些商品背后的生产商 producer 是谁,这些货有什么标识性强(使之与其他事物区分开)的特征。

首先,一个重要任务是在后台从 producer 进货的时候便对每个商品都进行人工再分类的主题 topic 标记(后期是可以使用算法的手段来减少该工作量的),我们需要把所有的帽子都标记为“帽子”、衣服标记为“衣服”,甚至做的更好一点给每个帽子标记细 label,如“大红色”、“呢子材料”,给每个衣服标记上时间特征“夏季”、“寒冬”,还要性别特征“男款”,还要场景特征“夜店”、“约会”等等一些更细的标签,当然对于一些曾经我没做好的标记,我必需挑选出那些还有利用价值的商品请人工再去鉴别并标记上,这是后来请专家帮我设计一套自动标记的算法来完成本工作的基础。

招募销售——开始人工运营

销售人员是必需的,初期经营的商品和用户体量比较小,使用我们聪明的头脑一眼就能看出趋势,再花几个小时做仔细的分析,一些问题的优化策略便可初见端倪。人工运营的工作很广,在推荐领域是维系供货商的关系以保持有货进、和维系用户的关系即向用户推荐自己觉得好的推荐清单。

初期人工运营的策略较简单,即拿到后台的报表然后挑选出 TopN 最热门的一些货物,经过分析发现了几个它们之所以受欢迎的原因,然后拿这些少数的原因去形成自己的筛选体系,并制定规则去筛选出一些优质热卖的商品推荐给用户,从而维系用户良好的体验,但是有个问题会发生在用户量增长后(卡住的 DAU),提及原因:人脑计算和记忆能力上限导致难以全局的处理用户的多样性。

另外还需要考虑商家侧长尾挖掘问题,即签约商家进行低成本供货。当然这是要付出一定代价的,比如一些商家恨不得整个店都摆满自己的东西增加曝光率,但是这个不可能,所以难点在如何平衡。除此外,有时候还不得不考虑多样性问题和那些小品牌的利益,一些小品牌购买率低,但是它可以保证平台多样性来面向不同需求的用户群体,并且增加平台的抗风险能力,下降或流失一个供货商也有候补集以不至于造成大的冲击。

所以,这是一个用户、大 V、小 IP 三角利益的动态权衡。因此数据的监控也该围绕这些对象来展开。

招募会计——建立数据采集体系

接下来要考虑请一些会计来这里帮我统计每天的销售报表。

盯梢用户——打点与上报

这中间我叮嘱会员管理人员一定要照顾和记录好那些老用户,哪怕是每次进来都主动搜索购买的那些顾客,做好他们的日常问候以及优惠促销提醒工作。另一方面我也叮嘱销售顾问们妥善记录下每一个较新或陌生用户到访的时间 visit time,和他们在每个 topic 区域停留的时间,以及他们试衣服的“标签款式 label”、“供应商 producer”、“主题 topic”,因此这是一次点击行为。然后是我最想看到的购买行为即他们最后付款了,这类似一次有效播放行为。

作为会计,他们关注的是微观量:单个用户停留时长(活跃度)、试了哪些衣服(点击行为)、买了哪些衣服(播放行为)。

作为老板,我关注的是宏观量:平均停留时长、平均点击率、平均播放率,以及我的宏观发展方向是否健康,即 DAU 是否增长、停留时长、回头率、有没有更多的潜在客源和收入。

现在开业了,用户来了,有的买了东西有的没买就走了,我也不知道是销售的策略不聪明还是我的商品不好,还是我的受众太窄,于是我们还需要请了一些专家帮我制定新策略。

招待新用户——用户冷启动

买来的先验知识——用户先验信息调查

来我店的用户可能是穷学生、富婆、牛奋、各种角色,所以我都不知道是从收入、还是职业、还是籍贯来分类了。于是我干脆设计了一张表,然后去找了一个信用中介买了些数据。

这些表里面很多信息是缺失的,不过这也是我作为用户进门的时候的一份依据。从信息熵(重要的概念)的角度来解决问题,只要提供越多的信息(前提是正确的信息),那么不确定的因素就越小、熵就越小,我也就可以得到一个更确定的置信区间,从而把用户的不确定性缩小。同样根据信息熵的理论,如果经过抽样验证发现中介提供的这些数据可靠性不强或者只有一半可以用,那直接不要了。

鼓励注册会员——收集用户信息和 ID

虽然已经有了上述的外部信息,但是当一个客户来我店时,需要做一个 identification 去核实他的身份才能调出他在我方买来的第三方信息库中的那一行信息。与此同时,我还尽可能的以注册会员卡有优惠为借口(因怕他反感)去登记他电话号码、微信、邮箱、生日等等一些 id 信息,以便我以后去其他第三方库中去关联他的其他信息。所以让用户赶紧在平台注册而不是一直当游客。

问卷调查——与用户的初次握手

勤快的销售总是有的,我专门告诉了店里所有的员工,用户来店一定要看面相和时机去问卷调查,比如问问他的兴趣、偏好、并登记他身上穿的款式等等,尽管这样有些用户是拒绝的并且会比较反感,所以这一步我通常都不是强制的,只是善意的询问而已,这一点是着重强调给员工的。在用户登录时,需要运营配合数据一起设计问卷调查表来获取冷启动需要的先验信息。

爆款和潮款迎新——人工运营的推荐套路

对于第一次或前两次来店的新用户,一定要叮嘱销售顾问们去推荐“爆款”(人气高、有效点击高)和“潮款”(时髦最近最新的,老一阵子的千万拿开),注意“和”字,是“与逻辑 &&”。据第一印象定理,我们一定要给用户留下一个最好的第一印象,这样他下次还可能会记得我这个位置。因此我宁愿牺牲部分兴趣相关性,也把对新用户的商品候选集都弄成店内最潮最爆的那些,然后拿用户的先验信息(如果有的话)去与这些 hot 候选集做交集并推荐。

但是这一套不会一直管用。

招待回头客——用户画像与行为分析

用户行为分析可谓是各大电商公司算法工程师们关注的大头了,将人工智能等手段应用到销售的场景无非就是这些地方。根据用户量的增长、以及所采用的算法先进程度,我们可以明确地看到一个依托用户行为分析数据的推荐引擎逐渐超越依托历史经验和常识的人工运营推荐团队的曲线。

这里的原理比较简单,就是做匹配,计算一个用户和一个商品的匹配度高不高,越高越先推荐给 TA(这里是对个人的,即每个人都不一样),从而增加 TA 购买的几率。优化的方向也比较清晰,特征工程与模型算法。

特征工程和用户画像

过了一段时间,我们通过店里的数据报表收集到了用户的购买行为,包括用户当时的状态以及它买的东西是什么样子、同时当时的场景如何,外面天气如何,也就是说我们完全是可以人工来做好推荐的,只要要求运营人员按照我的要求去对每个用户都做这种分析就能达到完美的效果。

用户画像的解释非常的通俗,即用户当时是个什么状态,例如她在买那个包的时候“最近赚了钱,女性,近一个月有买类似的包,喜欢在晚上过来闲逛,历史上喜欢蓝色等等”,同样还有商品画像“LV,蓝绿色,马云同款,鳄鱼皮等”、场景画像“雨夜,国庆放假前等”,这些画像包括历史的、最近的、实时的,凡是用来表示当时这个事物状态的特征组。

类似的,通过对用户商品场景画像和购买记录回放,我们会总结出来类似“7、8 月份的下雨天晚上,喜欢穿裙子扎马尾的中年女性,一般倾向于走到亲子专区重点关注甚至购买黄颜色的带连体帽的童装”这样的规律。

是的,然后你要花很多时间去总结出几百几千条类似的规律,然后让销售人员去背。

这里的一个关键就是如果我总结的规律是“晚上中年女性喜欢购买童装”,然后拿去培训销售人员会得到什么样的结果?

答案不言而喻,肯定会出现一些 bad case 错误推荐,而造成这个的原因就是销售人员观测的时候偷懒,在特征工程上对用户和商品的描述粒度太粗,即采用了没有区分度的特征使得这种特征组合会出现截然相反的两种购买行为,从而误导分析人员。

怎么发现这种问题呢?以后在讨论关于评估的离线指标和在线实测时再详谈。另外一个错误就是,数据人员偷懒,只随机抽取了数据报表的 1/10 提交给我分析,从而漏掉了一些本来很有价值的关键信息,并留下了一些冗余的信息,从而同样导致我总结出来一条错误的结论,这就不能怪我傻了。

模型算法和用户行为分析

面对庞大的特征体系,没办法总结出特征与特征之间的交织关系和规律,因此我们直接观测用户共性,采用类似协同过滤的手段来总结,即用户 A 跟 B 买的东西交集比较大,然后我们建议推荐他们两个相互没有买过的东西,从而单纯从行为来完成了这件事,这是一种简单的方式。

或者面对庞大的特征我干脆采用聚类的手段然后划线来分群体,这是另一种简单的方式。不过数据公司貌似都提供了一个策略:对每个用户画像进行聚类,形成几个簇,然后新来一个用户对它进行类似 KNN 归类,然后把那类人的东西推给他,这个方法是常规的无监督的聚类手段。关于最热门手段会在之后的文章中提出来,并附上实现步骤。

最后,我们总结出来的这个策略是要反馈并培训给销售的,但是有时候销售也很笨,比如抓不住实时的信息,反应慢半拍,重复描述。这个就是服务端的问题了,比如无法提供实时信息反馈啊、延迟和性能高,使得我方的策略效果被迫降级。

不同等级的雇员与能力要求——模型复杂度与学习周期 & 特征工程与特征实时性

同样在主动推荐系统(猜你喜欢这种类似的功能)的场景中,也是需要实时地传递用户刚刚的状态,这是基于“more information less entropy”的理论来的,所以推荐系统要求特征的时效性非常强,就好比一个敏锐的推销员会观察用户的一举一动并随机应变。

之前所提的两条线是值得非常重视的,其一是他们对特征的发现和观察能力,能敏锐地识别出到底是哪个特征有区分性或比较有辨识度——特征工程方向;其二是他们的抽象和分析能力,能通过缜密的思考和分析提出自己的一套方法论从而综合利用这些特征——数学建模方向。

上面两条路线是并行的,即模型是一个销售的逻辑思维能力或深度思考能力 processor(一个可以综合分析不同事物关联性的抽象能力),特征是他的观察力或外界感知能力 sensor(一种能快速获取有“价值”信息的天赋能力)。一个好的销售必须要有这两种素质。

  • 见习:无逻辑无观察,对男女老少只知道推荐爆款潮款——“潮款爆款”的热度推荐引擎。别小看这种引擎,当你们公司什么都没有的时候,就直接用数据库或者 excel 统计一下潮款爆款吧,绝对比随便任意地展示给客户好。热度引擎,这是我的第一个 baseline,而且请这样的顾问也挺便宜。
  • 初级:初级逻辑和延迟的观察,知道简单地分析商品之间的相关性,知道推荐同款,但不关注用户实时的动作。——离线学习、离线推荐。
  • 中级:高级逻辑和敏锐观察力,可以在接待用户前掌握其历史习惯,同时观察用户当前的关注点——离线学习、实时推荐。
  • 高级:高级逻辑和及其敏锐的观察力,在中级顾问的基础上提供贴身咨询服务,从客户到店的那一刻起,就实时捕捉下用户的每个动作,考虑每一步实时动作对决策的影响——离线学习、实时记忆、实时推荐
  • 资深:在高级顾问的基础上,另外拥有非凡的学习能力,能现学现卖地总结用户刚刚的购买行为,并马上应用到对下一个用户的服务策略中去——在线学习、实时记忆、实时推荐。

逆向推测——反向标注

对于 UGC 平台而言,内容或商品的产量是极大的,所以之前提到的利用人工来“清理货物”标注只能应付一小部分,除了给这些“供应商”制定一个标注规则外,我们也可以设计一些文本算法来从文本来提取标签,更深一点就是采用深度学习手段从内容或商品本身去挖掘出隐含标签。

不过有一种比较简便的方法,如果当关注和购买某个商品的用户达到一定数目,则可以将用户画像反向传递到商品身上,从而推测出商品所具备的属性。例如,一百个用户都购买了某款衣服,然后我发现这一百个用户里面 80 个带有“亲子”的标签,我反向推测这款衣服具备“亲子”属性,从而完成标注。

强烈购买欲与随便看看

主动与被动——搜索 =NLP+ 推荐

通过我的观察,我发现用户基本上是分为两类:一类是目标性明确的用户直接进来就开始主动搜索;一类是目标不明确的漫游浏览型用户,挑挑选选爱买不爱。对于这两类用户我方能做的反应其实只有一种,第一个是检索、第二个推荐。

检索是精确是识别客户发出的询问 query,并精确地猜测出他想寻找的内容:“你们这有没有那种,晚上情趣的… 那个?”“您要的是情趣内衣吗?”“是”。这便是检索系统的最高境界,即自然语言处理的智能问答型检索机器人(而不单是 tf-idf 或者基于历史特征的召回排序引擎)。可以看到的是,其实它除了文本预处理这部分将符号转换成特征值,剩余的部分是一个推荐引擎。

推荐则是更加泛化的一个说法,它应该被描述为一个智能体 agent,可以结合用户的历史以及当前的特征实时给一个召回和排序的反应。

不管是搜索引擎还是推荐引擎,它的终极目标其实是一个智能问答型机器人,它的贝叶斯误差上限即是人类专业销售顾问的表现(也就是它的终极追求便是成为一个对某个用户专属的小秘书)。

答疑与推荐——搜索纠错 & 搜索推荐

用户到店里未免不知道有什么,可能会询问一些比较抽象的词汇“jay”,这时候销售就应该做两件事,第一是理解其表达意思——自然语言处理,比如提示您要找的“jay”是不是“周杰伦”?第二是做召回排序——推荐系统在搜索中的应用。召回无非两种,与主题强相关的先推荐,“周杰伦同款”、“周杰伦 CD”等等,与主题联想相关的穿插推荐,比如“本草纲目”、“昆凌”等等。至于到底按什么顺序呈现给用户,需要结合可以降低条件熵的上下文,这里即客户的场景特征。

贴身服务——特征的实时跟踪

要明确任何“正确”信息都是有价值和有用的,更多的信息则可以更多地降低意图的熵,更多地降低预测的不确定性,从而在用户第一次搜索“周杰伦”紧接着搜索“本草纲目”,然后立刻又搜“周杰伦”的推荐结果不一样。

搜索与推荐的未来——交互式推荐

未来的搜索和推荐进化方向应该会向交互式搜索与推荐系统发展,理由是“降低信息熵”才可以获取更多的准确性。在推荐场景只要能捕捉到用户暗示的蛛丝马迹,就可以降低我们对用户意图的不确定性,从这个角度出发,各大公司无非在这个领域就是去花更多成本去降低这个熵。

然而,我们之前的目光都停留在被动观察者的角度,如果更进一步就该变被动于主动,发展交互式体系,在适当时机主动的向用户询问并通过确认来降低熵。简而言之就是变被动为主动,推荐系统不再是一个默默的大白,而是一个察言观色的伴侣,语音交互在智能家居中是一个鲜明的应用和趋势。

卡住的 DAU(Day Active User)——新产品开发

信息熵——优化思路

信息熵用来量化信息,表征人们对信息的不确定性。那么这么个看似八竿子打不着北的概念怎么就跟我们扯上关系了?

我们战术级优化策略是时刻要以降低信息熵为导向的。

先确定一个最直接的目标函数,例如用户启动搜索引擎的直接目标是为了搜索到想要的内容(换个说法我们给它推荐它想要的内容),而这个过程中他其实一直在提供着隐含信息,在哪个页面停留比较久、哪个内容点进去却又退出来、点了哪个推荐项又进行了跳转,我敢说这些信息是完全可以用来降低信息熵的但基本上没有被利用(当然了,采集难度略大),先人工检查一下业务流程中的每一步操作细节,看看有没有哪一步对最终的目标函数提供了有用信息,因为 AI 是在模拟人的脑力劳动,只是将其复制出来几万个思考更快一些的实例罢了,所以,绝知此事要躬行。

战略高于战术——扩大潜在目标群体

因为在做服装生意一段时间后,我们发现了业务间的关联,那就是用户在购买服装的时候会考虑买包和伞,这便是我通过发掘后期所获取到的信息,我将进货一批相关的新产品,从而开发用户潜在的付费能力。

另外,基于我们的业务基础打算提供订制西服的新业务,这直接使得那些曾经不在目标群体的新用户变成了潜在的用户。

有时候 DAU 上不去除了查看战术,还有看是不是接近了贝叶斯误差(天花板),从 1 到 N 的战术更新是很烧脑烧钱的,从 0 到 1 的战略尝试是高风险的。但是我更看重战略,它的投资回报更高,而且它不像大多数都可以拿钱缩小的战术差距。当我小店生意平平的时候, 我就要考虑重新装潢和变化服务了。

内部的冲突与矛盾——人工运营和 AI 的分工

随着用户的增长,一场必然的冲突最终还是发生了,即运营组跟挖掘组的矛盾。当然,一种无可逆转的趋势不得不说,以后的推荐策略几乎不需要人工参与运营,这个工作被人工智能来替代更为恰当。

从客观的角度来解释一下为什么。

人和机器的天赋优势比,人擅长深度综合思考、情感处理、艺术创造,而机器擅长高速运算、持久记忆、并行化,所以论对一个 VIP 用户来说,人的优势不言而喻,但面对 100 个、1000 个、10000 个 VIP 用户,你难道会花钱去请 100 个私人秘书?还是一个人工智能搞定一切?

这就是 CPU 与 GPU 的差别,为什么说人工运营推荐也可以做得很好,因为它有一个前提,那就是人力做到千人千面、用户数据分析,这个你用 100 个 CPU 是可以顶一个 GPU 的,只要老板肯出这个钱。

但是,随着人工智能的发展,计算机再综合思考和分析能力上越来越接近人,至少在推荐场景是这样,所以叠加上机器的其他天赋,它的综合表现水平肯定会高于人类。

销售会非常相信自己对一个用户和一个商品的判断,从而推理“其他人也会有同样的看法”,这种情况只会发生在与他具备相同特征的群体中,而这种直觉在 90% 他所未知的群体中表现却很差。

基于统计与数学的机器推荐面对千人千面的情况下会表现得更好,他是基于缜密科学依据发展而来的仿人类智能系统,相当于模拟了很多个个性化的私人推荐小秘书(当然这是当数据和策略都比较完美的情况下)。

不过遵循天赋强项的来看,人工在推荐当中扮演的角色更多会倾向于“标签标注”,“商品质量”,“寻找 bad case(整理样本)”这样的角色。另外发挥人的情感处理优势和深度的综合理解优势,机器目前还识别不出内容本身蕴含的情感因素和隐层话题,机器也无法与签约主播有效的沟通来维系主播的关系,所以把有曝光需求的商品 / 主播抛过来,机器来设置优先的策略,而不要人工干预过多推荐策略。

结束语

如果需要上线第一版推荐系统,那可以先用热度、新鲜度加权排名推荐先应付。然后使用开源的协同过滤以及 word2vec 做第二版基于用户行为分析的推荐,排序可以考虑用 GBDT_LR 的方式完成。最后走用神经网络的路线,DNN 和 WDL 目前是很时髦的方向。

关于细节在下一次文章中聊聊。

作者简介

庄正中,布里斯托大学硕士,现为荔枝 APP 的数据挖掘工程师 &AI 工程师。主要从事神经网络算法的研究和应用,大数据领域的开发工作。

感谢蔡芳芳对本文的审校。

2018 年 6 月 14 日 17:521794

评论

发布
暂无评论
发现更多内容

一点 Go Web 编程实践经验

Garfield

go Go web

业务架构学习内容有哪些?

周金根

BIZBOK 业务架构

LeetCode 169. Majority Element

liu_liu

算法 LeetCo

Go: 理解 Sync.Pool 的设计

陈思敏捷

go golang sync sync.pool pool

阿里培训官给新入职程序员的25条建议

Java架构师迁哥

区块链技术发展的十大趋势

CECBC区块链专委会

区块链 金融 安全问题

TOGAF认证课由2天变化为5天的思考

周金根

企业架构 TOGAF

为什么每个微服务要有自己独立的数据库?

码猿外

数据库 架构 微服务

面试必问亿级流量优化策略之JVM调优,文档视频面试,还不收藏

小Q

Java 程序员 架构 JVM jvm调优

藏在Java数组的背后,你可能忽略的知识点

Java架构师迁哥

架构师课作业 - 第十三周

Tulane

不草率,你只管下载资料,剩下的交给「哇哦」

小Q

Java 学习 架构 面试 分布式

我理解的面向对象(ObjectiveSql 实践)

Braisdom

Java ORM框架 ORM

Golang领域模型-实体

奔奔奔跑

go 架构 领域驱动设计 DDD 微服务拆分

企业中台化落地:从战略分析到战术实践及架构演进过程

Barry的异想世界

架构设计 策略模式 模板方法模式 中台架构 领域驱动设计DDD

SpringCloud轻松集成Dubbo实现RPC调用

Barry的异想世界

微服务 dubbo nacos RPC spring cloud alibaba

区块链赋能市场监管 浙江上线“黑科技”清除取证固证难题

CECBC区块链专委会

区块链 市场监管 取证难题

央行数研所推出贸易金融区块链平台

CECBC区块链专委会

区块链 金融

从新浪数字化转型,窥见互联网的“懂行”新十年

脑极体

基于Goc的Golang代码VSCode实时染色方案

大卡尔

go 测试覆盖率 精准测试

宅家三个月玩转算法,再战字节跳动,字节跳动面试官朝我比了个“ok”

云流

编程 字节跳动 算法 Java 面试

Dubbo-go应用维度注册模型

apache/dubbo-go

dubbo dubbo-go dubbogo

Java四种引用类型:强引用、软引用、弱引用、虚引用

简爱W

金沙账号审核不通过维护不给提现风控怎么回事?怎么办

过山太阳

内容审核 提现不了

【高并发】Redis如何助力高并发秒杀系统,看完这篇我彻底懂了!!

冰河

redis 多线程 高并发 秒杀 电商超卖

week11--作业

Geek_165f3d

我们该怎么保护手机屏幕前的父母?

徐说科技

手机 短视频

服了,十年运维架构专家的MySQL运维经验,除了实战还是实战

周老师

Java 编程 程序员 架构 面试

一文解开java中字符串编码的小秘密

程序那些事

java安全编码 java编码指南 UTF编码

oeasy教您玩转 linux 010212 管道 pipe

o

HashMap将cpu打满始末

林昱榕

hashmap 线程安全 cpu 100% cpu飙满

微服务架构下如何保证事务的一致性

微服务架构下如何保证事务的一致性

中小企业如何做好推荐系统?-InfoQ