2015 年 12 月

第 30 卷,第 13 期

本文章是由機器翻譯。

Microsoft Azure - Azure、Web API 和 Redis 如何讓傳遞資料變得更快

強尼戴普 Webb | 2015 年 12 月

現今的 worldof 即時行銷部門,死亡的旋轉圓,太常伴隨著等待網頁載入或搜尋查詢,以填入真的很可能表示銷售死。建立、 儲存和分析越來越多的資料記錄時,產生豐富、 深入解析即時資料成長以往更具挑戰性。問題就變成如何選擇適當的技術工具和最佳架構詳查數百萬筆資料記錄,以及提供即時結果,以改善客戶經驗。

這篇文章將探討最新的使用案例,我們幫助實作 Redis 和 Web API 的用戶端。我們將討論我們實作的方法,我們遇到的挑戰,以及如何我們最終達成的效能需求。

商務挑戰

數個月前 100 大多樣化保險及金融財務服務業組織接近 Harte Hanks,全域行銷公司,透過新的開發案。公司想要在線上的保險報價程序期間提供更好、 更豐富的客戶經驗。若要這樣做,它需要啟用主動式快速存取客戶的原則資料。

目標是要讓客戶以檢視並選取一或多個透過網際網路自我服務或代理程式後端應用程式的保險原則。最後,這會導致較高商業價值、 更高的客戶滿意度、 高報價繫結速度,以及改善的代理程式的委任程序。為了使此現實情況下,客戶的預存的詳細資料和資料所需的處理,引號程序期間會比對,並且主動,提供近乎即時的方式。

用戶端的資料庫包含超過 50 萬個記錄,這表示任何傳統資料庫與這一類的要求通常會需要多個秒鐘的時間載入。我們已提供 Web 服務能夠在此大型資料來源上執行查詢,並將結果傳遞到毫秒內取用者負責。

此工作中,我們會評估 Redis 和 Web API 的實作。整體的量值因素包括:

  • 交易要求
  • 物件的要求
  • 每秒的回應
  • 資料的總頻寬
  • 站台的總輸送量

實作: 我們如何辦到了

建置 Web 服務,以將資料公開需要元件都會提供特定功能的多個圖的層。隨著 Web 服務的要求時,支援這些層級的基礎結構就必須改寫,並迅速調整規模。雖然延展性很重要,但可用性為並同樣重要的是為了讓取用者快樂,一律必須考量。此外,公開的端點必須監視,並以特定的驗證通訊協定,以確保資料保護並使用最大效能來安全地傳遞包裝。若要協助符合這些需求,我們的解決方案,我們可以利用 Microsoft Azure。在 Azure 中,我們部署的資源包括虛擬機器、 Web 應用程式、 虛擬網路、 資源群組組合及可用性設定組來建立功能完整、 高品質的解決方案。

資料層

因為大部分的解決方案可利用 Microsoft 堆疊,讓我們利用 Microsoft SQL Server 在大多數情況。不過,此解決方案的 SLA 需求會指定服務回應時間少於 1 秒,每個要求,每小時,大約 6000 要求的速率超過 50 萬筆記錄的資料集。傳統的資料庫,例如 SQL Server 會將資料儲存到磁碟和 IOPS 的瓶頸,因為我們無法保證每個查詢會通過這項需求。進一步讓問題更複雜的問題,我們已公開所需的資料子集屬於傳統資料庫含有數 tb 的不相關的資料。基於這個理由,我們可以開始評估解決方案,以便快速支援大型資料集。當我們發現 Redis。

Redis 是記憶體中的資料結構儲存區支援多個資料型別。基本的伺服器需求包括 Linux 散發套件,足夠的 RAM 來封裝您的資料和磁碟空間不足以保存資料。Redis 也可以設定為叢集,但這是較適合使用數 tb 資料的解決方案。因為我們的資料集不小於 50 GB,我們決定為了簡單起見,並設定單一的主/從屬性設定。若要裝載此組態,我們會建立兩個虛擬網路中的 CentOS 7.1 虛擬機器在 Azure 上。每個 VM 包含 56 GB 記憶體、 靜態 IP 位址和 SSH 端點使用 AES256 加密。因為這兩個 Vm 共用可用的集合,Azure 提供的 99.95 %sla 保證運作時間。另外,我們建立的所有資源記錄都附加至資源群組建立專為此解決方案,讓我們來監視和管理每月計費。只需要幾分鐘內,我們的 Vm 已部署,而且可供我們使用。

站立 Redis 伺服器是簡單又完成一小時內。下載並安裝最新穩定版本到我們剛建立的伺服器之後, 第一次與解決方案的首要我們修改組態檔,以允許 Redis 呼叫僅能附加的檔案 (12X12) 持續性。簡單地說,這表示傳送至我們的執行個體的每個命令會儲存到磁碟。如果要重新啟動伺服器,所有會重新執行命令,將伺服器還原到其原始狀態。若要消除繁雜很少,BGREWRITEAOF 命令就會觸發偶爾也會重寫命令以重建在記憶體中目前的資料集所需的最短序列的檔案。此外,我們會設定使用 50 GB,建立一個緩衝區,並防止 Redis 耗用所有的系統記憶體,如果已載入太多資料的記憶體上限。這一點之後,如果我們的解決方案曾經需要更多記憶體,我們可以輕鬆地使用 Azure 入口網站的 VM 的大小調整和更新組態更新版本。接下來,我們設定從屬執行個體,以確認主機中,建立資料複寫。若主要執行個體已變成無法使用,從屬執行個體都可以提供我們的用戶端。最後,我們重新啟動我們的 Redis 伺服器組態,才會生效。以下是我們所使用的設定:

appendonly yes
maxmemory 50000000000
slaveof 10.0.0.x 6379
# cluster-enabled no

資料載入和基準測試

我們將從傳統資料庫載入 Redis 所需的資料包含大約 4 GB 的客戶中繼資料。此更新中繼資料,每日,因此我們需要建立處理程序,將它轉換成 Redis 資料類型,並大量載入以保持我們的解決方案。若要執行此動作,我們可以建立自動化的程序來擷取每日變更集到 Redis 通訊協定格式的檔案,並將它們傳送到主要伺服器使用可用的 SSH 端點。在主要執行個體,我們建立了大量載入的 bash 指令碼使用管道模式的檔案。若要強調,管道模式跟我們一樣能在 5 分鐘內載入 28 百萬筆記錄是解決方案的我們的主要項目。請注意,不過,該管線模式尚無法相容於叢集實作。在初始原型設計階段中,我們發現,載入到叢集中的 28 百萬筆記錄會需要數小時因為記錄已個別傳送。這是我們來維持簡單的主/從屬性實作的設計決策的重要因素。管道模式命令和回應的單一執行個體看起來像這樣:

$ cat data.txt | redis-cli –pipe
All data transferred. Waiting for the last reply...
Last reply received from server.
errors: 0, replies: 1000000

之後管道模式中執行,回應會指出已收到多少錯誤和回覆。我們會剖析這個回應的指令碼內、 封存檔案和電子郵件通知傳送給適當的技術小組。對於每個錯誤,技術人員,可以評估擷取,快速找出想要重新載入任何資料。完成之後的每日處理指令碼,我們是進行效能評估我們使用 Redis 基準測試公用程式的實作。圖 1 顯示我們的解決方案,它會符合我們的 SLA 需求,想必我們的效能結果。

Redis 基準測試
圖 1 Redis 基準測試

服務層

很重要,我們的用戶端是唯一的取用者,我們的解決方案。幸運的是,Azure 簡化這與存取控制服務,讓我們建立我們的解決方案特別的 OAuth 提供者。一旦實作,我們的服務需要每個要求,以新權杖在 5 分鐘後重新產生特定的權杖。附帶一提,語彙基元,應該永遠保存到期之前。要求每個服務呼叫新的權杖會基本上會造成瓶頸方案或者,更糟的是,讓它無法存取如果超過 Azure 所指定的要求限制。我們強烈建議利用這項功能,請參閱 Azure 文件實作到生產環境之前的任何人。

有多個 C# Redis 用戶端可使用,但因為我們認為這是最受歡迎且最成熟,我們會使用 StackExchange.Redis。因為所有的資料儲存在集合中,我們可以使用 LRANGE 命令來查詢資料。若要避免重新連線的每個查詢,StackExchange.Redis 所使用的連接是單一子句模式中管理。中的範例 圖 2 示範如何擷取資料。

圖 2 連線到 Redis 及擷取資料

private static Lazy<ConnectionMultiplexer> lazyConnection =
  new Lazy<ConnectionMultiplexer>(() => {
  return ConnectionMultiplexer.Connect(
    ConfigurationManager.AppSettings[Constants.AppSettings.RedisConnection]);
});
public static ConnectionMultiplexer Connection
{
  get
  {
    return lazyConnection.Value;
  }
}
public async static Task<MemberResponse> MemberLookup(MemberRequest request)
{
  MemberResponse response = new MemberResponse();
  try
  {
    if (request != null && request.customer != null && request.customer.Count() > 0)
    {
      foreach (var customer in request.customer)
      {
        Customer c = customer;
        RedisKey key = GetLookupKey(c);
        IDatabase db = Connection.GetDatabase();
        c.policies = await db.ListRangeAsync(key, 0, -1, CommandFlags.None);
        response.customer.Add(c);
      }
      response.success = true;
    }
    else
    {
      response.exceptions = new List<ServiceException>();
      response.exceptions.Add(Classes.ErrorCodes.Code_101_CustomerRequired);
      response.success = false;
        }
  }
  catch (Exception ex)
  {
    response.exceptions = new List<ServiceException>();
    response.exceptions.Add(Classes.ErrorCodes.Code_100_InternalError);
    response.success = false;
    Logging.LogException(ex);
  }
  response.executedOn =
    Utils.FormatEST(DateTime.UtcNow).ToString(Constants.DateTimeFormat);
  return response;
}

若要裝載在 Azure 中我們的解決方案,我們建立的 Web 應用程式。達到最佳效能,很重要,我們將 Web 應用程式部署至與 Redis 執行個體相同的區域。一旦部署應用程式,我們建立 VNET 連線到我們的 Redis 虛擬網路,讓服務取得資料的直接存取。這個連接會示範 圖 3

VNET 整合的連線
圖 3 VNET 整合的連線

此 Web 應用程式已設定進行調整以根據 CPU 使用量的 10 個執行個體。因為我們的解決方案的流量各不相同,視需要調整 Web 應用程式。做為額外的安全性階層,SSL 憑證已套用至應用程式,以及篩選特別為用戶端的 IP。雖然應用程式已設定為自動調整,但它沒有自動容錯移轉。為了充分發揮解決方案的可用性,我們的用戶端,我們會建立主要的 Web 應用程式中的複製,但放在不同區域。兩個應用程式新增至 Azure 流量管理員,我們也運用進行自動容錯移轉。

最後,我們要購買自訂網域,並建立 CNAME 記錄指向我們流量管理員的 URL,完成我們的實作。若要監視的每日的效能,我們的解決方案,我們可以購買直接從 Azure marketplace 的 New Relic 的執行個體。所使用的 New Relic,我們可以快速識別需要改進,以及伺服器可用性的區域。

總結

Azure 中部署這個方案,我們了解如何讓不同的技術堆疊合作快速來提供功能強大、 成功的解決方案。雖然將方案部署至 Azure 不排除維護伺服器,如果您遵循的模式中的位置,您必須成功。根據您的解決方案的平均持續時間,您無法藉由將您的方案移至雲端儲存的硬體成本。

結束實作時,平均回應時間是 50 個並行使用者 25 毫秒。根據這些結果,回應時間是每 15 加入的並行使用者擴充大約 10 毫秒。


Sean IannuzziHarte Hanks 是標頭的技術,已超過 20 年,科技產業播放中的社交網路,大的資料過多的技術和商業構想之間溝通落差舉足輕重的角色在資料庫中的解決方案,雲端運算、 電子商務及財務應用程式的今天。Iannuzzi 有經驗的 50 個以上的獨特的技術平台、 已達成十幾技術獎/認證,專精於技術方向以及可協助您達成商務目標的解決方案。

強尼戴普 Webb是 Harte Hanks 軟體架構設計人員和已實作使用已知的用戶端的尖端技術過去 10 年來的高品質解決方案。他的專長包括完整的軟體開發生命週期,以及 Microsoft.NET Framework 中,軟體架構、 雲端運算,Web 開發、 行動應用程式開發、 API 開發、 SQL 資料庫和 NoSQL 資料庫。

感謝以下技術專家對本文的審閱: Eric 謎 (Liquidhub)
Eric 謎是 Philadelphia Liquid 中樞的技術經理。他已被開發和設計解決方案以.NET Framework 自創立。他的專長包括前端 web 開發、 REST API、 WCF、 Windows 服務和 SQL Server。他有深入的金融服務和直接行銷業界經驗。