-
ActiveMQ失效轉移查看全部
-
集群方式查看全部
-
為什么要對消息中間件集群？ ·實現高可用，以排除單點故障引起的服務中斷 ·實現負載均衡，以提升效率為更多客戶提供服務。查看全部
-
【解決消息發送時的一致性問題】--使用內存日志的解決方案 內存日志可以使用EHCache類的框架來解決，并且它可以將內存日志持久化到本地文件，同時還支持集群復制，保證消息不丟失。查看全部
-
【解決消息發送時的一致性問題】--使用消息表的本地事務解決方案 雖然避開了分布式事務，但還是要求業務必須全部基于數據庫內的事務系統。查看全部
-
解決消息發送時的一致性問題： 使用JMS中XA系列接口保證強一致性。 1.引入分布式事務 2.要求業務操作必須支持XA協議 ------------------------------ 強一致性，同一時刻，要么都成功，要么都失敗。 弱一致性，不對時間做保障。但隨著時間的遷移，不同結點間的數據最終會達到一致。 ------------------- 實際生產中，特別是互聯網對一致性并沒有那么強，相反對性能要求卻非常高。 所以需要一種不引入分布式事務，又能保證最終一直性的解決方案。 ---------------- 使用消息表達本地事務來達到最終一致性--查看全部
-
ActiveMQ的虛擬主題，可以將消息自動中轉到對應的隊列。 其他MQ也有類似的解決方案。查看全部
-
jms級聯缺陷：中轉器的開發，增加的了 1.開發的復雜性：每增加一個業務集群，都需要增加一個中轉器。 2.保證中轉器的高可用，中轉器出行故障，消息將在主題中堆積。查看全部
-
需要解決的問題： 1.不同業務系統分別處理同一個消息，同一個業務系統負載處理同類消息 2.解決消息發送時的一致性問題 3.解決消息處理時的冪等性問題 4.基于消息機制建立事件總線查看全部
-
實際業務場景特點 同一類消息在集群中被負載消費 業務的發生和消息的發布最終一致性。查看全部
-
1要求積分系統和日志系統都能收到登錄事件（像發布訂閱模式）。 2不能讓同一個消息，被積分系統和日志系統集群重復處理（像隊列模式）。 3.登錄成功后，一定要將登錄事件發送到積分系統和日志系統，否則將出現部分積分和日志沒有正常增加的問題。（保證業務和消息的一致性）查看全部
-
ActiveMQ RabbitMQ Kafka 綜合評價查看全部
-
A為broker集群，不能作為生產者。 原因：如果A為生產者，宕機時有未被消費掉的消息，那B和C就收不到后續消息了查看全部
-
三臺服務器，達到既可以支持高可用，又可以達到負載均衡的效果 -------- AB、AC組成 消息同步 BC組成 主從 -------- 按順序啟動ABC， B拿到持久化資源成為主，C為從。 A為B的消息同步服務器，A不能持久化->通過同步->B進行持久化 A、B均可提供服務，達到 負載均衡+高可用 ---------------------------------------- A宕機，B可繼續提供服務（高可用）。 B恢復，可繼續消費B上的消息；A上的新消息也可以被B消費。（集群未受影響） ---------- B宕機，釋放資源排它鎖，C獲得資源為主 B恢復，B為從查看全部
-
Broker Cluster 不具備高可用，它正在處理的消息可能會丟失。 但是它做到了負載均衡，也就是說各節點之間的消息可以被共用。查看全部
舉報
0/150
提交
取消