@skypyb 你说的是 rabbitmq_delayed_message_exchange 插件吗，这个插件用起来是很方便，不是我试过之后感觉有几个问题
1.延迟时间类型是 int，最大只能支持 24.8 天，后面的小数点被我省略了。
2.关于迁移，如果换服务器怎么办，只把队列迁移过去原来的延迟时间还在不在，因为看到作者在 github 写的
You can disable this plugin by calling rabbitmq-plugins disable rabbitmq_delayed_message_exchange but note that ALL DELAYED MESSAGES THAT HAVEN'T BEEN DELIVERED WILL BE LOST. 即把插件关闭所有尚未传递的延迟消息将丢失
3.作者说插件设计不支持十万百万场景，因为有人用这个插件支撑了太多延时队列导致延迟时间会更久，提了 issue，Current design of this plugin doesn't really fit scenarios with a high number of delayed messages (e.g. 100s of thousands or millions). See #72 for details.
所以我想问一下你们的生产环境用的是这个吗，有出现上述的问题吗，或者换了什么解决方案吗

@Breadykid 请问一下帖主最后是怎么解决的？

@liumyao
我的结论：注入的是代理对象。如果有错误，麻烦和我说一下，感谢

楼主，我在 springboot 中测试了一下，用的是 cglib，controller 调 service，使用 AopContext.currentProxy()打断点，发现当前代理类是 controller 的 cglib 代理类。
然后关键是我的 servic 中的方法 A 调用 同一 service 中的方法 B，
service{

public A(){
this.B();
}

@Transactional
public B(){
}
此时方法 B 的注解失效

然后我看了一篇文章，链接为 https://my.oschina.net/guangshan/blog/1807721
说 this 调用的不是代理类中的方法，可以使用 applicationContext.getBean(service.class),在用这个 bean 调用方法 B 可以解决，所以可以判断注入的是代理对象，但是 this 调用原来的本类实例的方法
但是我的问题是 ioc 容器中存放的是代理类实例还是原本的类的实例 ？
我上面文章的链接是说代理类中有原本类实例，导致 this 调用了原来的没有增强过的方法

@eefnrowe
你的问题:如果没有加 lockUser 锁的情况下
doUnpack 逻辑有问题。
你只把红包锁住，一个用户的 2 次并发访问，在你的逻辑中，可能都运行到 if(redisTemplate.hasKey(userIdsKey))
都没有 userIdsKey，所以加了两条，
当你在 redisson 中加上用户锁时，一个用户的两次并发请求就不会运行到下面的代码了

我反而有一个问题，在 redisson 的官方文档中
https://github.com/redisson/redisson/wiki/8.-%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E5%92%8C%E5%90%8C%E6%AD%A5%E5%99%A8
你在 lock 时

// 加锁以后 10 秒钟自动解锁 官方解释
// 无需调用 unlock 方法手动解锁 官方解释
rLock.lock(10, TimeUnit.SECONDS);

这句代码官方解释是 10 秒后自动解锁,这样的话如果你的业务代码大于 10 秒或者因为某些原因等待超过 10 秒，会不会导致锁被释放掉，锁失效。
所以我感觉不加时间才是对的，除非你业务需要

一个简单的例子
mp.mp_name 改成 max(mp.mp_name) as mp_name
其他字段也相同。
因为我们这边也不给改 sql_mode,所以搜索出来的方法,亲测可用，因为聚合函数没有不许放到 group by 后面的限制
不过要注意你的 max(field)中的字段的内容是否相同，我这边都是相同的，如果不一样,max(field)会拿最大的,需要注意一下
详细可以看官网文档的 group by 部分 https://dev.mysql.com/doc/refman/8.0/en/group-by-handling.html
我看的 8.0 文档，你换成自己版本就好了