RT,业务场景需要,从channel读出数据后,如果处理失败,需要把数据再丢入channel,再处理。但是因为数据有一定的顺序(不能把失败的数据写到channel的尾部),所以我再把失败的数据丢入channel准备重试的时候,需要丢到channel的头部,然后再读出来进行重试
有疑问加站长微信联系(非本文作者)

RT,业务场景需要,从channel读出数据后,如果处理失败,需要把数据再丢入channel,再处理。但是因为数据有一定的顺序(不能把失败的数据写到channel的尾部),所以我再把失败的数据丢入channel准备重试的时候,需要丢到channel的头部,然后再读出来进行重试
有疑问加站长微信联系(非本文作者)
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
`单行代码`
用2 个channel组合出来一个你的要求就好了
一个是优先被读取,常态是空的;一个是被正常的读取。 如果处理失败的化插入第一个就可以了。
可是 你确定重试就会成功了?要是一直失败了 是不是就阻塞了? 阻塞了 内存是不是会暴涨? 。cpu会不会都浪费在重试上了,导致正常的请求没有时间处理?。。。
所以你这个前提就有问题?
要是一直重试失败,那只好把这个数据丢弃了,还能有啥办法?
好办法
这不是rmq消费确认的场景?
正规的消息中间件都会提供确认机制,但这不因为redis快嘛,所以想用redis做消息队列
不成功又要重新处理,那不是死循环了,其它正常的数据永远都处理不到,
这个,貌似仅仅chan实现不了,可以用队列。但是如果 仅仅失败 立即重试没必要还放进chan中,从chan中取出了,创建个goroutine处理好了。如果是稍后重试,放进chan中(题住的尾部) 恰好合适。
可以有重试机制 但是不能无限制重试,重试几次还失败 应该有后续处理,比如报警人工干预,或者以日志的形式保留下来看下 为什么失败 想办法优化下
错误这里应该直接 在函数内部处理,直接重试几次,不行就写入日志,不应该用CHAN来控制错误机制。在有一点,第一次错,不代表第二次就正确了,一般CHAN都是有数量限制的,错的多了,chan里就没有正确的了。。 应该像1楼那样,要不两个,要不就像9楼那样,别有可遇见性错误。