dubbo provided many cluster for example: failover,failfast,failsafe,failback,forking,mergeable,broadcast.
in FailoverClusterInvoker,dubbo will try another provider when catch RpcException.
in BroadcastClusterInvoker,dubbo will call all providers one by one.
in FailbackClusterInvoker , dubbo will retry when failed.
in ForkingClusterInvoker, dubbo will call all providers in different thread.
but ConsumerContextFilter will clearAttachments after call. it's lead to Attachments lost when retry and Muti call in clusterInvoker.
dubbo提供了很多不同类型的cluster，例如failover,failfast,failsafe,failback,forking,mergeable,broadcast.
其中FailoverClusterInvoker会做失败转移，调用失败后重试另一台服务器。
BroadcastClusterInvoker会依次调用所有的服务器。
FailbackClusterInvoker中，如果调用失败，会定时重试。
ForkingClusterInvoker中，会在不同的线程中分别调用所有的服务提供方。
但是，dubbo中同时还存在一个filter叫做ConsumerContextFilter，在一次调用完成后会立即清理掉所有的Attachments。所以，不管是FailoverClusterInvoker的失败转移，还是FailbackClusterInvoker的定时重试，抑或是BroadcastClusterInvoker的广播，都会存在问题，因为后续的调用中，Attachments已经全部丢失了。
一次调用完成后，的确应该清理Attachments，但Attachments的清理时机放在ConsumerContextFilter是不合适的，不管是FailoverClusterInvoker的失败转移，还是FailbackClusterInvoker的定时重试，在重试调用的时候，参数和第一次调用时应该是完全一致的，而非失败重试时参数丢失，Attachments清理最正确的做法应该是在cluster级别来做。
dubbo provided many cluster for example: failover,failfast,failsafe,failback,forking,mergeable,broadcast.
in FailoverClusterInvoker,dubbo will try another provider when catch RpcException.
in BroadcastClusterInvoker,dubbo will call all providers one by one.
in FailbackClusterInvoker , dubbo will retry when failed.
in ForkingClusterInvoker, dubbo will call all providers in different thread.
but ConsumerContextFilter will clearAttachments after call. it's lead to Attachments lost when retry and Muti call in clusterInvoker.
dubbo提供了很多不同类型的cluster，例如failover,failfast,failsafe,failback,forking,mergeable,broadcast.
其中FailoverClusterInvoker会做失败转移，调用失败后重试另一台服务器。
BroadcastClusterInvoker会依次调用所有的服务器。
FailbackClusterInvoker中，如果调用失败，会定时重试。
ForkingClusterInvoker中，会在不同的线程中分别调用所有的服务提供方。
但是，dubbo中同时还存在一个filter叫做ConsumerContextFilter，在一次调用完成后会立即清理掉所有的Attachments。所以，不管是FailoverClusterInvoker的失败转移，还是FailbackClusterInvoker的定时重试，抑或是BroadcastClusterInvoker的广播，都会存在问题，因为后续的调用中，Attachments已经全部丢失了。
一次调用完成后，的确应该清理Attachments，但Attachments的清理时机放在ConsumerContextFilter是不合适的，不管是FailoverClusterInvoker的失败转移，还是FailbackClusterInvoker的定时重试，在重试调用的时候，参数和第一次调用时应该是完全一致的，而非失败重试时参数丢失，Attachments清理最正确的做法应该是在cluster级别来做。