标签：一个队列 进程 处理 异常 有一个 rpo 业务逻辑 提交 处理过程
简使用pop，不能保证最少消费一次，比如pop超时可能中途丢失，或者消费者处理过程中异常而未能处理完。
解决此问题有多种方法：
1) 方法一：使用rpoplpush替代pop
这种方法相当于建立了一个回滚，由于操作是在redis端完成的，可保证数据不会丢，当消费者完成业务逻辑后，再清掉lpush的另一队列，这步有点类似于事务的commit提交。如果在处理过程中消费者异常重启，则在重启时先检查lpush的队列，完成处理后再清lpush的队列。
2) 方法二：使用lrange+ltrim替代pop
消费时先lrange拿到数据，处理完后再使用ltrim清掉已处理的数据（这步也类似于事务的commit提交）。
不过这里存在一个缺陷：同时只能有一个消费者，不能多线程多进程和多机器同时处理同一个队列，因此消费者存在单点问题，基于Zookeeper等来解决单点有些重，而且在切换会有些延迟，存在短暂停顿问题。
3) 方法三：使用eval(lua)+lrange+ltrim替代pop
站在redis端，list可看作是一个本地队列，借助eval+lua，可实际这个转换。既然是本地队列，则可轻松的实现多消费者并发消费（本质是串型的），通过lua取list中的数据，并维护list数据的移动。
第一步是lua方式取得数据，并更新消费偏移；第二步是lua方式提交更新（也类似于事务的commit提交）。
上述三种方法，方法二缺陷明显。而方法一如果消费者在提交前挂掉，另lpush队列中的数据需要另外处理。方法三相对好维护，即使消费者在提交前挂掉，另外的消费在提交时可以帮助解决消费位置移动（实际是调用ltrim）问题。
当然由于redis的主节点和复制节点间是异步复制，该机制存在的丢数据问题无法通过上述三个方法来解决。
标签：一个队列 进程 处理 异常 有一个 rpo 业务逻辑 提交 处理过程
原文地址：https://www.cnblogs.com/aquester/p/11442367.html
