2019年快狗打车智能调度系统架构演进.pdf

《2019年快狗打车智能调度系统架构演进.pdf》由会员分享，可在线阅读，更多相关《2019年快狗打车智能调度系统架构演进.pdf（48页珍藏版）》请在三个皮匠报告上搜索。

1、目录创业之初高速发展智能驱动总结01020304搬家货运2014年2015年2016年货的搬家服务上线企业服务上线 平台日订单突破20万快狗打车150+个驻点城市，200万注册司机，累计服务货运用户过亿次覆盖中国及东南亚地区的同城货运平台2017年快狗打车与GGV合并2018年平台日订单突破40W2019年平台化&增长.创业之初快速迭代试错家政速运美甲平台jzsymjplonlyonen 快速孵化多个业务(20+)n节奏：3周内上线，含用户侧APP、商家APP、管理后台业务孵化APPPC其他.OrderPushJar司机1司机2司机3MQTTAPPPC其他.OrderPushJar派单-石器时

2、代n 简单的距离推送n 抢单即中单n 每单都有补贴订单调度（初级）n系统不稳定，一个慢SQL，全业务受影响。n多业务并存，订单表索引多，性能下降。n订单字段冗余，新增和修改字段非常痛苦。n业务增长迅猛，数据库已成为瓶颈。成长痛点第一次技术演进迁库、集群解耦思考：n停服迁移？NO！方案：n将速运的表单独同步到速运独立库n数据双向同步（特殊的订单ID保证主键不重复）n数据校验（数据写入日志，数据校对）。速运1suyunorderall order速运2其他业务数据库拆分速运order迁移后：n 按数据内容分库，解耦合n 按业务量调整数据库配置，减少成本订单结算配置轨迹settlecommonsna

3、p数据库拆分高速发展稳定高效n争分夺秒n补贴大战n快速迭代多人维护一套工程，效率差，BUG频发n业务高速发展，数据量急速增长n运营分析需求越来越复杂n补贴大战，大量无效补贴，运营成本高高速发展中的问题第二次技术演进第二次技术演进奔跑中的火车换轮子奔跑中的火车换轮子n服务化解耦n缓存&分库分表-提升系统性能n大数据平台-复杂需求分析其他.OrderCenterServerOrderPushServerTCPGeTuiMiPush司机1司机2司机3APPPCTaskServerSettleServerPayServer.n模块服务化n推送多通道派单-铁器时代n 按距离、象限推送n多司机择优（好评、

4、完成率）n多轮推送、补贴随抢单人数调整订单调度（探索）项目之初读写分离水平/垂直拆分分库+读写分离分库分表n 范围法优点：切分简单，扩容简单。不足：Key必须增长，负载不均匀。n 哈希法优点：切分简单，负载均衡。不足：扩容麻烦，平滑迁移是需要解决的困难点水平拆分n部分查询变慢了非patition key查询，需要遍历全部库n运营需求无法实现各种维度统计，没办法联表查询拆分后问题n前端需求n运营需求按照年龄、性别、头像、登陆时间、注册时间来进行统计分析。1%99%uidlogin_namephoneemailxxxxx问题分析任何脱离业务的架构设计都是耍流氓n索引表法非patition key与

5、uid建立索引表n缓存映射法非patition key与uid映射关系放入缓存，缓存命中率高n非patition key生成uid根据loginname或XXXX生成uid，需要技巧，有主键冲突风险n基因法根据loginname或XXXX多个属性的部分字段生成uid前端解决方案思路：1）假设分8库，采用uid%8路由，潜台词是，uid的最后3个bit决定这条数据落在哪个库上，这3个bit就是所谓的“基因”。2）f(login_name)生成login_name_gene。3）生成全局唯一的id(61bit)4）uid=全局唯一id与基因的拼装基因法n冗余后台库通过MQCanal实时同步到后台库

6、n大数据平台实时拉取数据库数据进行统计和回写。n外置搜索引擎ES/Solr/XXXX运营侧需求解决方案平台补贴如何高效，起到真正补贴的作用？如何尽量满足用户的需求？如何分配司机的收益？反思第三次技术演进战斧项目n策略服务细化n智能模型接入n智能分流框架智能时代效率、精准日志中心大数据平台APPH5ServerDBDTS/Canal日志上报flume/kafka.数据收集归一化&分桶XGBoost特征组合独热编码数据切分：训练集+测试集归一化&分桶逻辑回归+L1性能检测反向编码特征处理数据收集模型训练订单信息用户信息司机信息客司关系信息订单推送、司机接单的