734695609 最近的时间轴更新 734695609 最近的时间轴更新 |
734695609V2EX 第 297654 号会员，加入于 2018-03-07 14:01:04 +08:00今日活跃度排名 13073 |
734695609 最近回复了
2021-03-09 09:18:05 +08:00 回复了 babyrjw 创建的主题 › 程序员 › beanstalked 性能 |
@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.
所以我想问一下你们的生产环境用的是这个吗，有出现上述的问题吗，或者换了什么解决方案吗
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.
所以我想问一下你们的生产环境用的是这个吗，有出现上述的问题吗，或者换了什么解决方案吗
2020-06-01 14:52:37 +08:00 回复了 Breadykid 创建的主题 › 程序员 › 跨库的数据库事务回滚操作 |
@Breadykid 请问一下帖主最后是怎么解决的？
2020-04-07 16:48:41 +08:00 回复了 liumyao 创建的主题 › Java › 关于 jdk 动态代理的一点疑问 希望大佬们能解答一下 万分感谢 |
@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 调用了原来的没有增强过的方法
我的结论：注入的是代理对象。如果有错误，麻烦和我说一下，感谢
楼主，我在 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 调用了原来的没有增强过的方法
2019-09-12 16:13:58 +08:00 回复了 eefnrowe 创建的主题 › Java › 关于使用 redisson 分布式锁出现的问题 |
@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 秒，会不会导致锁被释放掉，锁失效。
所以我感觉不加时间才是对的，除非你业务需要
你的问题:如果没有加 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 秒，会不会导致锁被释放掉，锁失效。
所以我感觉不加时间才是对的，除非你业务需要
2019-06-03 11:11:38 +08:00 回复了 lyzy 创建的主题 › MySQL › mysql5.7 开启 only_full_group_by 如何修改 sql 语句 |
一个简单的例子
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 文档，你换成自己版本就好了
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 文档，你换成自己版本就好了
2018-12-12 01:30:50 +08:00 回复了 ppy 创建的主题 › 程序员 › 请教关于 CORS 中 Access-Control-Allow-Credentials 的问题 |
@cfy 同一 IP 的不同端口也是跨域的。
针对你的这句话：而我访问已经上线的前端页面时，因为前后端都是部署在同一个 host 上的所以不存在跨域的问题。
针对你的这句话：而我访问已经上线的前端页面时，因为前后端都是部署在同一个 host 上的所以不存在跨域的问题。
Select Language