背景：該業(yè)務(wù)場景常見于促銷活動通知，有時候運營配置某些活動后，要全量的通知給用戶。在該項目中，push通知鏈路共有三個階段，伴隨用戶量和業(yè)務(wù)復(fù)雜度的上升，不斷地對該鏈路進(jìn)行優(yōu)化。

階段一：初期，滾動拉取用戶數(shù)據(jù)，采用線程池或for循環(huán)，調(diào)用推送接口。進(jìn)行模板組裝和SDK調(diào)用

瓶頸：

• 性能效率方面：
  • 資源占用高：若用for循環(huán)調(diào)用推送接口，需依次處理每個用戶，用戶量大時耗時久，易引發(fā)系統(tǒng)長時間資源占用，拖慢其他業(yè)務(wù)。
  • 吞吐量受限：線程池若線程數(shù)設(shè)置不合理，或無有效任務(wù)隊列、拒絕策略，高并發(fā)下會線程競爭、任務(wù)積壓，降低推送吞吐量，無法及時觸達(dá)大量用戶。
• 穩(wěn)定性與可靠性方面：
  • 異常影響范圍大：滾動拉取用戶和循環(huán)推送中，單個用戶處理出錯，若未妥善隔離，可能讓整個循環(huán)中斷或影響其他用戶處理，降低推送成功率與系統(tǒng)穩(wěn)定性。
  • 缺乏容災(zāi)重試：未對失敗推送任務(wù)有效重試、降級，遇到網(wǎng)絡(luò)抖動等臨時問題，會大量丟失推送，影響活動觸達(dá)效果，且難定位恢復(fù)故障。
• 業(yè)務(wù)靈活性與擴(kuò)展性方面：
  • 耦合度高：模板組裝、SDK 調(diào)用和用戶拉取推送流程耦合，后續(xù)要換推送 SDK 或改模板，需改動大量代碼，增加維護(hù)成本與升級風(fēng)險。
  • 難適配復(fù)雜場景：業(yè)務(wù)復(fù)雜后，如按用戶分層、分時段推送，現(xiàn)有簡單循環(huán)難擴(kuò)展，要大改流程才能支持，限制業(yè)務(wù)創(chuàng)新優(yōu)化。

階段二：引入mq和模塊劃分

成效：

• 性能效率方面
  • 提高并發(fā)處理能力：引入 MQ 集群，通過 MQ 分區(qū)和多消費節(jié)點實現(xiàn)了并發(fā)消費。相比階段一單純使用線程池或 for 循環(huán)依次處理用戶，并發(fā)消費能同時處理多個推送任務(wù)，大大提高了 push 的時效性，減少了整體推送耗時，能夠更好地應(yīng)對大量用戶的推送需求 ，提升了系統(tǒng)的吞吐量。
  • 資源利用更合理：運營服務(wù)和推送服務(wù)職責(zé)分離，使得各自可以根據(jù)業(yè)務(wù)特點進(jìn)行針對性的資源配置和優(yōu)化。例如，運營服務(wù)專注于活動創(chuàng)建和用戶數(shù)據(jù)查詢，推送服務(wù)專注于消息組裝和推送，避免了階段一中因功能耦合導(dǎo)致的資源過度占用和相互影響，提高了系統(tǒng)資源的利用效率。
• 穩(wěn)定性與可靠性方面
  • 解耦降低風(fēng)險：MQ 解耦了運營服務(wù)與推送服務(wù)，使得一個服務(wù)出現(xiàn)問題時，不容易影響到另一個服務(wù)。比如運營服務(wù)在創(chuàng)建活動或查詢用戶數(shù)據(jù)時遇到短暫的性能問題，不會直接導(dǎo)致推送服務(wù)的阻塞或中斷，降低了單個服務(wù)故障對整個推送鏈路的影響范圍，提高了系統(tǒng)的穩(wěn)定性。
  • 失敗重試機(jī)制：MQ 具備消息持久化和重試機(jī)制，對于推送失敗的消息可以進(jìn)行重新投遞和處理，一定程度上解決了階段一中缺乏有效容災(zāi)重試的問題，提高了消息推送的成功率和可靠性。
• 業(yè)務(wù)靈活性與擴(kuò)展性方面
  • 配置化管理：提供活動配置、推送模板配置等能力，代碼可以根據(jù)配置信息動態(tài)進(jìn)行推送渠道選擇和模板內(nèi)容構(gòu)建。這使得在面對不同類型的促銷活動或者業(yè)務(wù)需求變化時，無需修改大量代碼，只需要調(diào)整配置即可，提高了業(yè)務(wù)的靈活性和可維護(hù)性。
  • 抽象工廠模式：推送服務(wù)根據(jù)消息推送類型選擇對應(yīng)的組件工廠進(jìn)行消息組裝，采用抽象工廠模式實現(xiàn)了推送組件的可插拔性。當(dāng)需要新增推送渠道（如增加新的 APP 推送方式或新的短信供應(yīng)商）時，只需要擴(kuò)展對應(yīng)的組件工廠和推送組件，而無需修改其他部分的代碼，降低了代碼耦合度，增強(qiáng)了系統(tǒng)的擴(kuò)展性。

但這種升級后仍存在瓶頸：