day01-环境搭建与登录
● 简单介绍下你做的物流项目。
参考回答：我最近做过的一个项目是物流类的项目叫做xxxx 是公司自研的一个项目, 主要是为了体现智能调度这一方面, 主要是基于微服务架构体系的物流项目系统, 主要是通过智能管控车辆调研、线路规划等核心业务流程，操作智能化，大幅度提升人效及管控效率, 节省运输成本;该项目类似顺丰速运，是向C端提户提供快递服务的系统。竞品有：顺丰、中通、圆通、京东快递等。项目产品主要有4端产品：用户端：基于微信⼩程序开发，外部客户使用，可以寄件、查询物流信息等。快递员端：基于安卓开发的手机APP，公司内部的快递员使用，可以接收取派件任务等。司机端：基于安卓开发的手机APP，公司内部的司机使用，可以接收运输任务、上报位置信息等。
● 在项目中，你们git是怎么使用的？怎么进行持续集成的？提交git后如何自动进行构建？
参考回答：我们项目中是使用GitFlow对项目代码进行管理的，代码推送到git服务后，会通知Jenkins中进行自动构建，方便测试人员进行测试。● master：发布上线时，基于master打tag，基于tag进行发布，不允许在该分支上开发，始终保持该分支的稳定。● develop：开发阶段使用的分支，提交到该分支代码都是相对稳定的，不能直接基于此分支开发，如果开发新的功能，需要基于此分支创建新的分支进行开发功能，待功能开发、测试通过后合并到develop分支。● Feature：新功能的开发，基于Develop分支创建Feature分支，功能开发完后合并到Develop分支，禁止未开发完成的代码合并到Develop分支。● Release：在Release分支中不再添加新的功能，只是做bug的修复，等测试完成bug全部修复之后，需要将Release分支合并到Master分支和Develop分支，并且基于Master打出版本的tag。● hotfix：如果发布到生成环境的版本出现bug，比如：生产环境的v1.0版本出现bug需要尽快修复，此时就需要基于master创建hotfix分支，并且基于hotfix分支修复bug，待bug修复完成后需要将代码合并到master和develop分支。
● 聊聊你们项目中的权限管家，它有什么用？为什么要这么做？
参考回答：我们项目中的权限管家，是一个集中的权限管理平台，该系统管理着公司内部的员工信息以及权限，它是基于RBAC权限管理模型设计的，通过设置角色来设置相应的权限。公司之所以开发一个这样的权限平台，主要是方便多个系统之间的可以共用这一套服务，避免重复开发用户权限功能。
● 你负责了哪个端的登录业务的开发？具体聊聊是怎么做的。
参考回答：此问题自行准备话术。
day02-用户端登录与统一网关
● 有对接过微信小程序登录吗？说说集成的流程？
参考回答：有的。我在物流项目中实现了用户端的登录，这个实现中集成了小程序登录，以及获取用户手机号的对接，小程序登录主要流程是前端获取登录code，将code传递到后端，后端再请求微信服务端，就可以获取到openid、unionid等信息，再将openid与自己的用户体系关联起来。获取手机号，在用户授权后获取到获取手机号code，通过此code再到微信服务端获取真实的手机号。
● 微信接口中的openid与UnionID有什么不同？你们是怎么用的？
参考回答：UnionID与openid最主要的区别在于，openid在一个应用中唯一，而UnionID是在一个开发者账号下唯一。
● 微信接口中的access_token你们有没有缓存？缓存时间是多少？假设access_token提前失效你该怎么处理？
参考回答：这个我们有做缓存的，微信官方也提示需要加缓存的，否则每次都获取access_token比较影响性能，我们设置的缓存时间是比它原有时间提前10分钟失效，这样有一定的余量时间进行获取新的access_token。假设access_token提前，这种情况是本地redis中的access_token未失效，但是在微信服务端已经失效，针对这种情况，我们将在发起微信请求后，对响应内容做解析，如果发现是access_token过期，就主动进行刷新，覆盖掉之前的数据，这样就可以确保access_token继续有效。
● 在项目中，用户登录成功后的token你们是怎么生成的？有效期是多久？有考虑过双token模式吗？谈谈你的想法。
参考回答：在我们项目中，用户登录成功后，我们是使用jwt生成token的，其中加密方式使用的是RSA非对称加密，并且我们用的是双token三验证的模式，会同时生成一对长短token，分别是access_token、refresh_token，时间分别是5分钟和24小时，当access_token失效后，前端会通过refresh_token进行刷新动作，会重新获取到一对长短token，依次往复。
● 如何让token提前失效？
参考回答：jwt生成的token是无状态的，无法进行提前失效，如果需要提前失效的话，就需要将token转化成有状态的，方法有很多，比如可以将token存入到redis中，并且设定有效期时间，需要提前将token失效的话，直接将redis中的数据删除即可。
● 说说统一网关中是如何进行认证与鉴权工作的？在网关中如何自定义过滤器？
参考回答：我们在网关中进行认证和鉴权工作，主要是校验请求头中的token是否有效以及请求用户是否具备允许访问的角色，通过角色来校验是否有权限。网关中自定义过滤器，主要是通过编写AbstractGatewayFilterFactory子类实现，其匹配规则是ManagerToken --> ManagerTokenGatewayFilterFactory。
● 项目中的用户权限是如何管理的？如何与权限管家对接？
参考回答：我们项目中的权限是通过对接公司内部的权限管理平台来实现的，我们是通过它提供的SDK进行对接的，就可以通过SDK中提供的类进行登录、查询角色等操作。
day03-运费微服务
● 你们的运费是怎么计算的？体积和重量怎么计算，到底以哪个为准？
参考回答：运费计算是通过【首重价格 + 续重 续重单价】 计算的。体积和重量是没办法直接比较的，我们会将体积转化成重量，这里要用到轻抛系数，用体积/轻抛系数就可以计算出重量，与实际的重量进行比较，取大值，进行运费计算。
● 详细聊聊你们的运费模板是做什么的？
参考回答：我所说的运费模板，实际上就是运费规则，我们定义了有同城、省内、经济区互寄、跨省，这四种类型的规则，其中保存了首重、续重、轻抛系数、模板类型、关联城市等字段。在计算运费时，需要根据收发件人的地址确定使用的模板，再根据模板中具体的值进行运费计算。
● 前面听你提到了责任链模式，能详细聊聊你们是怎么用的吗？为什么要这样用？
参考回答：我刚刚说的责任链模式是用在运费计算模块中，在运费计算时，首先需要查询运费模板，由于运费模板是有多种类型的，并且它们之间是有优先级的，同城 > 省内 > 经济区互寄 > 跨省，按照优先级选择符合条件的模板即可。这种场景下就比较适合使用责任链模式来做，如果第一种类型没有找到模板，就第二种类型进行查找，如果依然没有，就第三种.... 依次类推，最后由跨省模板兜底。
● 有没有针对运费计算做什么优化？
参考回答：有优化的。在之前的实现中，对于运费模板的查询是基于MySQL数据库完成的，这样性能比较差，组长要求我把运费模板存入到Redis中，查询时优先从Redis中进行查询，如果查询不到再查询数据库，从而提升了性能。
day05-路线规划之Neo4j入门
● 你所做的物流项目中，运输路线错综复杂，你们如何进行计算路线的？是距离优先还是成本优先？
参考回答：在我们物流项目中，采用Neo4j图数据库存储了机构、路线等数据，通过指定两个网点即可查询出相应的路线，路线的维度会有两个，分别是转运节点优先和成本优先，这两个维度我们都实现了，在系统中有全局的设定，根据这个设定来进行选择使用哪个维度进行路线规划。
● 为什么选择使用Neo4j图数据库存储路线？
参考回答：之所以选择Neo4j图数据库来存储路线，主要是以下两个原因：1、我们的业务模型与Neo4j的数据结构非常的像，都是节点以及节点之间的关系2、Neo4j支持深度查询，这样就可以查询任意指定的网点之间的路线
● 路线运输模型在Neo4j中是如何设计的？
参考回答：我们的路线运输模型，主要是开始网点 -> 二级转运中心 -> 一级转运中心 -> 一级转运中心 -> 二级转运中心 -> 结束网点。
● 在Neo4j中如何设置关系的查询深度？
参考回答：查询时，在关系中可以指定最小深度和最大深度，其中最小深度是可以省略的，格式：-[:TYPEminHops..maxHops]->
● 在SDN中如何自定义Cypher查询？可以直接定义JPA方法，为什么还要自定义查询？
参考回答：基于SpringData的规则只能实现一些基本的CRUD操作，一些复杂的操作就需要自定义查询了，比如：查询转运最少的路线等。
day06-路线规划之机构管理
● 你们项目的MQ的可靠性如何保障？分别说说发送和消费的可靠性保障。
参考回答：首先，我们使用RabbitMQ时，使用的队列是开启持久化的，这样确保服务宕机后，数据可以恢复。消息生产者：●消息发送到交换机，但是没有队列与此交换机绑定，此时我们的处理方案是记录日志，由人工进行处理●消息发送到交换机，但是交换机不存在，此时我们将消息在本地持久化，存储到MySQL表中，后续使用xxl-job进行补偿性的发送处理●由于服务器宕机或网络原因，导致不能连接到MQ服务器，此时发送消息会产生异常，我们将异常进行捕获，然后基于Spring-Retry机制进行重试，重试全部失败后将消息在本地持久化，存储到MySQL表中，后续使用xxl-job进行补偿性的发送处理消息消费者：●开启自动确认模式●消费失败进行重试，重试全部失败后，将消息发送到指定的error队列中，由人工进行处理
● 你们项目中的机构是如何管理的？为什么需要做数据同步？是怎么做同步的？
参考回答：我们项目中的机构的数据是与权限管家同步的，由于这是两套系统，所以我们采用MQ的方式进行同步，权限管家在数据变更时发出消息，我们微服务进行监听消息，对应的将数据同步写入到Neo4j中。
● 有设计过树形结构菜单的表结构吗？怎么设计的？
参考回答：有的。对于树形结构的表，主要是三个字段，分别是id、parentId、isLeaf，其中parentId标记该节点的父节点id，isLeaf标记是否有子节点。我们采用hutool工具包中的TreeUtil进行对树形结构进行构建，可以快速的构造出树形结构json数据。
● 项目中有使用过三方地图服务吗？你们是怎么用的？都用了哪些服务？
参考回答：有用过的。不过我们并没有直接使用三方的地图服务，而是采用公司内部的地图中台服务，可以非常方便的与三方地图服务对接起来，基本上简单的几行代码就搞定了。我有用过地理位置编码功能，就是将中文地址转化为经纬度坐标，我们用的坐标体系是gcj02，还有就是指定两个点坐标进行车辆导航的路线规划。
day07-线路规划之线路管理
● 你们物流项目中的路线规划是怎么做的？
参考回答：我们是基于Neo4j的深度查询实现的，通过指定发件人、收件人所在的网点，进行路线规划，我们实现了两个维度的规划，分别是最少转运节点和最低成本，这两种方式具体使用哪一种，是通过全局设定的参数来决定的。
● 如何确定路线的成本和距离？成本计算规则是什么？该成本会计算到公司利润核算中吗？
参考回答：关于路线的距离，我们记录的是实际距离，具体的实现是通过高德地图的接口查询到的，而成本的计算是通过全局设定的每公里的成本单价*距离计算出来的，该成本仅仅用于路线规划中的成本属性，并不是实际的成本，所以不能用于公司的利润核算。
● 对于路线的往返你们是怎么设计的？为什么成对创建的？
参考回答：关于路线的设计，我们是设计的往返路线，也就是在创建路线时成对创建，这是因为我们业务的特殊性，车辆从A点开往B点，后面是需要从B点回到A点的，不能跑空车，主要是公司成本的考虑、
● 路线支持修改起点或终点机构吗？请说明理由。
参考回答：不支持的。因为Neo4j中，关系是无法脱离节点存在的，如果需要修改某一个路线的起点或终点，可以先把原路线删除，再创建新的路线即可。
day08-作业范围微服务
● MongoDB存储的数据结构与MySQL存储的数据结构有什么区别？
参考回答：MongoDB与MySQL是不一样的，主要区别在于：●MongoDB属于非关系型数据库，由于底层基于分布式文件实现，所以支持海量数据的存储，MySQL是基于本地文件系统实现，无法支持海量数据存储，MySQL可以借助于分库分表技术实现。●MongoDB采用类似json的结构bson实现，更加的灵活，不要求每条数据的字段数量都一致，而MySQL采用传统的行列表格实现。●MongoDB的操作更像是是调用方法完成，而MySQL采用SQL语言实现。●MongoDB的优势在于单表操作，对于多表连接查询支持并不好，可以通过聚合函数实现，而MySQL天然的支持链表查询。
● 为什么会使用到MongoDB？MongoDB中如何存储坐标位置数据？如何实现附近的人查询？
参考回答：我们在实现作业范围时用到了MongoDB，因为作业范围实际上是一组坐标点数据，由这些坐标点组成的闭合的多边形，我们需要通过一个点查找是否在这个多边形的范围内，而MySQL是做不到这一点的，MongoDB就很容易能够实现，因为MongoDB支持地理空间坐标索引，并且支持的类型比较丰富。实现附近的人查询，主要的思路是，以当前用户的坐标点为圆心，查询距离为半径画圆，在MongoDB中查询这个圆形覆盖的数据，具体是使用NearQuery实现。
● 用户下单后如何确定为其服务的快递员？如何确定起点、终点的机构？
参考回答：用户下单后，根据发件人的详细地址获取到其经纬度坐标点，收件人详细地址获取到经纬度坐标点，然后根据这两个坐标点在作业范围中进行查询，即可查询到服务范围内的快递员和机构。
● 作业范围如果不使用MongoDB，还可以使用其他技术实现吗？
参考回答：不使用MongoDB的话，还可以通过Elasticsearch实现，但是Elasticsearch更擅长全文索引，实现搜索功能，虽然也能实现，但是在作业范围这个功能中使用MongoDB更适合一些。
day10-智能调度之分配快递员
● 你简历中写的调度中心是什么意思？它有什么用？为什么要设计调度中心？
参考回答：我们物流项目中的调度中心，主要是完成快递员、司机、车辆的调度工作，比如：用户下单后哪个快递员上门取件，就需要经过调度中心进行计算，给快递员分配取件任务，也就是说调度中心主要就是计算一些核心的业务逻辑，重点在于通过计算完成资源的调度工作。
● 你们物流项目核心的业务逻辑你了解吗？能画一下吗？这个是你设计的吗？你都参与哪些业务模块的开发？
参考回答：我们物流项目中的核心业务逻辑我是了解的，虽然这个不是我设计的，但是我参与了一些业务的开发，我主要是参与的快递员任务分配的开发，就是用户下单之后选择在服务范围内，有排班并且当日任务量最少的那个快递员进行分配。
● 用户下单后，是如何确认上门取件的快递员的？如果有多个快递员怎么处理？怎么做到均衡分配任务的？
参考回答：我们是通过发件人的详细地址可以确定去经纬度坐标，通过这个坐标数据就可以定位到服务范围内的快递员，如果有多个快递员我们就计算他们的快取件任务量，优先分配最少任务量的快递员，这样就可以达到均衡分配任务的效果。
● 生成取件任务，为什么会用到延时队列？
参考回答：这个是产品经理在产品上的定义。就是用户期望上门时间与当前时间超过预定的时间（如2小时），就暂时不给快递员下发取件任务，这个时候就需要使用延迟队列，等到达预定时间再下发任务。
● 生成取派件任务为什么不在work中直接生成，而是发消息到调度中心，再发消息到work中？
参考回答：因为调度中心是计算中心，所以需要先通过调度中心进行计算，将计算的结果下发给work微服务进行任务的生成，而work微服务是不具备计算能力的，只能有存储的处理能力，所以需要新订单的消息先发到调度中心，经过处理后再发给work微服务。
day11-智能调度之取派件任务
● 系统分配取件任务后，如果快递员不能上门取件，你们是怎么处理的？有几个情况需要考虑？
参考回答：分配给快递员的取件任务，如果快递员不能上门取件，快递员就需要进行取消操作，如果快递员取消必须要选择【取消原因】，系统会根据不同的【取消原因】做不同的处理，比如取消原因是【退回到网点】就需要系统重新调度，重新下发取件任务，如果是【用户取消】就将订单进行取消操作，其他原因就将订单关闭。
● 你们系统中的，订单和取派件任务是什么关系？是一对一的吗？怎么设计的？
参考回答：我们设计的订单与取派件任务是一对多的关系，也就是说一个订单可能会对应多个取派件任务，因为有些任务分配给A快递员后，A不能完成任务，需要系统重新分配，这个时候就会产生多个取件任务。派件任务也是一样的道理，所以是一对多的关系。
● 派件任务是在什么时候生成的？快递员可以取消派件任务吗？为什么？
参考回答：派件任务是在快递到达目的地网点时，系统会生成派件任务，快递员是不能自己取消派件任务的，如果需要需求就需要在后台系统中完成，主要是考虑到不能放快递员私自取消，避免无快递员愿意派件的情况，因为一般派件的提成比取件要低。
● 项目中有用到分布式事务吗？在什么场景下用的？具体怎么用的？
参考回答：有用到。我们是在快递员上门取件后，点击【取件】操作用到了，我们是使用Seata框架实现的，主要是在取件的方法上加了@GlobalTransactional注解，这样就开启分布式事务，起到了全局事务的作用，确保了跨多个微服务更新操作时，可以做到同时成功或失败。
day12-智能调度之运单调度
● 物流项目中你参与了核心的功能开发吗？能说一下核心的业务逻辑吗？
参考回答：我在物流项目中参与了部分核心功能的开发，比如在智能调度中我参与了【订单转运单】的业务开发。订单转运单是在快递员取件成功后，将订单转为正式的运单，也就意味着即将开始真正的运输，在生成运单编号时我们采用了美团Leaf来生成自增长的单号，并且性能方面有保障。在实现中，使用消息与其他微服务交互，并且确保了接口的幂等性。
● 你们的运单号是怎么生成的？如何确保性能？
参考回答：运单号采用了美团Leaf来生成自增长的单号，美团Leaf是一个开源的高性能的ID生成服务，其底层采用双buffer模式确保了性能。双buffer的方式：Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。
● 能说一下订单转运单的业务逻辑吗？生成运单后如何与调度中心整合在一起的？
参考回答：订单转运单是在快递员取件成功后，将订单转为正式的运单，也就意味着即将开始真正的运输。生成运单后与调度中心整合，我们采用的是MQ消息的方式进行整合的。
● 合并运单为什么使用Redis的List作为队列？如何确保消息的幂等性的？
参考回答：之所以选择使用Redis得List作为队列，是因为我们需要一个高性能的、先进先出的队列，所以使用Redis是不错的选择，具体实现的时候，我们采用的左进右出。为了确保运单处理的幂等性，我们采用Redis的set结构存储该队列中对于的运单，将运单加入队列时，先经过set集合进行判断是否存在，如果存在就不加入，否则才加入。
day13-智能调度之运输任务
● 能说一下xxl-job的分片式调度是在什么场景下使用的吗？这样做的好处是什么？
参考回答：一般使用xxl-job的分片式调度，是需要并行处理大量数据或任务时用到，使用分片式调度的好处就是充分利用分布式资源，多台服务器并行执行任务，并且确保数据的不重复处理。
● 有用过分布式事务吗？你们是怎么用的？用在什么场景？
参考回答：有用到。我们是在快递员上门取件后，点击【取件】操作用到了，我们是使用Seata框架实现的，主要是在取件的方法上加了@GlobalTransactional注解，这样就开启分布式事务，起到了全局事务的作用，确保了跨多个微服务更新操作时，可以做到同时成功或失败。
● 不同的运单流转节点是不一样的，你们如何将运单合并？如何确保redis的高可用？
参考回答：在合并运单实现中，我们将运单存入到待处理的队列中，待处理的队列采用Redis的List实现，key为：当前机构id+下一个机构id，采用左进右出的方式将运单数据存入到队列。redis的高可用我们一般优先采用redis的主从架构+哨兵模式，如果数据量大的情况下，会考虑使用redis集群模式。
● 你们系统中，车辆、车次和路线之间是什么关系？车辆有司机数量限制吗？
参考回答：车辆、车次和路线之间的关系是这样的，在一条路线上可以绑定多个车次，每个车次可以绑定一个车辆，每个车辆必须至少两个司机，并且司机的基本信息必须的完善的。
day14-物流追踪信息微服务
● 你们项目中的物流信息那块存储是怎么做的？为什么要选择MongoDB？
参考回答：如果采用MySQL实现的话，MySQL存储在一张表中，每条物流信息就是一条行数据，数据条数将是运单数量的数倍，查询时需要通过运单id作为条件，按照时间正序排序得到所有的结果，而MongoDB存储基于其自身特点可以将物流信息列表存储到属性中，数据量等于运单量，查询时只需要按照运单id查询即可。所以，使用MongoDB存储更适合物流信息这样的场景，我们将基于MongoDB进行实现。
● 针对于查询并发高的问题你们是怎么解决的？有用多级缓存吗？具体是怎么用的？
参考回答：我在物流信息业务实现中解决过该并发的问题，由于业务的特点，用户查询的数据是具备一定的时效性的，并且物流信息更新的也不频繁，所以，我采用了多级缓存的解决方案来应对高并发，我在第一版本的实现中，将caffeine作为一级缓存，redis作为二级缓存，如果一级缓存能够命中就返回数据，否则进行二级缓存的命中，最终兜底的是MongoDB。
● 多级缓存间的数据不一致是如何解决的？
参考回答：多级缓存间的数据不一致问题，在我开发过程中有遇到过的，我的解决方案是通过Redis的发布订阅功能实现，具体是在更新二级缓存时向redis发出消息，所有的服务节点都监听该队列，所有的服务节点就会收到更新的消息，然后将自身一级缓存中的数据删除即可。
● 来，说说在使用Redis场景中的缓存击穿、缓存雪崩、缓存穿透都是啥意思？对应的解决方案是啥？实际你解决过哪个问题？
参考回答：缓存击穿是指，某一热点数据存储到redis中，该数据处于高并发场景下，如果此时该key过期失效，这样就会有大量的并发请求进入到数据库，对数据库产生大的压力，甚至会压垮数据库。缓存雪崩的情况往往是由两种情况产生：● 情况1：由于大量 key 设置了相同的过期时间（数据在缓存和数据库都存在），一旦到达过期时间点，这些 key 集体失效，造成访问这些 key 的请求全部进入数据库。● 情况2：Redis 实例宕机，大量请求进入数据库缓存穿透是指，如果一个 key 在缓存和数据库都不存在，那么访问这个 key 每次都会进入数据库● 很可能被恶意请求利用● 缓存雪崩与缓存击穿都是数据库中有，但缓存暂时缺失● 缓存雪崩与缓存击穿都能自然恢复，但缓存穿透则不能
我实际解决了缓存穿透的问题，主要是应用布隆过滤器解决，在进行缓存命中之前先进行布隆过滤器的判断，如果不存在直接返回，如果存在再进行缓存命中。
● 说说布隆过滤器的优缺点是什么？什么样的场景适合使用布隆过滤器？
参考回答：布隆过滤器的优缺点：● 优点 ○ 存储的二进制数据，1或0，不存储真实数据，空间占用比较小且安全。 ○ 插入和查询速度非常快，因为是基于数组下标的，类似HashMap，其时间复杂度是O（K），其中k是指哈希算法个数。● 缺点 ○ 存在误判，可以通过增加哈希算法个数降低误判率，不能完全避免误判。 ○ 删除困难，因为一个位置可能会代表多个值，不能做删除。布隆过滤器适合判断数据一定不存在，不适合判断一定存在的场景。
