解读 | 滴滴主题研究计划：机器学习专题+

最新推荐文章于 2022-05-17 13:37:41 发布

stay_foolish12

最新推荐文章于 2022-05-17 13:37:41 发布

阅读量1.7k

点赞数

分类专栏：机器学习文章标签：机器学习滴滴

机器学习专栏收录该内容

74 篇文章 13 订阅

订阅专栏

解读 | 滴滴主题研究计划：机器学习专题（上篇）

2018年7月31日管理员

滴滴主题研究计划

滴滴希望通过开放业务场景，与学术界发现与定义问题，合作共赢解决领域难题，构建高水平跨境知识与研究网络，构筑产学研合作共同体。

2018年秋季期主题研究计划包含机器学习、计算机视觉、语音信号处理、地理信息技术和能源与汽车五大研究方向的15个来自滴滴真实业务场景。诚邀全球顶尖的学者与滴滴研究员共同探讨前沿技术在出行领域的落地应用，以真实场景驱动技术革新。

2018年秋季期提交申报书截止日期8月19日。请您关注项目关键时间节点，选定申报命题后提前完成申报工作。

主题研究计划官方网址：

https://outreach.didichuxing.com/RFP

本期我们将介绍机器学习方向课题，希望大家可以找到与自己研究方向匹配的申报方向。

机器学习

一. 供需预测

1.技术方向

时空数据人群转移分析城市出行

2.课题背景

出行领域的核心在于连接司机和乘客。如何有效利用这些信息通过大数据和机器学习的技术方案，对供给和需求进行描述和建模，实现高频出行下的供需平衡，是提升整个平台效率和服务的关键。通过建立一个统一的供需实时预测系统，通过基础能力的建设和打磨，能赋能订单分配、司机调度、导流、定价、产品策略等业务场景，提升整个出行平台的效率。

3.研究目标

针对上述关键问题，研究目标包括不限于：

1. 时空数据预测

构建出行场景下时空数据预测能力，其中涉及数据集组织、特征工程、模型训练和验证。对于时空数据的分析和研究一直是业界热议的方向之一，而时空数据预测也一直是业界的一大难题，我们拟建立科学的评估体系，对输出的预测能力提出以下要求：提供实时预测能力，达到数据可用性，适配节假日、极端天气、突发事件等异常情况。

2. 人群转移分析

出行场景的根本是人群的转移，只有深入挖掘人群属性及行为特征，才能对城市出行规律做出更加科学的解读。

二．拼车算法研究

1.技术方向

研究拼车合乘算法，提升拼车系统的效率

2.课题背景

网约车的快速发展和普及，极大地提升了出行服务的体验和效率。同时，车辆共享使得交通拥堵得到缓解，基于大数据的供需匹配与优化技术也助力于智慧城市的建设。其中拼车通过行程共享，致力于进一步提升车辆利用效率，以提供低价、高效、绿色的出行服务产品。

在更少的体验损失下，将更多的订单组合在一起，也将极大提升拼车效率。拼车效率的实现依赖于定价能力, 需求结构及分单能力, 且各部分作用相互耦合。定价模型灵活支持不同业务目标下的基础定价及补贴发放策略。出行需求结构在不同城市差异巨大: 在相似体验约束下，达到同等效率所需的订单数量在不同时空域上迥异。给定供需集合，分单模块负责将需求与需求，供给与需求进行实时匹配，并通过匹配算法及时序决策的优化提升拼车效率。

三个部分的综合影响最终决定了拼车效率的实现，而各独立部分影响面的量化及相互作用关系的描述，对整体策略能力进化必不可少。

针对上述关键问题，研究目标包括不限于：

1. 拼车分单时序决策优化

实时拼车业务的一个主要特征是分单系统对出行需求的即时响应，意味着匹配决策需要在极短的时间内完成。对某一订单来说，在其生命周期中往往能参与多个订单组合，且该订单组合的集合随时间变化并决定了此订单匹配效率的优化空间。因此，匹配决策需在当前轮次的优化力度及未来需求的随机性之间做权衡。即不仅提升每一轮次的匹配效率，同时需考虑订单在时序上所能参加的匹配轮次组合并决策最佳分配点。

2. 需求结构与分单耦合关系建模

分单框架中的各要素如基础匹配算法，时序决策优化，体验参数控制等，在不同的需求结构下，对于拼车效率的影响也相应变化。因此，在不同的需求结构下，需灵活地根据相适应关系调整分单框架，从而使各要素的组合能更好地实现拼车效率。

3. 需求结构建模

在同一城市中需求结构是异质化的，而基于业务目标，去有向地调整需求结构十分重要。为不同时空域内的需求建立属性，可增强对输入订单集合的把控能力。如动态泛线路的挖掘，及线路间影响关系的建模等。

4. 绕路识别

拼车绕路的实时识别，包括拼车子单内送驾绕路，拼友接驾绕路，全拼单整体绕路，相邻单绕路等的识别。一般来说，这个过程涉及异常问题定义，用户反馈收集和清洗，特征数据集构建，模型训练和验证。其中，问题的拆解和建模是最困难的。拼车绕路场景有着丰富的内涵，完成机器学习建模应该满足以下三个要求：

1）内聚性

每个子问题场景都有一个清晰的定义，任何两个子场景之间的边界尽可能清晰。每个子场景的拆分定义具有较强的内聚性。

2）全局性

各子问题场景间的相关性及子场景与总场景的关系，对问题的发现和早期问题的及时解决有较强的影响，需要统筹考虑。

3）模型指标

模型需要通盘考虑准确率、召回率对成本和用户体验的平衡，同时兼顾模型判责的可解释性。

5. 成单调度

根据订单时间、费用、里程、路况、空余座位、司机属性、乘客属性等特征，结合成本收益体验等建设基于深度学习、强化学习的拼单调度策略，从而提升资源利用率和司乘体验。

1) 多目标优化

充分考虑司机、乘客利益和约束，实现司乘体验的优化，体验和效率、平台长期增长的均衡。

2) 模型指标

在充分理解业务和数据的基础上，分场景建设通用的灵活可配置的调度模型。实现拼成率、顺路率等核心业务指标的明显提升。

三 . 派单算法研究

1.技术方向

组合优化、强化学习、多目标优化、在线系统

2.课题背景

网约车服务在近年来得到了广泛的普及和长足的发展。与传统的巡游出租车相比，网约车的优势之一在于其存在中心化的决策机制，可按需在线地撮合乘客和司机间的匹配，从而达到提升平台效率和司乘体验的效果。订单分配（或派单）算法作为连接司机和乘客的桥梁，是网约车平台中最核心的问题之一。

在实际应用中，一个可用的订单分配算法需要满足几下几个要求：

1. 实时计算、运行效率高

以滴滴平台为例，每天平台日订单3000万，这对算法的实时性和复杂度有了很高的要求；

2. 平衡效率、体验等多个目标

在订单分配算法中，平台不仅要考虑整体的匹配效率，还需要满足司乘体验的要求、公平性、可解释性以及平台长期增长的诉求。如何将这些目标有机地结合在一起是一大难题。

从上述分析可知，派单任务无法简单地由人工配置进行，其对机器算法有着很强的依赖。从另一个角度来说，派单算法也是人工智能、机器学习、运筹优化等研究领域很好的实验土壤。综上，派单问题可以作为学术和工业界结合的重要应用之一。

3.研究目标

针对上述关键问题，研究目标包括不限于：

1. 匹配算法框架

在订单分配问题中，一个重要的特性是其存在网络效应和时序效应。具体来说，网约车为一个司乘的双边市场，司乘间的匹配皆不是互相独立的，其在时间和空间上组成了一个网络状的结构。同时，派单中需要考虑平台效率、司乘体验、公平性等多种因素，形成了多目标优化的问题。因此，设计一个可满足以上条件的匹配框架，平衡优化目标和约束，并综合时间序列和空间匹配要求，非常有研究价值。

2. 个性化派单

根据用户实时状态以及用户特性的不同，进行个性化的分单，以提升司乘和效率。

3. 派单公平性和可解释性

滴滴的线上分单系统每天为大量的司机和乘客服务，其服务对象均为有感情有诉求的个体，故算法的可解释性和公平性往往与平台效率、体验处于同样重要的作用。如何把公平性引入优化目标或约束中，并生成可解释可回溯的匹配标准，也是算法必须要考虑的问题。

注意

更多项目信息

请关注主题研究计划官方主页：

https://outreach.didichuxing.com/RFP

本文来自滴滴学术合作微信号。

云服务器 DC2

可随时自助获取、可弹性伸缩的云服务器，帮助用户打造安全、可靠、灵活、高效的应用环境，满足持久稳定运行的需求，提升运维效率。

立即体验

标签

解读 | 滴滴主题研究计划：机器学习专题（下篇）

2018年8月8日管理员

滴滴主题研究计划

滴滴希望通过开放业务场景，与学术界发现与定义问题，合作共赢解决领域难题，构建高水平跨境知识与研究网络，构筑产学研合作共同体。

2018年秋季期提交申报书截止日期8月19日。请您关注项目关键时间节点，选定申报命题后提前完成申报工作。

主题研究计划官方网址：

https://outreach.didichuxing.com/RFP

上期我们介绍了机器学习方向的前三个课题，大家可以在文末点击查看。这期我们将介绍该方向的另外三个课题，希望大家可以找到与自己研究方向匹配的申报课题。

机器学习

四. 网约车评价体系设计

1.技术方向

深度学习，机器学习，半监督学习，Active Learning，标注方法，Transportation，用户体验

2.课题背景

随着移动互联网颠覆性的变革，网约车行业在全球兴起。滴滴作为全球领先的网约车以及智慧交通平台，已经在深刻改变着人们的出行乃至生活方式。

让好服务的司机能获得好的收入，为网约车设计一套评价体系，兼顾乘客体验，司机接单公平性与平台的合理收益，也成为司乘生态建设的一大关键。滴滴目前的评价体系构建依赖的机器学习建模实现的。司乘反馈的准确数据标注和模型的持续优化也将可以让网约车评价体系设计的更完善，从而使司机和乘客的用户体验进一步提升。

3.研究目标

针对上述关键问题，研究目标包括不限于：

1. 标注方法研究

构建自动或半自动的样本标注能力，为模型训练提供足够多的样本。一般来说，这个过程需要结合人工标注样本，涉及半监督学习、Active Learning等方面的知识。将自动标注的样本达到人工标注的质量是最困难的。需要满足以下两个要求:

1) 准确性

每个样本都要得到准确的评价结果，达到或近似达到人工标注的质量。

2)自动或半自动

样本的生产是自动或半自动的，可以支撑DNN这种大规模训练数据要求。

2. 模型算法研究

探索合适的机器学习、深度学习、增强学习等方法，持续提高模型效果。详细来说，评估的指标和方面包括：

1）AUC

2）准确率

3）召回率

4）工程架构

五．基于网约车取消场景下的判责方法研究

1.技术方向

深度学习，机器学习，半监督学习，Active Learning，标注方法，Transportation，用户体验

2.课题背景

随着移动互联网颠覆性的变革，网约车行业在全球兴起。滴滴作为全球领先的网约车以及智慧交通平台，已经在深刻改变着人们的出行乃至生活方式。良好的司乘生态非常重要，以一个普通的约车场景为例，当乘客输入自己的起终点并点击“叫车”时，平台会实时匹配合适的司机，而在匹配完成后和开始计费前，司机或乘客可以随时取消这笔订单，但可能会面临一定的责任判定，因为一方的取消往往会影响另一方的体验。

滴滴的取消判责当前是用机器学习建模方式实现的能在司乘任意一方取消订单时，实时、自动判定司乘双方的取消责任，即时给予反馈，有效保障司乘双方权益。司乘反馈样本的准确标注和机器学习模型算法的提升都可以让取消行为的责任判定更准确，从而使司机和乘客的用户体验进一步提升。

3.研究目标

针对上述关键问题，研究目标包括不限于：

1. 标注方法研究

1)准确性

每个样本都要得到准确的判责结果，达到或近似达到人工标注的质量。

2) 自动或半自动

样本的生产是自动或半自动的，可以支撑DNN这种大规模训练数据要求。

2. 模型算法研究

探索合适的机器学习、深度学习、增强学习等方法，持续提高模型判责效果。详细来说，评估的指标和方面包括：

1) AUC

2) 准确率

3) 召回率

4) 工程架构

六．乘客个性化出行需求预测模型研究

1.技术方向

用户画像，机器学习，深度学习，个体出行需求预测

2.课题背景

滴滴致力于满足用户的出行需求，目前用户出行需求表达一般在打开滴滴出行之后，此时用户的需求决策（从A至B，打车出行）已基本确定，出行服务目标主要为对需求表达后的高效满足。

对用户未来短期的个性化的需求预测研究，对于后续通过运营手段引导和促进用户共享出行，具有重要意义。例如，通过算法准确预测个体用户未来24小时从A到B的概率，则可以结合行程特点（典型的，出行概率高还是低，出行目的地是商场还是饭店），提前对用户进行个性化运营和推荐，从而有效增强用户体验，提升运营效果。

通常，用户的出行决策在平台上只得到部分的展示，数据往往呈现出高度稀疏的特点，用户是否从A出行到B又受到天气、需求变动等多方面影响，出行需求预测具有相当难度。但用户出行需求又有一定场景，每一场景都有其特征，如通勤类（稳定性，固定时间地点），旅游类（异地，热门景点），娱乐类（餐饮，娱乐场所，往返）等，表明用户个体的出行需求，一定程度上是可预测的。通过机器学习算法，挖掘滴滴的用户数据，预测每一个个体用户未来出行的可能性和场景，对于后续通过个性化的运营手段引导和促进用户共享出行，具有重要意义。

3.研究目标

针对上述关键问题，研究目标包括不限于：

1) 乘客未来24小时出行路径预测

通过滴滴收集的海量数据，包括历史行程，用户位置，订单数据，结合POI，天气情况，社会事件（演唱会，春运）等数据，利用机器学习算法，预测个体用户未来24小时的出行路径（从A到B），并相应地计算其概率。

4.性能要求与期待产出

模型预测效果的衡量指标：

1. TOPN预测路径对实际出行路径的准召（典型地，N=1，3）

2. 预测TOP1召回路径上实际是否出行的AUC因不同场景下的预测需求难度和意义不一样（如通勤类易预测，娱乐类相对难），因此上述指标宜依据场景不同而分别衡量。

要求：

1. 在分类场景下，个体用户出行预测的准召等指标方面取得较好效果；

2. 在学术上体现算法先进性和模型的创新性；

3. 算法和模型能够在滴滴业务场景中落地。

注意

更多项目信息

请关注主题研究计划官方主页：

https://outreach.didichuxing.com/RFP

项目组邮件通知：

gaia@didichuxing.com

解读 | 滴滴主题研究计划：机器学习专题（上篇）

您的留言将激励我们越做越好

	</div><!-- #content -->
</div>

云服务器 DC2

可随时自助获取、可弹性伸缩的云服务器，帮助用户打造安全、可靠、灵活、高效的应用环境，满足持久稳定运行的需求，提升运维效率。

立即体验

标签

Java编程详细解析—淘宝大秒杀系统是如何设计的？

2018年10月17日小刀爱编程

摘要

最初的秒杀系统的原型是淘宝详情上的定时上架功能，由于有些卖家为了吸引眼球，把价格压得很低。但这给的详情系统带来了很大压力，为了将这种突发流量隔离，才设计了秒杀系统，文章主要介绍大秒系统以及这种典型读数据的热点问题的解决思路和实践经验。

一些数据

大家还记得2013年的小米秒杀吗？三款小米手机各11万台开卖，走的都是大秒系统，3分钟后成为双十一第一家也是最快破亿的旗舰店。经过日志统计，前端系统双11峰值有效请求约60w以上的QPS ，而后端cache的集群峰值近2000w/s、单机也近30w/s，但到真正的写时流量要小很多了，当时最高下单减库存tps是红米创造，达到1500/s。

热点隔离

秒杀系统设计的第一个原则就是将这种热点数据隔离出来，不要让1%的请求影响到另外的99%，隔离出来后也更方便对这1%的请求做针对性优化。针对秒杀我们做了多个层次的隔离：

业务隔离。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热。

系统隔离。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中。

数据隔离。秒杀所调用的数据大部分都是热数据，比如会启用单独cache集群或MySQL数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%。

当然实现隔离很有多办法，如可以按照用户来区分，给不同用户分配不同cookie，在接入层路由到不同服务接口中；还有在接入层可以对URL的不同Path来设置限流策略等。服务层通过调用不同的服务接口；数据层可以给数据打上特殊的标来区分。目的都是把已经识别出来的热点和普通请求区分开来。

动静分离

前面介绍在系统层面上的原则是要做隔离，接下去就是要把热点数据进行动静分离，这也是解决大流量系统的一个重要原则。如何给系统做动静分离的静态化改造我以前写过一篇《高访问量系统的静态化架构设计》详细介绍了淘宝商品系统的静态化设计思路，感兴趣的可以在《程序员》杂志上找一下。我们的大秒系统是从商品详情系统发展而来，所以本身已经实现了动静分离，如图1。

图1 大秒系统动静分离

除此之外还有如下特点：

把整个页面Cache在用户浏览器

如果强制刷新整个页面，也会请求到CDN

实际有效请求只是“刷新抢宝”按钮

这样把90%的静态数据缓存在用户端或者CDN上，当真正秒杀时用户只需要点击特殊的按钮“刷新抢宝”即可，而不需要刷新整个页面，这样只向服务端请求很少的有效数据，而不需要重复请求大量静态数据。秒杀的动态数据和普通的详情页面的动态数据相比更少，性能也比普通的详情提升3倍以上。所以“刷新抢宝”这种设计思路很好地解决了不刷新页面就能请求到服务端最新的动态数据。

基于时间分片削峰

熟悉淘宝秒杀的都知道，第一版的秒杀系统本身并没有答题功能，后面才增加了秒杀答题，当然秒杀答题一个很重要的目的是为了防止秒杀器，2011年秒杀非常火的时候，秒杀器也比较猖獗，而没有达到全民参与和营销的目的，所以增加的答题来限制秒杀器。增加答题后，下单的时间基本控制在2s后，秒杀器的下单比例也下降到5%以下。新的答题页面如图2。

图2 秒答题页面

其实增加答题还有一个重要的功能，就是把峰值的下单请求给拉长了，从以前的1s之内延长到2~10s左右，请求峰值基于时间分片了，这个时间的分片对服务端处理并发非常重要，会减轻很大压力，另外由于请求的先后，靠后的请求自然也没有库存了，也根本到不了最后的下单步骤，所以真正的并发写就非常有限了。其实这种设计思路目前也非常普遍，如支付宝的“咻一咻”已及微信的摇一摇。

除了在前端通过答题在用户端进行流量削峰外，在服务端一般通过锁或者队列来控制瞬间请求。

数据分层校验

图3 分层校验

对大流量系统的数据做分层校验也是最重要的设计原则，所谓分层校验就是对大量的请求做成“漏斗”式设计，如图3所示：在不同层次尽可能把无效的请求过滤，“漏斗”的最末端才是有效的请求，要达到这个效果必须对数据做分层的校验，下面是一些原则：

先做数据的动静分离
将90%的数据缓存在客户端浏览器
将动态请求的读数据Cache在Web端
对读数据不做强一致性校验
对写数据进行基于时间的合理分片
对写请求做限流保护
对写数据进行强一致性校验

秒杀系统正是按照这个原则设计的系统架构，如图4所示。

图4 秒杀系统分层架构

把大量静态不需要检验的数据放在离用户最近的地方；在前端读系统中检验一些基本信息，如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束等；在写数据系统中再校验一些如是否是非法请求，营销等价物是否充足（淘金币等），写的数据一致性如检查库存是否还有等；最后在数据库层保证数据最终准确性，如库存不能减为负数。

实时热点发现

其实秒杀系统本质是还是一个数据读的热点问题，而且是最简单一种，因为在文提到通过业务隔离，我们已能提前识别出这些热点数据，我们可以提前做一些保护，提前识别的热点数据处理起来还相对简单，比如分析历史成交记录发现哪些商品比较热门，分析用户的购物车记录也可以发现那些商品可能会比较好卖，这些都是可以提前分析出来的热点。比较困难的是那种我们提前发现不了突然成为热点的商品成为热点，这种就要通过实时热点数据分析了，目前我们设计可以在3s内发现交易链路上的实时热点数据，然后根据实时发现的热点数据每个系统做实时保护。具体实现如下：

构建一个异步的可以收集交易链路上各个中间件产品如Tengine、Tair缓存、HSF等本身的统计的热点key（Tengine和Tair缓存等中间件产品本身已经有热点统计模块）。

建立一个热点上报和可以按照需求订阅的热点服务的下发规范，主要目的是通过交易链路上各个系统（详情、购物车、交易、优惠、库存、物流）访问的时间差，把上游已经发现的热点能够透传给下游系统，提前做好保护。比如大促高峰期详情系统是最早知道的，在统计接入层上Tengine模块统计的热点URL。

将上游的系统收集到热点数据发送到热点服务台上，然后下游系统如交易系统就会知道哪些商品被频繁调用，然后做热点保护。如图5所示。

图5 实时热点数据后台

重要的几个：其中关键部分包括：

这个热点服务后台抓取热点数据日志最好是异步的，一方面便于做到通用性，另一方面不影响业务系统和中间件产品的主流程。

热点服务后台、现有各个中间件和应用在做的没有取代关系，每个中间件和应用还需要保护自己，热点服务后台提供一个收集热点数据提供热点订阅服务的统一规范和工具，便于把各个系统热点数据透明出来。

热点发现要做到实时（3s内）。

关键技术优化点

前面介绍了一些如何设计大流量读系统中用到的原则，但是当这些手段都用了，还是有大流量涌入该如何处理呢？秒杀系统要解决几个关键问题。

Java处理大并发动态请求优化

其实Java和通用的Web服务器相比（Nginx或Apache）在处理大并发HTTP请求时要弱一点，所以一般我们都会对大流量的Web系统做静态化改造，让大部分请求和数据直接在Nginx服务器或者Web代理服务器（Varnish、Squid等）上直接返回（可以减少数据的序列化与反序列化），不要将请求落到Java层上，让Java层只处理很少数据量的动态请求，当然针对这些请求也有一些优化手段可以使用：

直接使用Servlet处理请求。避免使用传统的MVC框架也许能绕过一大堆复杂且用处不大的处理逻辑，节省个1ms时间，当然这个取决于你对MVC框架的依赖程度。

直接输出流数据。使用resp.getOutputStream()而不是resp.getWriter()可以省掉一些不变字符数据编码，也能提升性能；还有数据输出时也推荐使用JSON而不是模板引擎（一般都是解释执行）输出页面。

同一商品大并发读问题

你会说这个问题很容易解决，无非放到Tair缓存里面就行，集中式Tair缓存为了保证命中率，一般都会采用一致性Hash，所以同一个key会落到一台机器上，虽然我们的Tair缓存机器单台也能支撑30w/s的请求，但是像大秒这种级别的热点商品还远不够，那如何彻底解决这种单点瓶颈？答案是采用应用层的Localcache，即在秒杀系统的单机上缓存商品相关的数据，如何cache数据？也分动态和静态：

像商品中的标题和描述这些本身不变的会在秒杀开始之前全量推送到秒杀机器上并一直缓存直到秒杀结束。

像库存这种动态数据会采用被动失效的方式缓存一定时间（一般是数秒），失效后再去Tair缓存拉取最新的数据。

你可能会有疑问，像库存这种频繁更新数据一旦数据不一致会不会导致超卖？其实这就要用到我们前面介绍的读数据分层校验原则了，读的场景可以允许一定的脏数据，因为这里的误判只会导致少量一些原本已经没有库存的下单请求误认为还有库存而已，等到真正写数据时再保证最终的一致性。这样在数据的高可用性和一致性做平衡来解决这种高并发的数据读取问题。

同一数据大并发更新问题

解决大并发读问题采用Localcache和数据的分层校验的方式，但是无论如何像减库存这种大并发写还是避免不了，这也是秒杀这个场景下最核心的技术难题。

同一数据在数据库里肯定是一行存储（MySQL），所以会有大量的线程来竞争InnoDB行锁，当并发度越高时等待的线程也会越多，TPS会下降RT会上升，数据库的吞吐量会严重受到影响。说到这里会出现一个问题，就是单个热点商品会影响整个数据库的性能，就会出现我们不愿意看到的0.01%商品影响99.99%的商品，所以一个思路也是要遵循前面介绍第一个原则进行隔离，把热点商品放到单独的热点库中。但是无疑也会带来维护的麻烦（要做热点数据的动态迁移以及单独的数据库等）。

分离热点商品到单独的数据库还是没有解决并发锁的问题，要解决并发锁有两层办法。

应用层做排队。按照商品维度设置队列顺序执行，这样能减少同一台机器对数据库同一行记录操作的并发度，同时也能控制单个商品占用数据库连接的数量，防止热点商品占用太多数据库连接。

数据库层做排队。应用层只能做到单机排队，但应用机器数本身很多，这种排队方式控制并发仍然有限，所以如果能在数据库层做全局排队是最理想的，淘宝的数据库团队开发了针对这种MySQL的InnoDB层上的patch，可以做到数据库层上对单行记录做到并发排队，如图6所示。

图6 数据库层对单行记录并发排队

你可能会问排队和锁竞争不要等待吗？有啥区别？如果熟悉MySQL会知道，InnoDB内部的死锁检测以及MySQL Server和InnoDB的切换会比较耗性能，淘宝的MySQL核心团队还做了很多其他方面的优化，如COMMIT_ON_SUCCESS和ROLLBACK_ON_FAIL的patch，配合在SQL里面加hint，在事务里不需要等待应用层提交COMMIT而在数据执行完最后一条SQL后直接根据TARGET_AFFECT_ROW结果提交或回滚，可以减少网络的等待时间（平均约0.7ms）。据我所知，目前阿里MySQL团队已将这些patch及提交给MySQL官方评审。

大促热点问题思考

以秒杀这个典型系统为代表的热点问题根据多年经验我总结了些通用原则：隔离、动态分离、分层校验，必须从整个全链路来考虑和优化每个环节，除了优化系统提升性能，做好限流和保护也是必备的功课。

除去前面介绍的这些热点问题外，淘系还有多种其他数据热点问题：

数据访问热点，比如Detail中对某些热点商品的访问度非常高，即使是Tair缓存这种Cache本身也有瓶颈问题，一旦请求量达到单机极限也会存在热点保护问题。有时看起来好像很容易解决，比如说做好限流就行，但你想想一旦某个热点触发了一台机器的限流阀值，那么这台机器Cache的数据都将无效，进而间接导致Cache被击穿，请求落地应用层数据库出现雪崩现象。这类问题需要与具体Cache产品结合才能有比较好的解决方案，这里提供一个通用的解决思路，就是在Cache的client端做本地Localcache，当发现热点数据时直接Cache在client里，而不要请求到Cache的Server。

数据更新热点，更新问题除了前面介绍的热点隔离和排队处理之外，还有些场景，如对商品的lastmodifytime字段更新会非常频繁，在某些场景下这些多条SQL是可以合并的，一定时间内只执行最后一条SQL就行了，可以减少对数据库的update操作。另外热点商品的自动迁移，理论上也可以在数据路由层来完成，利用前面介绍的热点实时发现自动将热点从普通库里迁移出来放到单独的热点库中。

按照某种维度建的索引产生热点数据，比如实时搜索中按照商品维度关联评价数据，有些热点商品的评价非常多，导致搜索系统按照商品ID建评价数据的索引时内存已经放不下，交易维度关联订单信息也同样有这些问题。这类热点数据需要做数据散列，再增加一个维度，把数据重新组织。

本文出自头条号，作者小刀爱编程，查看【原文链接】