-
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
提交
取消