如何防止 Azure Web 角色中的重复 HTTP 请求

How to prevent duplicate HTTP requests in Azure Web Role

我们间歇性地看到重复的 HTTP 请求命中我们的 Azure 云服务应用程序。我们的应用程序使用 Azure 流量管理器在两个区域之间分配流量(用于 DR 目的)。我们每个区域有 3 个大型 Web 角色实例。

有没有人在 Azure 中遇到(理想情况下,已解决)类似的问题?

更多细节如下:

1.跟踪记录:

跟踪日志记录在似乎重复的 MVC 控制器操作中实现:

    [HttpPost]
    public JsonResult JsonPost(FormCollection formData)
    {
        Logger.Info(LogFormatter.FormatMessage(ToString(), "JsonPost", UserHelper.CustomerSession.CustomerId, "Begin JSON post."));
        var result = new DefaultJsonResult();
        try
        {
            #region Build and validate foo model
            var fooModel = BuildFooModel(formData);
            .
            .
            .
        }
        catch (Exception ex)
        {
            Logger.Error(LogFormatter.FormatException(ex, ToString(), "JsonPost",
                UserHelper.CustomerSession.CustomerId, "Error while proccessing Foo."));
            result.Success = false;
            result.Action = new JsonResultAction(JsonResultActionType.Display);
            result.Error = new JsonResultError();
            result.Error.Details.Add(new JsonResultErrorDetail
            {
                Type = "FooProcessing",
                Message = "Error while proccessing Foo."
            });
        }
        Logger.Info(LogFormatter.FormatMessage(ToString(), "JsonPost", UserHelper.CustomerSession.CustomerId, "End JSON post."));

        return Json(result);
    }                

在跟踪日志中,我们看到以下多个实例:

Message: Calculating bar.
Timestamp: 01/22/2015 03:42:28
Controller Name: Com.Web.Controllers.FooController
Action Name: bar
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_0; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=15;

Message: Begin JSON post.
Timestamp: 01/22/2015 03:43:22
Controller Name: Com.Web.Controllers.FooController
Action Name: JsonPost
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_0; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=28;

Message: Sending Foo Notification
Timestamp: 01/22/2015 03:43:28
Controller Name: Com.Web.Business.Modules.Foo.FooModule
Action Name: ProcessFoo
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_0; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=28;

Message: Begin JSON post.
Timestamp: 01/22/2015 03:43:30
Controller Name: Com.Web.Controllers.FooController
Action Name: JsonPost
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_2; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=13;

一些注意事项:

  1. 第二个 "Begin JSON post" 发生在第一个请求记录其 "End JSON post" 之前(顺便说一句,从来没有记录过)

  2. 第二个 "Begin JSON post" 发生在另一个网络角色实例上

2。 IIS 日志:

对应的IIS日志如下:

2015-01-22 03:42:29 W3SVC1273337584 RD00155DE0F696 127.0.0.13 POST /foo/bar
- 443 johndoe@hotmail.com 128.0.0.28 HTTP/1.1 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_8_2)+AppleWebKit/536.26.17+(KHTML,+like+Gecko)+Version/6.0.2+Safari/536.26.17

2015-01-22 03:43:30 W3SVC1273337584 RD00155DE0CAC8 127.0.0.54 POST /foo/jsonpost
- 443 johndoe@hotmail.com 128.0.0.28 HTTP/1.1 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_8_2)+AppleWebKit/536.26.17+(KHTML,+like+Gecko)+Version/6.0.2+Safari/536.26.17

此时您可能会问自己第一个 /foo/jsonpost 请求的 IIS 日志条目在哪里?这种行为对于重复请求的每个实例都是一致的,但是,原因仍然是个谜。

感谢阅读。任何关于如何进一步排除故障的见解甚至建议都将不胜感激。


谷歌搜索 "azure duplicated requests" 得到以下结果:

2015 年 1 月 26 日更新
启用失败请求跟踪希望捕获幻影(第一个 /foo/jsonpost)请求并隔离它的来源。不幸的是,仍然没有运气,Failed Request Tracing 与 IIS 日志一致。

结案:

丢失的日志条目是由有缺陷的第三方 API 通信逻辑导致的堆栈溢出造成的。当 IIS 重新启动它时 resumed/recovered 导致堆栈溢出的请求。因为 connection was kept alive throughout the recycle 客户端只看到了第二次执行的响应。第二次尝试没有发生堆栈溢出的原因是执行采用与第一次执行不同的代码路径。

我们怎么知道有堆栈溢出(除了 TODO 注释为“prevent stack overflow”):

  • 在系统事件日志中:“A process serving application pool 'ASP.NET v4.0' suffered a fatal communication error with the Windows Process Activation Service. The process id was '5328'. The data field contains the error number.
  • 在 HTTPERR (IIS) 日志中,出现“Connection_Abandoned_By_ReqQueue”错误,这意味着应用程序池中的工作进程意外退出或通过关闭其句柄孤立了一个挂起的请求
  • 崩溃日志显示 0x800703e9 - “Recursion too deep; the stack overflowed.

希望这些发现对其他试图解开 IIS 日志丢失之谜的迷失灵魂有所帮助...