网约车系统开发方案与容量评估
2022-09-09 10:23:34 行业资讯一、网约车系统项目背景
Ptaxi网约车软件开发客户
二、网约车系统业务流程
网约车系统客户端设计
考虑乘客获取预估价格的查询是否会有性能瓶颈,我的理解应该是调用地图提供商接口,获取公里数,再计算价格。只需考虑ecs能够横向扩容即可。
网约车系统司机端设计
抢单模式:
1.司机端抢单模式下,主动查询符合条件的订单列表,此处需要考虑列表查询算法优化。压力在数据库端,避免全表扫描,可采用网格定义方式提高查询效率,降低数据库压力。
2.获取列表后,司机端需要点击抢单,对于多个司机返回列表并排序在前的客户订单状态,会存在热更新,有且只有一个司机能够对某个客户订单update并打上司机id。抢单时update司机id为抢单司机id where司机id=Null,并读取update返回记录条数,如果update返回记录为0则说明抢单失败,即司机id已被更新不为null。此处直接利用数据库锁即可,考虑到司机数量远小于乘客数量,并且司机抢单并非定时秒杀模式,时间分散,因此数据库锁影响可以忽略。
派单模式:
后台计算匹配的司机id,并向客户端进行推送。此处仅需考虑对计算过程的效率以及性能压力即可,同样匹配逻辑是寻找最近距离司机,同样通过网格编号查询距离,通过子域id限定查询范围,提高查询效率。
三、网约车系统架构设计
1.客户端通过软负载均衡SLB接入服务端。
2.服务端利用ESS弹性计算功能,支持在CPU超过一定阈值时,进行弹性扩容。
3.司机端服务于乘客端服务进行分离,以支持系统解耦,按需扩容。
4.司机端与乘客端服务器在首期只连接一个RDS数据库,后续按需进行分布式数据库扩容。
5.利用Redis存放网格id与网格子域的映射关系的映射关系,以保障快速查询。
四、网约车系统核心算法
通过地图网格算法的方式,降低经纬度计算压力,通过网格子域的方式,减少查询范围,提高订单匹配效率。网格算法:A1,B1,属于同一子域(图中不同颜色),子域ID为sub-zone,在同一子域中查询匹配条件。
五、网约车系统性能评估
目标:通过性能评估,获知系统支持容量,对后续扩容进行支持。
工具:Apache ab test
服务器配置:16c32g服务器上部署应用服务节点
测试条件:假设抢单时司机连续点击次数平均为3次
测试内容:
程序只从数据库读取一条字段记录做的select查询处理的QPS压测地址
http://www.ptaxi.cn/api/test/qps
https://www.ptaxi.cn/api/test/qps
程序做了事务处理的TPS压测地址
http://www.ptaxi.cn/api/test/tps
https://www.ptaxi.cn/api/test/tps
测试结果分析:
1.HTTP性能明显优于HTTPS性能,其中原因是HTTPS进行了通讯加密,应用程序还需承担证书卸载的压力,如果采用SLB进行证书卸载,HTTPS性能可以进一步提升。2.在HTTP通讯条件下,吞吐量QPS以及TPS均在并发为1000时出现拐点,因此该配置服务器最大支持的HTTP并发为1000,QPS最高为802,TPS最高为750。
3.在不采用SLB的情况下,吞吐量QPS以及TPS均在并发为500时出现拐点,因此该配置服务器最大支持的HTTPS并发为500,QPS最高113,TPS最高为130。
因此系统如需HTTP通讯支持吞吐量超过1000或HTTPS通讯支持吞吐量超过500时,则需要进行配置升级,通过横向扩容进行支持,并考虑数据库瓶颈情况。
六、推荐配置
根据性能评估结果,服务端配置至少两台16c32g以上进行负载均衡,单台能够达到700+QPS。后续按需进行横向弹性扩容。拆分为4c8gECS则至少各需要4台。
Ptaxi猿著专注出行软件开发,提供打车软件开发/出租车+电召系统开发/城际客运定制app开发/租车app开发/顺风车软件开发/代驾app开发;助力企业搭建网约车平台,代办或协助申请拿网络预约出租汽车经营许可证!
更多资讯
猿著打车软件开发获悉秦皇岛市《网络预约出租汽车运输证》开始办理
Ptaxi网约车软件开发获悉三大造车新势力,先后瞄准网约车市场
每月持续产品迭代更新
快速Saas搭建+定制开发
专属客户经理提供技术支持
提供企业合同及国家增值税发票