6-SDCC2015-快的打车-王小雪-快的打车架构实践分析报告.pdfVIP

快的打车架构实践 王小雪 发展历程 （体系化的架构设计） 3 V （核心链路优化） 2 V 2015.2 2014.4 用） 013.12 1亿用户 滴滴快的合并 能可 2 日订单：600w+ （功 收购 “大黄 1 V 2013.7 蜂”，开启 商务车业务 覆盖城市：70+ 2012.5 5月成立，8 月上线运营 V1阶段——基本功能可用  公司没有知名度  系统仅满足基本的功能  技术团队10-30人左右  天气不好系统就崩溃  日订单从几百 到几万  快的一崩溃滴滴也崩溃  作坊式研发  反过来也是一样，很有默契 确立了原始的系统模型 MongoDB Mina V2阶段——核心链路优化 2013年底打车大战爆发，很短时间内，日订单规模从几万单迅速膨胀到几百万单。系统面 临很多问题，我们将问题分优先级，首先对核心链路进行优化，否则业务主流程都无法正 常进行。 核心链路问题及业务影响 LBS瓶颈 问题：暴增的LBS查询和写入给MongoDB带来巨大的压力，经常会延时 影响：推单时选取的司机有时离乘客很远，或者很近的却没有推送 长连接服务稳定性 问题：TCP server高峰期CPU load很高、消息被截断、连接丢失 影响：司机收不到订单；司机接单了乘客却不知道；乘客取消订单了司机不知道 LBS瓶颈和方案 长连接服务稳定性 硬件问题 不支持多队列的网卡，IO中断都被分配到了一个cpu核上，大量数据包到来的情况下，单个 cpu核无法全部处理，导致LVS不断丢包，连接不断中断。 解决方案 更换支持硬件多队列的网卡(Intel 82575、82576，Boardcom的57711等， linux 内核版本需要 在2.6.21 以上) 长连接服务稳定性 软件问题（Min 框架） 1 内存使用控制不够细粒度，垃圾回收难以有效控制 2 空闲连接检查效率不高，在大量连接的情况下会出现周期性CPU 使用率飙高 3 编解码组件在高并发下会出现消息被截断的情况 解决方案 （快的自己的AIO框架）  资源(主要是ByteBuffer)池化,减少GC造成的影响  广播时，一份ByteBuffer复用到多个通道，减少内存拷贝  使用TimerWheel检测空闲连接，消除空闲连接检测造成的 CPU尖峰  支持按优先级发送数据