【ReactJs+springBoot项目——租房】第8章：RocketMQ错误消息重试+RocketMQ的集群搭建+SpringBoot整合RocketMQ+分布式WebSocket +地图找房

【ReactJs+springBoot项目——租房】第8章：RocketMQ错误消息重试+RocketMQ的集群搭建+SpringBoot整合RocketMQ+分布式WebSocket +地图找房

RocketMQ的错误消息重试策略RocketMQ的集群搭建SpringBoot整合RocketMQ实现分布式的WebSocket 实现地图找房功能

1、重试策略

在消息的发送和消费过程中，都有可能出现错误，如网络异常等，出现了错误就需要进行错误重试，这种消息的重 试需要分2种，分别是producer端重试和consumer端重试。 1.1、producer端重试 生产者端的消息失败，也就是Producer往MQ上发消息没有发送成功，比如网络抖动导致生产者发送消息到MQ失 败。

1.2、consumer端重试

消费者端的失败，分为2种情况，一个是exception，一个是timeout。

1.2.1、exception

消息正常的到了消费者，结果消费者发生异常，处理失败了。例如反序列化失败，消息数据本身无法处理（例如话 费充值，当前消息的手机号被注销，无法充值）等。

消息的状态：

可以看到，消息的状态分为成功或者失败。如果返回的状态为失败会怎么样呢？ 在启动broker的日志中可以看到这样的信息：

这个表示了，如果消息消费失败，那么消息将会在1s、5s、10s后重试，一直到2h后不再重试。

其实，有些时候并不需要重试这么多次，一般重试3~5次即可。这个时候就可以通过msg.getReconsumeTimes()获 取重试次数进行控制。

1.2.2、timeout

比如由于网络原因导致消息压根就没有从MQ到消费者上，那么在RocketMQ内部会不断的尝试发送这条消息，直 至发送成功为止！

也就是说，服务端没有接收到消息的反馈，既不是成功也不是失败，这个时候定义为超时。

2、RocketMQ的集群

2.1、集群模式 在RocketMQ中，集群的部署模式是比较多的，有以下几种：

单个Master 这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用，不建议线上环境使用。 多Master模式 一个集群无Slave，全是Master，例如2个Master或者3个Master 单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。 多Master多Slave模式，异步复制 每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟，毫秒 级。 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master宕机后，消费者仍然 可以从Slave消费，此过程对应用透明，不需要人工干预。性能同多Master模式几乎一样。 缺点：Master宕机，磁盘损坏情况，会丢失少量消息。多Master多Slave模式，同步双写 每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，主备都写成功，向应用返回 成功。 优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高。 缺点：性能比异步复制模式略低，大约低10%左右。 2.2、搭建2m2s集群 下面通过docker搭建2master+2slave的集群。

3、SprinBoot整合RocketMQ

3.1、导入依赖

说明：rocketmq-spring-boot-starter的依赖包是不能直接从中央仓库-的，需要自己通过源码install到本地仓库的。

3.2、编写application.properties配置文件

3.3、生产者发送消息

3.4、消费消息

3.5、编写启动类

3.6、编写测试用例

3.7、测试 先启动springboot，再运行测试用例，即可看到消费者接收到生产者发送的消息。 3.8、事务消息 3.8.1、定义TransactionListenerImpl

3.8.2、定义生产者

3.8.3、消费者（没有变化）

3.8.4、编写测试用例

3.8.5、测试 测试结果与非Spring使用，结果一致。

4、实现分布式WebSocket

4.1、实现方案

4.2、导入RocketMQ相关依赖

4.3、添加SpringBoot配置

4.4、实现

Message对象添加ObjectId的注解：

4.5、测试

可以看到，1003接收到了1001发来的消息，说明消息系统已经发挥了作用。

5、地图找房完善项目的功能，实现地图找房功能，效果如下：

5.1、前端实现

地图使用的是百度地图api，具体代码实现：

可以看到，目前的数据是静态的，需要改造成加载后台数据的方式。

5.2、改造数据的加载方式

5.2.1、修改数据的加载逻辑

5.2.2、编写graphql接口

编写MapHouseDataResult、MapHouseXY：

编写MapHouseDataFetcher

5.2.3、整合测试

5.3、增加拖动事件

在地图拖动后，增加事件，获取中心位置的坐标，以便后续的查询。

测试：

百度地图缩放比例：

5.4、传递经纬度以及缩放比例参数

查询数据的原理图示：

说明：中心点坐标的外围1.5倍缩放比例的范围是查询范围。修改GraphQL定义：

测试查询：

查询结果：

优化前端代码：

5.5、MongoDB的地理位置索引 在MongoDB中，支持存储位置的经纬度，可以对其索引，通过算子操作，进行查找附近的数据。如：查找附近的 人、附近的餐馆等。 我们可以用此特性，存储房源的位置数据以及进行地图找房查询。

5.6、实现基于MongoDB的查询

5.6.1、导入依赖

5.6.2、添加配置

5.6.3、编写实现代码

编写pojo：

编写MongoHouseService：

修改MapHouseDataFetcher：

5.7、测试

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。