在进一步深入讲解这些用例把背后的的诉求前，说明一下客户端开启ACL是指在构建消息发送者、消息消费者时，传入与ACL相关的参数，截图如下：
接下来逐步分析上述测试用例的目的。
2.1 客户端不开启ACL，服务端开启ACL
例如像我们公司的技术架构，涉及到数据的流转，重度依赖MQ，目前应用中存在太多的低版本的MQ客户端，例如4.1.0，如果服务端开启了ACL，如果能兼容低版本客户端，那这样升级起来就会显得非常容易，但经过测试：结果为不兼容。其实这个也好理解，服务端开启了ACL，客户端没有授权信息，是肯定不会让你通过的。
2.2 客户端开启ACL，服务端不开启ACL
经过测试，服务端如果不开启ACL的话，尽管客户端在消息发送、消息消费等场景下发送了授权信息，但服务端会忽略这些信息，并不会触发ACL校验。
基于开源版本，通过上面的验证，其优雅升级思路：为各个客户端规划好用户名与密钥,并且对所有客户端进行改造，等待所有客户端都完成改造后，服务端再开启ACL。
通常在具体实践中，由于涉及所有客户端改造，可以分集群进行改造，由上到下推动该事项的执行，统一定好一个客户端改造的最后时间点，在该时间点后，服务端开启ACL，至此完成RocketMQ集群的授信访问。、
上述方案的缺点也是显而易见的，需要客户端先行改动，只有等所有客户端全部改造完成后，服务端才能开启ACL。
由于当时项目的升级的迫切性，基于官方版本这种升级方案显然无法满足我们当时的需求。回到文章开头部分说的紧迫诉求：当务之急是要限制生产环境任意一台机器对MQ集群的管理权限,即限制对MQ中topic、消费组的创建与删除，对Broker相关配置的修改。
为了解决上述问题，需要利用RocketMQ自定义的ACL校验机制，其策略概况如下：
-
对于需要admin权限的操作，服务端必须开启校验。
-
对于不需要admin权限的操作，例如消息的发送、消费，如果客户端没有上传校验信息，默认放行
基于上述这样的改造，暂时可以解决问题。
RocketMQ的acl校验器是基于SPI机制，可插拔，提供了org.apache.rocketmq.acl.AccessValidator接口，并且需要将具体实现类写入到broker/src/main/resources/META-INF.service /org.apache.rocketmq.acl. AccessValidat or文件中。
但需要注意的是，如果该文件中配置了多个校验器，会自动组装成链条。
在实际使用过程中，发现这种扩展机制从使用层面来看并不优好，校验器(策略)尽量参数化，即在broker中使用参数来指定。
小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
、讲解视频**
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-RpTCyhNq-1710838638740)]
1040
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
