bug: confusing result for traffic split plugin 灰度插件的结果混乱

[Marco-Zheng]

Issue description

我在traffic split中添加了如下代码，为了从header中获取版本参数_v

配置了两个上游

服务的插件配置如下

"traffic-split": {
      "disable": false,
      "rules": [
        {
          "match": [
            {
              "vars": [
                [
                  "_v",
                  "==",
                  "3.0.0"
                ]
              ]
            }
          ],
          "weighted_upstreams": [
            {
              "upstream_id": "1144979451",
              "weight": 1
            }
          ]
        }
      ]
    }

然后访问服务header带上_v=2.0.0
Tips：这里说明下，我的upstream分别是两个版本2.0.0和3.0.0
2.0.0是老版本的代码，返回值的data为版本的值，如传入v=2.0.0，返回值为2.0.0，传入1.0.0返回值为1.0.0

{
    "_st": 1623911745176,
    "code": 0,
    "data": "2.0.0",
    "lang": "zh_CN"
}

3.0.0为我测试的新代码，返回值固定为

{
    "_st": 1623911745176,
    "code": 0,
    "data": "",
    "lang": "zh_CN"
}

data为空值

按照规则来说，当_v=2.0.0，会拿到结果data=2.0.0，结果也是对的，然后我访问_v=3.0.0，结果也是对的

但是奇怪的事情发生了，当我再次访问_v=2.0.0，结果居然变成跟_v=3.0.0一样的结果了（本来正确结果应该拿到data=2.0.0）

这让我不得不怀疑，当upstream匹配上_v=3.0.0之后，这个upstreamId在缓存中被重写了，导致匹配上一次之后，后面的所有请求，我不管带上什么版本，如_v=1.0.0、_v=4.0.0，拿到的结果都是_v=3.0.0服务器返回的结果

而我期望的结果是，除了_v=3.0.0的返回结果为data=“”，其他的版本的返回结果为data=版本值，这样才能表示灰度执行成功

---

根据日志也可以看的出来，第一次为_v=2.0.0的时候，match_flag为false，第二次_v=3.0.0，match_flag为true，并打印出正确的upstreamId，奇怪的是第三次_v=2.0.0的时候match_flag为false，但是访问到了版本为3.0.0的服务器上

Environment

Bug report without environment information will be ignored or closed.

• apisix version (cmd: apisix version):2.4

[Marco-Zheng]

按照我刚刚的想法，我在如下代码处添加了日志，打印ctx.matched_route.value.upstream_id

可以发现结果如下，第一次的upstreamId=1144055930是对的，为版本2.0.0的upstreamId
第二次的upstreamId=1144979451也是对的，为版本3.0.0的upstreamId
但是第三次，我是用_v=2.0.0去访问的，upstreamId应该为1144055930而不应该为1144979451，因此怀疑该upstream_id被重写之后再也没有换回来，下次请求，还是用的旧的upstream_id，这样会导致一些问题

[tzssangglass]

maybe this PR #3842 can solve it, and you can upgrade the apisix version

[Marco-Zheng]

@tzssangglass I upgrade the apisix to version 2.6, the problem has been solved, thanks a lot!