● 你们项目的MQ的可靠性如何保障？分别说说发送和消费的可靠性保障。
● 你们项目中的机构是如何管理的？为什么需要做数据同步？是怎么做同步的？
● 有设计过树形结构菜单的表结构吗？怎么设计的？
● 项目中有使用过三方地图服务吗？你们是怎么用的？都用了哪些服务？
一.
通过保障生产者的可靠性，MQ的可靠性，消费者的可靠性。
可以通过生产者重试机制保障消息发送的可靠性。
但是这种方式是阻塞式的，所以会导致业务性能降低，不适合用在高性能业务中。
如果业务对性能要求没有那么高，可以控制重连时长，或者采用异步线程的方式，来合理使用生产者重试机制
我们选择了通过生产者确认机制保障发送的可靠性。
生产者发送消息给交换机，交换机会根据情况返回结果给生产者。
如果生产者返回ack且没有返回异常信息，证明消息发送成功。
如果生产者返回ack且返回异常信息，则证明mq接收到消息，但是消息在mq中丢失。
其余情况返回nack
生产者确认机制包括两大核心，分别是Publisher confim和Publisher return
我们通过重写returnCallback返回回调中实现mq对不同处理结果的返回，该返回是逻辑高一致性的，所以通过配置类实现
我们通过重写comfirmCallback确认回调来编辑确认结果之后的逻辑，因为不同业务逻辑存在差异，所以我们通过参数的方式传递该重写。实现相应的逻辑
为了保障消费者消费的可靠性，我们采用了消费者确认机制。
当消费者处理消息之后，会返回ack，nack，或者reject。
如果返回ack，代表消费成功，mq删除消息。
如果返回nack，代表消费失败，mq重新将消息发送到对列中或者进入死信队列。
如果返回reject，代表消费失败，且消费者拒绝处理该消息。
极端情况下，如果一值返回nack，一值处理失败，那么会降低业务性能。
所以我们采用消息在消费者本地重试的机制，如果最大重试次数内重试成功，则返回ack，否则就返回nack或者reject。
对于reject的消息，我们直接丢失吗？
我们可以将其加入死信队列，进行人工处理。
二.
通过权限管家，也就是服务中台。服务中台就是将服务化的逻辑抽取出来，采用RBAC权限控制模型，我记得jeecgboot也是采用的这种模型实现的权限控制，因为许多服务都需要用到机构管理。
通过mq实现数据同步。当在服务中台新增或者修改机构时，消息会推送到mq中，然后mq判断消息类型是否属于机构相关，然后提取里面的操作内容和操作类型，进行一系列crud操作。
三.
通过关联外键进行设计，比如让表中出现id，和父id，当然顶级菜单的父id为0，然后通过Huttoo工具包中的TreeUtil工具类实现。
四.
这一模块不是我实现的。