7. 欧阳康 - 快的打车Qcon分享 新.pptxVIP

快的打车技术成长历程分享kyo.ou@ 快的打车架构师 欧阳康业务发展概况“打车大战”“一号专车”覆盖全国32个城市“一号专车”上线日订单：600w+收购“大黄蜂”，开启商务车业务覆盖城市：70+公司成立，8月“快的打车”上线运营“打车大战”快的人的“出埃及记”存储问题长连接服务稳定性LBS瓶颈LBS瓶颈及解决方案快的 LBS主要应用场景DriversPassengersRHttp ServerTcp ServerLBS Query 1w+/sUpdate 4w+/sLBSLBS瓶颈及解决方案实时更新难以实现LBS可选方案伸缩性难以实现开发测试周期较长LBS瓶颈及解决方案MongoDB as LBS Server对实时更新支持较好通过副本集可以很容易地实现读写分离及负载均衡开发、部署较简单Write快的LBS Mongo集群结构MS1S2S3ReadLBS瓶颈及解决方案MongoDB 2d 查询原理(2.6版本)db.runCommand( { geoNear: “mycollection”, near : [120.5842,30.6597], maxDistance:5 });db.mycollection.find({loc:” wxec4e02”});db.mycollection.find({loc:” wxdf0ef3”});……LBS瓶颈及解决方案读写都很密集(4w+/s写,1w+/s读)时出现的问题:从服务器 cpu负载急剧上升查询性能急剧降低(大量查询耗时超过800毫秒)查询吞吐量大幅降低主从复制出现较大的延迟MongoDB geo 瓶颈100w+条700M原因：锁等待1.Mongodb 目前(2.6.4版本)锁是库级别的锁，每一次写都会锁库2.每一次LBS查询，会分解成许多次单独的子查询，增大了整个查询的锁等待概率WriteMS1S2S3解决方案：A. mongodb行锁(2.8版本，据说)B. 分片C. LBS From ScratchReadLBS瓶颈及解决方案分片wwwwMMMMrrrrSSSSSSSSSSSSLBS瓶颈及解决方案LBS From Scratch（120.5842,30.6597）ClientGeoHashwx4g0ec1Server IndexStorageLBS瓶颈及解决方案（120.5842,30.6597）LBS From ScratchGeo HashS2 Libaray2d CoveringClient Sidewx4g0ec1Geo MatchLoc Compute Servicewx4f0e32, w34f0ed2, wx4f3ed2…Store ServiceServer SideRedisRedisRedisLBS瓶颈及解决方案性能(3台redis)写：15w+读：18w+伸缩性GeoHash,Geo Match放在客户端,很容易水平伸缩，服务端的存储通过一致性hash算法实现伸缩性扩展性GeoHash,GeoMatch,Storage 都设计成插件，便于替换LBS From ScratchClientsGeo QueryLVSGeo Hash and Geo MatchAPPAPPAPPAPPAPPStorage Layerredisredisredisredis长连接服务稳定性快的长连接服务器架构Clients硬件问题：不支持多队列的网卡不能充分利用多核CPULVSMina框架不能很好地处理大量并发连接Tcp ServerTcp Server长连接服务稳定性长连接服务器遇到的主要问题硬件： 不支持多队列的网卡，IO中断都被分配到了一个cpu核上，大量数据包到来的情况下，单个cpu核无法全部处理，导致LVS不断丢包，连接不断中断。解决方案： 更换支持硬件多队列的网卡(Intel 82575、82576，Boardcom的57711等， linux 内核版本需要在2.6.21以上)长连接服务稳定性长连接服务器遇到的主要问题软件：Mina框架的问题内存使用控制不够细粒度，垃圾回收难以有效控制空闲连接检查效率不高，在大量连接的情况下会出现周期性CPU 使用率飙高编解码组件在高并发下会出现消息被截断的情况快的长连接业务的主要特点大量的广播消息推送具有不同的优先级长连接服务稳定性快的自己的AIO框架（基于java 7实现）资源(主要是ByteBuffer)池化,减少GC造成的影响广播时，一份ByteBuffer复用到多个通道，减少内存拷贝使用TimerWheel检测空闲连接，消除空闲连接检测造成的 CPU尖峰支持按优先级发送数据Timer wheel数据存储快的数据库瓶颈：10亿+条数据的表，600w+日增量业务数据特点：热点数据集中在2-3天内访问，一周以前的数据很少