elasticsearch实践篇：智能运输产品

朱雀 2022-02-05 07:53 365阅读 0赞

Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎，一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎。非常幸运的是，之前规划了很久的智能运输产品搜索与推荐在3个月前如期上线了，下面将分享下Elasticsearch 在业务系统中应用。

### **背景** ###

一条运输产品是有提货（服务区域）报价、干线（地点到地点）报价、配送（服务区域）报价、路由、项目合同报价、服务区域（地图上一个不规则的区域）以及各种平台服务收费项等基础数据构成。而一个运输产品的生成是非常复杂的，它由各种线路成员的提+干+配组合构成、既包含了路由生成规则信息、也包含会员身份信息（有过滤）及平台规则（有过滤）。

服务区（多边形）针对长宁区画出来，mysql存储类型是geometry 。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70][]

运输产品的选择页面

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 1][]

**它如何实现的呢？**

主要是实时计算，通过发站-到站找到路由，再通过路由（如：上海-南京-厦门）产生的笛卡尔乘积（每段之间都有不同的线路成员的报价），每次动态计算要关联非常多张表，很多依赖系接口以及大量复杂的计算。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 2][]

**它也带来了很多的问题？**

> 产品经理说：
> 
> 1.  选运输产品页面展示复杂，信息摆放错综杂乱，关键信息不突出
> 2.  选运输产品页面前端逻辑复杂，每次优化牵一发动全身
> 3.  产品未静态化，每次匹配拼装产品，影响性能，体验不好
> 4.  产品配置功能实现单一，无法对交易场景进行配置，目前只是做了简单的配置并无限堆积，扩展性不强

> 开发者说：
> 
> 1.  查询速度慢，提配产品基于服务圈，耗时(无法缓存,命中率无限趋向于0)且难以排查问题；涉及大量复杂IO计算
> 2.  未能抽象出一个完整的产品对象，无法分页问题；个性化较高（产品配置页面）；用户身份以及大量个性化入参影响查询结果；动态产品会导致拿不到评价信息
> 3.  交易后的运输产品快照，通过反推来展示繁琐

### **曾做过的优化** ###

其实我们也进行过阶段性的优化

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 3][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 4][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 5][]

但这些优化还远远不够，任重道远！

### 预期 ###

首先，进行基础数据的重塑

1.  取消服务区域，可以按行政区域划分
2.  统一报价阶梯，统一干线、配送产品的报价阶梯
3.  价格对象，现在的价格对象没有调整价格的作用，而是现在的产品对象

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 6][]

### 最终目标 ###

希望提高更丰富的搜索功能，为后续的**产品推荐**做准备。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 7][]

### 争议点 ###

**1. 运输产品要不要静态化？**

<table> 
 <tbody> 
 <tr> 
 <td style="width:70.65pt;"> &nbsp; </td> 
 <td style="width:155.9pt;"> 非静态化 </td> 
 <td style="width:429px;"> 静态化 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:70.65pt;"> 优点 </td> 
 <td style="vertical-align:top;width:155.9pt;"> 时效性较好 </td> 
 <td style="vertical-align:top;width:429px;"> 可以解决上面存在的大量问题 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:70.65pt;"> 缺点 </td> 
 <td style="vertical-align:top;width:155.9pt;"> 现有问题依然存在 </td> 
 <td style="vertical-align:top;width:429px;"> 但还是存在费用上繁杂上的计算，时效性有一定的延迟 </td> 
 </tr> 
 </tbody> 
</table>

可选的解决方案：

<table> 
 <tbody> 
 <tr> 
 <td style="width:84.8pt;"> 方案 </td> 
 <td style="width:122.6pt;"> geometry </td> 
 <td style="width:103.7pt;"> 图搜算法 </td> 
 <td style="width:237px;"> 全文搜索(更新) </td> 
 </tr> 
 <tr> 
 <td style="width:84.8pt;"> Neo4j </td> 
 <td style="vertical-align:top;width:122.6pt;"> 不支持 </td> 
 <td style="vertical-align:top;width:103.7pt;"> 非常丰富 </td> 
 <td style="vertical-align:top;width:237px;"> 不需要 </td> 
 </tr> 
 <tr> 
 <td style="width:84.8pt;"> 高阶map-reduce </td> 
 <td style="vertical-align:top;width:122.6pt;"> 继续使用mysql </td> 
 <td style="vertical-align:top;width:103.7pt;"> 没有 </td> 
 <td style="vertical-align:top;width:237px;"> 不需要 </td> 
 </tr> 
 <tr> 
 <td style="width:84.8pt;"> es search </td> 
 <td style="vertical-align:top;width:122.6pt;"> 支持 </td> 
 <td style="vertical-align:top;width:103.7pt;"> 没有 </td> 
 <td style="vertical-align:top;width:237px;"> 支持 </td> 
 </tr> 
 <tr> 
 <td style="width:84.8pt;"> mongodb </td> 
 <td style="vertical-align:top;width:122.6pt;"> 支持 </td> 
 <td style="vertical-align:top;width:103.7pt;"> 没有 </td> 
 <td style="vertical-align:top;width:237px;"> 支持 </td> 
 </tr> 
 </tbody> 
</table>

**2. 要不要静态化提配（服务区域）的信息？**

关于提配的产品，由于该信息是基于用户坐标才能筛选出相关的产品，而静态化处理（不可能有坐标，就没有这块产品）会导致运输产品的链条不完整，如果这块业务不能接受按行政区域（非坐标），那就必须添加新的交互来解决它，这样徒增产品搜索的复杂度。

### 最终方案 ###

最终业务上做了妥协，采用了静态化。静态化上我们采用全量（对现有数据进行全部迁移）+增量（对有变化数据及时更新）来保障es的数据完整性、准确性、时效性

**组件图**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 8][]

**设计方案 **

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 9][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 10][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 11][]

**时序图（略，有敏感数据不展示）**

**物理拓扑图**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 12][]

在实践的过程中，我们也遇到了非常多的坑，下面将分享下我们这方面的经验。

### 坑1：Bin-log数据事件暴增问题 ###

比如：一个用户在货运圈修改了“干线产品发布”中某些信息，从当前系统角度看，它是一个用户事件，而物理模型设计要满足数据库的范式（可能会分成很多表），这时候bin-log的master会把这些表的变动都推送过来。

解决方案：只关注主表的变动（从表的变动要映射到主表上）

### 坑2：关于评价及交易量的存储问题 ###

由于评价是由评价系统针对整段运输产品定期生成的，时间上不确定性。

交易量是某一段（干线）触发统计的，时间上比较随机。

Es-search要不要存储及更新评价、交易量、折扣？如果要存的话，实时性只能是准实时：虑到整段运输产品数据量非常大，

评价评分：

解决方案：有变化就推送（匹配规则 key=inputKey）。

交易量：

解决方案：有变化就推送（匹配规则 key like %transLineId%）

解决方案2：从canal中读取并处理

折扣：

解决方案：目前无法确定增量范围，待定

### 坑3：定时任务效率不高 ###

全量时太慢，采用elastic-job的任务分片

### 坑4：Canal高可用问题 ###

目前只能提供单机服务问题

解决方案：运维做keepalive，目前官方没有很好的方案，故障最好的处理机制就是重启（应该重跑某一段时间内的增量），另外就是加强监控。

### 坑5：笛卡尔乘积批量太多导致elastic-search频繁超时 ###

单个批量（5000条路由会产生100w种组合）太大操作bulk时不时的超时，[参阅对应解决方法 ][Link 1]

### 坑6：保障ES实时性与一致性 ###

关于实时性方面，业务接受允许一定的延迟（30s内），而一致性方面陆续采用很多幂等性设计比如业务乐观锁字段（order\_state更新递增）、version 字段等。![85332335][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70]: /images/20220205/b7dc841f29db4541875915a61ea58609.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 1]: /images/20220205/cfd78f27b2254e3bb70837cce82dd2eb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 2]: /images/20220205/f4752d3a222e412ca78afc27703c74ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 3]: /images/20220205/b61db3685e204343b8fa7e22fe12c425.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 4]: /images/20220205/1b19eaa4867a4446be3dc0254031bf4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 5]: /images/20220205/6ba601491e4a4fdf9c5ec88a17d7ea9e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 6]: /images/20220205/71f04678735c4766ba1a7159a0bbcb19.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 7]: /images/20220205/dc9f16bbb558487b9242c646edfb75d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 8]: /images/20220205/b711df2b24c64b448e05c09f878cd14f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 9]: /images/20220205/e0220064e3f84bf4b121782219f4c0f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 10]: /images/20220205/edfb913f023349baa3620e1b6799d279.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 11]: /images/20220205/411b3a87e55b4b69a798c43b2a90f512.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 12]: /images/20220205/d2faaad296d545fd9f87831efa02637e.png
[Link 1]: https://blog.csdn.net/alex_xfboy/article/details/88027849
[85332335]: /images/20220205/6abf2c8dcddf47299df2823f64cc059c.png