Spring Boot中MongoDB、Redis、RabbitMQ更新统计数据的最佳实践探讨

我正在构建基于Spring Boot、MongoDB、RabbitMQ和Redis的应用，用于跟踪并更新设备统计数据（如OS版本、设备类型）。

当前实现方案 #

• 设备数据立即存入MongoDB的devices集合；
• 将stats集合更新事件发送至RabbitMQ；
• 消费者处理事件并立即更新MongoDB的stats集合；
• 更新MongoDB后刷新Redis缓存。

考虑的替代方案 #

• 事件处理完成后立即更新Redis；
• 定期将Redis数据批量同步至MongoDB（如每日结束时）。

核心疑问 #

1. 先更新MongoDB再更新Redis是否属于最佳实践？
2. 是否有开发者采用上述替代方案？

DEVICE REGISTER 代码：

fun updateUser(request: UserUpdateRequest): BaseResponse {
    val device = Device(
        deviceUuid = request.device.deviceUuid,
        deviceBrand = request.device.deviceBrand?.lowercase(),
        deviceModel = request.device.deviceModel?.lowercase(),
        osName = request.device.osName?.lowercase(),
        osVersion = request.device.osVersion,
        appVersion = request.device.appVersion,
        sdkVersion = request.device.sdkVersion,
        userUuid = request.userUuid,
        lastUpdated = LocalDateTime.now())

    deviceRepository.save(device)
    //PUBLISH TO RABBITMQ FOR STATS COLLECTION UPDATE
    deviceEventProducer.sendDeviceEvent(device)
    SuccessResponse ("User created successfully")
}

HANDLE DEVICE STATS UPDATE EVENT 代码：

@Service
class DeviceEventConsumer(
    private val customStatsRepository: CustomStatsRepository
) {

    @RabbitListener(queues = ["deviceEventsQueue"])
    fun handleDeviceEvent(message: DeviceEventMessage) {
        println("handleDeviceEvent() -> device: $message")

        val merchantId = message.merchantId ?: return
            customStatsRepository.incrementOsStats(merchantId, message.device.osName!!)
            customStatsRepository.incrementOsVersion(merchantId, message.device.osVersion!!)
            customStatsRepository.incrementDeviceDetails(
                merchantId,
                message.device.deviceBrand!!,
                message.device.deviceModel!!
            )
        customStatsRepository.updateLastUpdated(merchantId)
    }
}

一、先更新MongoDB再更新Redis是否属于最佳实践？ #

这种先更新持久化数据库（MongoDB），再刷新缓存（Redis）的方式属于典型的写穿（Write-Through）缓存模式，是缓存与数据库一致性场景下的主流最佳实践之一，核心原因如下：

• 数据一致性优先：MongoDB作为持久化数据源，是业务数据的"唯一可信源"。先更新它能保证即使缓存刷新失败，核心统计数据依然准确；后续刷新缓存仅为加速读取，即使缓存更新出问题，读取请求也可降级到MongoDB获取正确结果。
• 避免脏数据风险：如果反过来先更新缓存再更新数据库，若中间服务崩溃或数据库更新失败，会导致缓存中存在数据库未持久化的"脏数据"，后续读取会出现数据不一致的问题。
• 适配业务场景：设备统计数据属于聚合类业务数据，通常需要保证统计结果的准确性，写穿模式能很好匹配这种对数据一致性要求较高的场景。

结合你当前的异步解耦流程（设备写入MongoDB → 发RabbitMQ事件更新统计 → 更新MongoDB后刷Redis），这个逻辑是合理的，既通过消息队列实现了核心业务与统计业务的解耦，又通过写穿模式保障了统计数据的一致性。

二、替代方案是否有开发者采用？ #

你提到的先更新Redis，定期批量同步到MongoDB的方案属于写回（Write-Back）缓存模式，确实有不少开发者在特定业务场景下采用，这类场景通常具备以下特征：

• 高并发写入需求：Redis的内存操作性能远高于MongoDB，适合处理海量设备统计的增量写入，能有效降低数据库的写入压力。
• 可接受短期数据滞后：允许MongoDB中的统计数据比Redis滞后一段时间（如你说的每日同步），业务上不需要实时查看持久化后的统计数据。
• 数据丢失风险可承受：如果Redis故障，未同步到MongoDB的增量数据会丢失，若你的业务可以通过重新计算devices集合的数据恢复统计结果，或者能接受少量数据丢失，这个方案是可行的。

但该方案也存在明显局限性：

• 数据一致性风险：Redis与MongoDB会存在窗口时间内的数据不一致，若有业务需要同时从两个数据源读取数据，会出现结果差异。
• 同步复杂度高：需要处理批量同步时的冲突、重试、幂等性问题，比如避免重复同步同一增量数据，否则会导致统计结果失真。

内容的提问来源于stack exchange，提问作者Ozgur Baykal