iamqq23ue commented on pull request #3382:
URL: https://github.com/apache/rocketmq/pull/3382#issuecomment-976096874
1、具体的错误信息我能看一下吗？错误是工作中实际发生的，还是刻意模拟的呢？
答：报错信息就是Error occurred when force data to
disk这一段，内网的文件导出有点麻烦，您可以模拟一下不难。这是模拟的异常场景。实际中我们会遇到存储不可用的情况，比如raid卡故障、存储故障等。信息和报错是一致的。
2、我没有理解错的话，按照目前的修改，发生错误以后就不可恢复了，如果要保证高可用，应该让这个broker变成只读。把这个错误码返回给客户端，客户端也处理不了。如果我是消息系统的使用者，我就会质问集群的维护者，为什么有这么多发送失败？
答：实际上多主多从模式，设置了retry以后，客户端会自动重发，不会收到错误码。让broker变只读我没意见，我觉得非常好。就是感觉和以前的代码风格不一致了，因为我没看到目前有哪个错误会直接影响broker的。改动大了可能又会有别的同学不同意，我就没敢大改。
3、你说的根据返回码决定是否重试，那是内部返回码，定义在ResponseCode中。SendStatus是对外的返回码，通常拿到这个返回码就是成功了（FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT、SLAVE_NOT_AVAILABLE也是成功，可以消费到的），其它的错误都是丢异常的。
为什么说SendStatus的4个返回码都算是成功？我经常用RAID1举例子，假设我是存储管理员，用2块硬盘组成RAID
1的逻辑盘提供给用户读写，正常情况下数据是双写，但如果有块硬盘坏了，我作为存储管理员应该通过报警知道这件事情，并且尽快替换掉损坏的硬盘，而整个过程中我的用户是不需要知道这件事情的，他只要享受高可用的读写服务就好。
在我们厂的实践中，只要能拿到SendStatus，这4个返回码程序都是按成功处理的（报警另算）。
回到当前的这个问题来，如果错误已经不可恢复了，send方法应该抛出异常，而不是在SendStatus增加返回码（ResponseCode可以加）。
答：如果使用磁盘，除了磁盘故障之外，还有RAID卡故障，RAID卡是个单点，不会有机会从容的更换。而且实际上就算集中存储也会有小概率故障。
我在ResponseCode也加了报错码，一般来说客户端是收不到SendStatus的。另外我觉得FLUSH_DISK_FAILED和FLUSH_DISK_TIMEOUT其实很类似，都是内存写入而刷盘异常。
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
