问一个并发上座的问题？

Question

问题描述

我是用 hash 表来表示座位上的人的（ key 表示座位位置，value 就是具体的 uid ），然后用 hsetnx 处理并发上座，
但是有个问题是，在上座成功后，我要把这条信息投递到消息队列里去（为了通知客户端），但是这里可能有网络原因（或者其他原因），
导致投递失败，但是 redis 又没有事务，没办法回滚，这样就会出问题，不知道大家有什么好思路，冒昧请教下。
伪代码类似于：

res =  cache.setnx(pos, uid)
if (!res) {
    throw new Exception('上座失败！')
}
mq.send({
    pos: pos,
    uid: uid,
    time: new Date()
})

Answer 1

消息队列本身就是解耦的，如果投递失败就回滚那就相当于强依赖了？

Answer 2

还是需要结合具体场景来看这个问题。

1. 操作之前，对数据做好检验工作。尽可能保证后面的失败都是由网络引起的。
2. 考虑对消息投递做重试处理。如果第一次投递失败，那么延迟2S，继续投递。如果还失败，延迟4S进行投递......设置一个重试上限，另外对重试过程追加日志输出，最好能加上报警。如果最后依旧失败的话，手工介入处理。这样的补偿，可以考虑新起goroutine异步处理就可以了。
3. 如果必须对redis回滚的话。你可以考虑，自己对整个处理过程加锁，保证map中key的值不被别的请求修改掉。当投递失败之后，删除redis中的数据。而且删除前一定要对删除的数据进行判断，保证删除的一定是自己写入的。
4. 延续3的话题，你可以看一下redis的set命令是否合适：SET key value [expiration EX seconds|PX milliseconds] [NX|XX]。不仅实现了setnx的功能，同时还加上了过期时间。跟map唯一的区别就是没有统一管理key值。
5. 考虑使用MySQL事物替换。数据表创建4个字段，主键ID，key，value，status。设置key为唯一索引。第一次INSERT插入数据也能模拟SETNX的操作。

仅供参考，需要结合实际需要来处理

Answer 3

既然是担心网络问题，我们在投递消息的时候如果投递失败（可以利用rabbitmq的confirm模式），就将消息存到本地，然后起一个定时任务，定期将未投递成功的消息再次投递，直到投递成功为止（保证最终一致性）。

res =  cache.setnx(pos, uid)
if (!res) {
    throw new Exception('上座失败！')
}
mq.confirmSelect();
mq.send({
    pos: pos,
    uid: uid,
    time: new Date(),
    confirmCallback：function() {
        //将没有投递成功的消息存到本地
    }
})