這一章咱們來講講Exchange中對郵件的QOS設置，這些設置平常也許大多數場景中不會涉及到，因爲需要大批量發送郵件的場景裏都會用到郵件中間件（發送大量宣傳郵件或者報表）。但是一旦讓咱們碰上了，咱們也得知道從哪下手去調整這些設置不是，關於這個話題Technet上已經寫得非常好了，咱這裏也是做個總結和搬運。
在面對大批量郵件流量的時候，如何保證郵件流的處理井然有序，避免引起郵件阻塞，同時保護Exchange服務器防止其被過度使用，這是一個及其值得注意的問題。Exchange 2013當中引入了“郵件限制”（Message Throttling）這麼一套算法來避免客戶端無意或有意地造成 Exchange 服務器上的系統資源耗盡。當然，郵件限制設置值針對經過Exchange 2013傳輸系統的SMTP郵件流。
Exchange2013中的郵件限制算法比較複雜，它基於Exchange 2010 SP1中引入的QOS算法，通過郵件大小、收件人數量、傳輸頻率來計算郵件的郵件的平均傳遞成本。三個值都高那麼平均傳遞成本也會高，這裏的“高”主要是指超過500個收件人或者是體積大於1MB的郵件。Exchange的限制服務會監視這些開銷，並且爲每個用戶設定一個預期的開銷值，一旦用戶超過這個預期值，他的郵件就會被置爲低優先級，就會耗費更多的時間去傳遞。（在發送郵件時，這裏的優先級會覆蓋任何用戶手動設置的優先級。）Exchange的限制服務還會在郵箱數據庫層面彙總RPC連接的平均延遲和每秒請求數，以獲得一個可被量化的健康值，這個健康值就可以反映某個數據庫當前的負載情況。這個值最終會影響此數據庫中所有用戶的預期開銷。
這裏還是說的比較籠統，而且都是比較不可控的Exchange內部原理性的東西，如果要深入瞭解以上說的這段話，請參考：郵件短信和郵件流限制https://technet.microsoft.com/zh-cn/library/bb232205(v=exchg.150).aspx#Cost
你可以在以下設置裏調整郵件限制選項：
傳輸服務：Set-TransportService與Set-MailboxTransportService命令。一般情況下，管理員只需要針對外部流量進行限制，或者針對某一臺或某幾臺特別忙的傳輸服務器進行限制設置。
接收連接器：Set-ReceiveConnector命令，同樣的，需要注意這個設置是用來限制從組織外部進來的郵件流量。
發送連接器：Set-SendConnector命令
注意，默認的Exchange限制設置一般能滿足大多數場景的需求，除非是性能監控上已經暴露出某些傳輸服務器、邊緣服務器一直處於一個繁忙的負載狀態。比如，在高峯時段有大量隊列累計，且在高峯時段過了之後該隊列依舊沒有減少。這就有可能反應出該服務器處理能力已經跟不上，或者是其他的一些條件引起的，這些條件你可以通過調整參數來解決掉。下表彙總了你可以用來控制傳輸限制的不同參數。
命令集 | 參數 | 作用 |
Set-TransportService或Set-MailboxTransportService | MaxConcurrentMailboxDeliveries | 此參數指定將郵件傳遞給郵箱時，傳輸服務可以打開的最大傳遞線程數。默認值爲20，參數範圍爲1-256。微軟特別表示：如非必要請在客戶支持的建議下修改該值。 |
Set-TransportService 或 Set-MailboxTransportService | MaxConcurrentMailboxSubmissions | 此參數指定從郵箱發送郵件時，傳輸服務可以打開的最大提交線程數。默認爲20，參數範圍爲1-256。 |
Set-TransportService | MaxConnectionRatePerMinute | 此參數指定允許入站連接對傳輸服務打開連接的最大速率。默認值爲1200。 |
Set-TransportService 或 傳輸服務器屬性 | MaxOutboundConnections | 此參數指定可以同時打開的最大出站連接數。如果輸入值 unlimited，則不限制出站連接數。此參數的值必須大於或等於 MaxPerDomainOutboundConnections 參數的值。默認爲1000 還可使用 “服務器” > “服務器” > “屬性” > “傳輸限制” > “出站連接限制” 中的 EAC 配置該值。 |
Set-TransportService 或 傳輸服務器屬性 | MaxPerDomainOutboundConnections | 此參數指定任何一個域的最大併發連接數。如果輸入值 unlimited，則不限制每個域的出站連接數。默認爲20 還可使用 “服務器” > “服務器” > “屬性” > “傳輸限制” > “出站連接限制” 中的 EAC 配置該值。 |
Set-TransportService | PickupDirectoryMaxMessagesPerMinute | 此參數指定分揀目錄和重播目錄每分鐘處理的最大郵件數。每個目錄都能夠以此參數指定的速率獨立處理郵件文件。默認爲100 |
Set-ReceiveConnector | ConnectionInactivityTimeOut | 此參數指定在關閉連接之前，已打開的、與源郵件傳遞服務器的 SMTP 連接可以保持空閒的最長時間。該參數的值必須小於 ConnectionTimeout 參數指定的值。 默認值：在郵箱服務器上的傳輸服務 5 分鐘 在客戶端訪問服務器上的前端傳輸服務 5 分鐘。 在邊緣傳輸服務器上 1 分鐘。 |
Set-ReceiveConnector | ConnectionTimeOut | 此參數指定與源郵件傳遞服務器的 SMTP 連接可以保持打開狀態的最長時間（即使源郵件傳遞服務器正在傳輸數據）。該參數的值必須大於 ConnectionInactivityTimeout 參數指定的值。 默認：在郵箱服務器上的傳輸服務 10 分鐘 在客戶端訪問服務器上的前端傳輸服務 10 分鐘。 在邊緣傳輸服務器上 5 分鐘。 |
Set-ReceiveConnector | MaxInboundConnection | 此參數指定此接收連接器允許同時建立的最大入站 SMTP 連接數。 默認爲5000 |
Set-ReceiveConnector | MaxInboundConnectionPercentagePerSource | 此參數指定接收連接器允許同時從單個源郵件傳遞服務器建立的最大 SMTP 連接數。該值以接收連接器上的可用剩餘連接百分比表示。接收連接器允許的最大連接數通過 MaxInboundConnection 參數定義。 默認： 100 % 在郵箱服務器上的傳輸服務中的默認接收連接器 2 % 在郵箱服務器上的傳輸服務器、客戶端訪問服務器上的前端傳輸服務中的其他接收連接器。 |
Set-ReceiveConnector | MaxInboundConnectionPerSource | 此參數指定接收連接器允許同時從單個源郵件傳遞服務器建立的最大 SMTP 連接數。默認值： unlimited 在郵箱服務器上的傳輸服務中的默認接收連接器（受MaxInboundConnection限制） 20 在郵箱服務器上的傳輸服務器、客戶端訪問服務器上的前端傳輸服務中的其他接收連接器。 |
Set-ReceiveConnector | MaxProtocolErrors | 此參數指定在接收連接器斷開與源郵件傳遞服務器的連接之前，接收連接器允許出現的最大 SMTP 協議錯誤數。默認爲5次。 |
Set-ReceiveConnector | TarpitInterval | 此參數指定緩送技術中使用的延遲。緩送技術是針對表明存在帳戶蒐集***或其他不受歡迎的郵件的特定 SMTP 通信模式，人爲延遲 SMTP 響應的一種方法。帳戶蒐集***嘗試從特定組織收集有效的電子郵件地址，作爲商業垃圾郵件的目標。 TarpitInterval 參數指定的延遲只適用於匿名連接。 默認爲5 秒。 |
Set-SendConnector | ConnectionInactivityTimeOut | 此參數指定在關閉連接之前，已打開的、與目標郵件傳遞服務器的 SMTP 連接可以保持空閒的最長時間。 默認爲10分鐘 |
最後還要一提的是，在 Exchange 2013 中，每個郵箱都具有 ThrottlingPolicy 設置。此設置的默認值爲空 ($null)。可以創建好限制策略，然後在 Set-Mailbox cmdlet 上使用 ThrottlingPolicy 參數爲需要應用的用戶郵箱配置限制策略。一般不建議進行限制策略的修改，除非你非常在意這些用戶對以下功能的資源佔用，這裏的設置主要是用戶可通過特定連接或在特定時間內對 Exchange 執行的活動數量，這些設置會影響用戶的預期開銷值：
· Exchange ActiveSync
· Exchange Web 服務 (Exchange Web Services)
· Outlook Web App
· 統一消息
· IMAP4
· POP3
· Outlook 客戶端連接（MAPI 或 RPC 連接）
· 郵件流設置
· PowerShell 命令
· CPU 使用情況
主要涉及到的命令就是Get/REMOVE/NEW/SET-ThrottlingPolicy，然後綁定到用戶郵箱即可。
OK，郵件限制就聊到這裏，下一章咱們聊聊另一個Exchange應對高峯流量時的自我保護措施-反壓。
本文出自 “卡斯特梅的雨季” 博客，請務必保留此出處http://sodaxu.blog.51cto.com/8850288/1684075