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

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